From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [RFC 2/2] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader Date: Wed, 07 Jan 2015 06:38:23 +0100 Message-ID: <54ACC64F.6030304__10050.0472276055$1420609262$gmane$org@redhat.com> References: <8d09c16eb39cbe264417cc66c4aca730af10b70b.1419295081.git.luto@amacapital.net> <20150105152511.GA9172@amt.cnet> <20150105191756.GA31201@amt.cnet> <20150105224858.GA6846@amt.cnet> <54AB9FFD.6070309@redhat.com> <54ABCE85.6070004@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y8jK8-0004O3-9R for xen-devel@lists.xenproject.org; Wed, 07 Jan 2015 05:38:28 +0000 Received: by mail-we0-f182.google.com with SMTP id w62so527377wes.13 for ; Tue, 06 Jan 2015 21:38:26 -0800 (PST) In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andy Lutomirski Cc: Gleb Natapov , "xen-devel@lists.xenproject.org" , Marcelo Tosatti , "linux-kernel@vger.kernel.org" , kvm list List-Id: xen-devel@lists.xenproject.org On 06/01/2015 17:56, Andy Lutomirski wrote: > Still no good. We can migrate a bunch of times so we see the same CPU > all three times There are no three times. The CPU you see here: >> >> >> // ... compute nanoseconds from pvti and tsc ... >> rmb(); >> } while(v != pvti->version); is the same you read here: >> cpu = get_cpu(); The algorithm is: 1) get a consistent (cpu, version, tsc) 1.a) get cpu 1.b) get pvti[cpu]->version, ignoring low bit 1.c) get (tsc, cpu) 1.d) if cpu from 1.a and 1.c do not match, loop 1.e) if pvti[cpu] was being updated, we'll loop later 2) compute nanoseconds from pvti[cpu] and tsc 3) if pvti[cpu] changed under our feet during (2), i.e. version doesn't match, retry. As long as the CPU is consistent between get_cpu() and rdtscp(), there is no problem with migration, because pvti is always accessed for that one CPU. If there were any problem, it would be caught by the version check. Writing it down with two nested do...whiles makes it clearer IMHO. > and *still* don't get a consistent read, unless we > play nasty games with lots of version checks (I have a patch for that, > but I don't like it very much). The patch is here: > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vdso_paranoia&id=a69754dc5ff33f5187162b5338854ad23dd7be8d > > but I don't like it. > > Thus far, I've been told unambiguously that a guest can't observe pvti > while it's being written, and I think you're now telling me that this > isn't true and that a guest *can* observe pvti while it's being > written while the low bit of the version field is not set. If so, > this is rather strongly incompatible with the spec in the KVM docs. Where am I saying that? Paolo