Re: x86: kvm: Revert "remove sched notifier for cross-cpu migrations"

["Radim Krčmář" <rkrcmar@redhat.com>]

2015-03-26 11:47-0700, Andy Lutomirski:
> On Wed, Mar 25, 2015 at 4:08 AM, Radim Krčmář <rkrcmar@redhat.com> wrote:
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > +       /* A guest can read other VCPU's kvmclock; specification says that
> > +        * version is odd if data is being modified and even after it is
> > +        * consistent.
> > +        * We write three times to be sure.
> > +        *  1) update version to odd number
> > +        *  2) write modified data (version is still odd)
> > +        *  3) update version to even number
> > +        *
> > +        * TODO: optimize
> > +        *  - only two writes should be enough -- version is first
> > +        *  - the second write could update just version
> >          */
> 
> The trouble with this is that kvm_write_guest_cached seems to
> correspond roughly to a "rep movs" variant, and those are weakly
> ordered.  As a result, I don't really know whether they have
> well-defined semantics wrt concurrent reads.  What we really want is
> just "mov".

Ah, so the first optimization TODO is not possible, but stores are
weakly ordered only within one rep movs.   We're safe if compiler
outputs three mov-like instructions.

(Btw. does current hardware reorder string stores?)