x86, paravirt: Add a global synchronization point for pvclock
in [Kernel]
|
From: H.J. Lu on 14 Jul 2010 15:40 On Wed, Jul 14, 2010 at 12:00 PM, H. Peter Anvin <hpa(a)zytor.com> wrote: > On 07/14/2010 11:18 AM, H.J. Lu wrote: >> >> There are some discussions on: >> >> http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02001.html >> http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00001.html >> >> Are they related? >> > > Not directly as far as I can tell. > > The issue is if gcc can ever reorder, duplicate or elide a volatile > operation (either asm volatile or a volatile-annotated memory > reference.) �In my (and Linus') opinion, this would be an incredibly > serious bug. > > Is there a gcc bug for this? -- H.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 14 Jul 2010 15:40 On 07/14/2010 12:32 PM, H.J. Lu wrote: > On Wed, Jul 14, 2010 at 12:00 PM, H. Peter Anvin <hpa(a)zytor.com> wrote: >> On 07/14/2010 11:18 AM, H.J. Lu wrote: >>> >>> There are some discussions on: >>> >>> http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02001.html >>> http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00001.html >>> >>> Are they related? >>> >> >> Not directly as far as I can tell. >> >> The issue is if gcc can ever reorder, duplicate or elide a volatile >> operation (either asm volatile or a volatile-annotated memory >> reference.) In my (and Linus') opinion, this would be an incredibly >> serious bug. > > Is there a gcc bug for this? > Are you asking for a bug report against the documentation? We're not sure what the semantics intended by the gcc team to be, which I guess is a documentation bug. -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.J. Lu on 14 Jul 2010 15:50 On Wed, Jul 14, 2010 at 12:36 PM, H. Peter Anvin <hpa(a)zytor.com> wrote: > On 07/14/2010 12:32 PM, H.J. Lu wrote: >> On Wed, Jul 14, 2010 at 12:00 PM, H. Peter Anvin <hpa(a)zytor.com> wrote: >>> On 07/14/2010 11:18 AM, H.J. Lu wrote: >>>> >>>> There are some discussions on: >>>> >>>> http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02001.html >>>> http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00001.html >>>> >>>> Are they related? >>>> >>> >>> Not directly as far as I can tell. >>> >>> The issue is if gcc can ever reorder, duplicate or elide a volatile >>> operation (either asm volatile or a volatile-annotated memory >>> reference.) �In my (and Linus') opinion, this would be an incredibly >>> serious bug. >> >> Is there a gcc bug for this? >> > > Are you asking for a bug report against the documentation? �We're not > sure what the semantics intended by the gcc team to be, which I guess is > a documentation bug. > Documentation bug is also a bug :-). -- H.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: Avi Kivity on 14 Jul 2010 16:20 On 07/14/2010 08:57 PM, Jeremy Fitzhardinge wrote: > Anything else? 1. set up a mapping 2. invlpg or set cr3 3. use the mapping Moving the invlpg will break your code. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- 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 14 Jul 2010 16:50
On 07/14/2010 01:16 PM, Avi Kivity wrote: > On 07/14/2010 08:57 PM, Jeremy Fitzhardinge wrote: >> Anything else? > > 1. set up a mapping > 2. invlpg or set cr3 > 3. use the mapping > > Moving the invlpg will break your code. invlpg uses memory clobbers. All the crX ops seem to use a __force_order variable to sequence them - but it looks like it's done precisely backwards and it's barking mad to do allow write_crX to be reordered with respect to memory ops. Hm, looks like glommer added it surreptitiously while unifying system_32.h and system_64.h (system_32.h relied on asm volatile not being reordered; system_64.h used memory clobbers). 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/ |