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: Tue, 06 Jan 2015 09:42:37 +0100 Message-ID: <54AB9FFD.6070309@redhat.com> References: <8d09c16eb39cbe264417cc66c4aca730af10b70b.1419295081.git.luto@amacapital.net> <20150105152511.GA9172@amt.cnet> <20150105191756.GA31201@amt.cnet> <20150105224858.GA6846@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Gleb Natapov , "xen-devel@lists.xenproject.org" , "linux-kernel@vger.kernel.org" , kvm list To: Marcelo Tosatti , Andy Lutomirski Return-path: In-Reply-To: <20150105224858.GA6846@amt.cnet> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org List-Id: kvm.vger.kernel.org On 05/01/2015 23:48, Marcelo Tosatti wrote: >>> > > But there is no guarantee that vCPU-N has updated its pvti when >>> > > vCPU-M resumes guest instruction execution. >> > >> > Still confused. So we can freeze all vCPUs in the host, then update >> > pvti 1, then resume vCPU 1, then update pvti 0? In that case, we have >> > a problem, because vCPU 1 can observe pvti 0 mid-update, and KVM >> > doesn't increment the version pre-update, and we can return completely >> > bogus results. > Yes. But then the getcpu test would fail (1->0). Even if you have an ABA situation (1->0->1), it's okay because the pvti that is fetched is the one returned by the first getcpu. Paolo