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

[Paolo Bonzini <pbonzini@redhat.com>]

On 26/03/2015 21:10, Radim Krčmář wrote:
> 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?)

It probably does so if they hit multiple cache lines.  Within a cache
line, probably not.

We can add kvm_map/unmap_guest_cached and then use __put_user.

Paolo