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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]