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