From mboxrd@z Thu Jan 1 00:00:00 1970 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Subject: Re: x86: kvm: Revert "remove sched notifier for cross-cpu migrations" Date: Thu, 26 Mar 2015 21:10:02 +0100 Message-ID: <20150326201001.GB27093@potion.brq.redhat.com> References: <20150323232151.GA12772@amt.cnet> <20150324153412.GB21710@potion.brq.redhat.com> <20150325110814.GE21522@potion.brq.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Marcelo Tosatti , kvm-devel , stable , Paolo Bonzini To: Andy Lutomirski Return-path: Content-Disposition: inline In-Reply-To: Sender: stable-owner@vger.kernel.org List-Id: kvm.vger.kernel.org 2015-03-26 11:47-0700, Andy Lutomirski: > On Wed, Mar 25, 2015 at 4:08 AM, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > > + /* A guest can read other VCPU's kvmclock; specification sa= ys 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 > > */ >=20 > 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?)