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: Wed, 25 Mar 2015 13:52:15 +0100 Message-ID: <20150325125212.GC21710@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: Received: from mx1.redhat.com ([209.132.183.28]:47333 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751220AbbCYMwU (ORCPT ); Wed, 25 Mar 2015 08:52:20 -0400 Content-Disposition: inline In-Reply-To: <20150325110814.GE21522@potion.brq.redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 2015-03-25 12:08+0100, Radim Kr=C4=8Dm=C3=A1=C5=99: > Reverting the patch protects us from any migration, but I don't think= we > need to care about changing VCPUs as long as we read a consistent dat= a > from kvmclock. (VCPU can change outside of this loop too, so it does= n't > matter if we return a value not fit for this VCPU.) >=20 > I think we could drop the second __getcpu if our kvmclock was being > handled better; maybe with a patch like the one below: The second __getcpu is not neccessary, but I forgot about rdtsc. We need to either use rtdscp, know the host has synchronized tsc, or monitor VCPU migrations. Only the last one works everywhere.