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