x86, paravirt: Add a global synchronization point for pvclock
in [Kernel]
|
From: Jeremy Fitzhardinge on 14 Jul 2010 17:20 On 07/14/2010 01:50 PM, H. Peter Anvin wrote: > invlpg, in the general case, definitely needs a memory clobber even if > volatiles are ordered, since it needs to be ordered with regards to > non-volatile memory operations. > Yes. I'd say write_crX should need that too, since they can they can have a variety global effects on how memory addressing works (from tlb flush to switching pagetable formats). > Note that memory clobbers don't by themselves enforce ordering since > they don't prevent the ordering of memory clobbers with respect to each > other. > Hm. Well we do *definitely* rely on that. I guess technically we'd need at least a memory input on the asm to be ordered with respect to a memory clobber. But that doesn't seem to have been an issue (or perhaps its mixed up with the secret semantics of asm volatile). J -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 15 Jul 2010 01:10 On 07/14/2010 11:11 PM, Jeremy Fitzhardinge wrote: > > The question is "what are the real ordering semantics of asm volatile"? > What ordering is enforced between other asm volatiles? What ordering is > enforced between asm volatiles and regular memory accesses? asm volatile > and other code? > > The documentation discusses this to some extent, but mostly says "there > are no ordering guarantees". Older versions of gcc - 2.95, for example > - are more explicit, saying that "asm volatiles" won't be moved out of > their basic block (I think that's how I parse it, anyway). > I looked over the text, and I think you're confusing static reordering and duplication with execution reordering (gcc is indeed free to move around and even replicate asm volatile statements). One thing is that the docs makes it perfectly clear that asm volatile is not ordered with respect to *non*-volatile operations (*all* the examples are volatile-nonvolatile.) It says that asm volatile statements may not be "consecutive", i.e. gcc may generate code in between them, but all of this is well known and understood. The other thing that the documentation *does* specifically make clear is that an "asm volatile" has an implicit dependency on all memory (as an input, as opposed to an output/clobber.) I actually found the following statement in the gcc documentation, although it is in the section on C++ (6.1 in my version); the text, though, makes it clear that it applies to both C and C++: Both the C and C++ standard have the concept of volatile objects. These are normally accessed by pointers and used for accessing hardware. The standards encourage compilers to refrain from optimizations concerning accesses to volatile objects. The C standard leaves it implementation defined as to what constitutes a volatile access. The C++ standard omits to specify this, except to say that C++ should behave in a similar manner to C with respect to volatiles, where possible. The minimum either standard specifies is that at a sequence point all previous accesses to volatile objects have stabilized and no subsequent accesses have occurred. Thus an implementation is free to reorder and ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ combine volatile accesses which occur between sequence points, but ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot do so for accesses across a sequence point. The use of ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ volatiles does not allow you to violate the restriction on updating objects multiple times within a sequence point. [My emphasis, obviously.] I think that pretty much settles the matter, since any statement (including an asm statement) inherently has a sequence point before or after it. However, I will file a gcc bug report to clarify. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 15 Jul 2010 01:40 For those that are interested: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44943 -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 16 Jul 2010 01:00 On 07/14/2010 01:45 PM, Zachary Amsden wrote: > That's the kind of bug I think Linus is talking about. We've been > expecting volatile to work that way for over a decade, by my > recollection, and if it doesn't, there is going to be a lot of broken code. > > Shouldn't we at least get a compiler switch to force the volatile > behavior? I'd suggest it default to conservative. At this point, it looks like there is no reason to be alarmed. The documentation actually contains a statement about volatiles not being mutually reordered across sequence points, and since asm is a statement (rather than an expression) it is always surrounded by sequence points. I have filed a gcc ticket to ask for clarification. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jeremy Fitzhardinge on 27 Jul 2010 13:50
On 07/13/2010 11:15 AM, Linus Torvalds wrote: > On Tue, Jul 13, 2010 at 11:04 AM, Avi Kivity<avi(a)redhat.com> wrote: >> Well, current upstream uses "m": > Yes, I'd expect current 2.6.34 to also show the same problem. > >> and works; I also failed to reproduce with 2.6.32.16. So I expect some >> toolchain involvement. > And yes, I do believe it's likely a newer gcc that triggers it too, > otherwise we'd have seen more reports of it. Did anyone get around to doing a proper fix for this? I don't see one in tip.git or linux-2.6.git. And it needs to get back into stable... Thanks, J -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |