From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marcelo Tosatti <mtosatti@redhat.com>
Subject: Re: x86: kvm: Revert "remove sched notifier for cross-cpu migrations"
Date: Wed, 25 Mar 2015 19:41:45 -0300
Message-ID: <20150325224145.GA5928@amt.cnet>
References: <20150323232151.GA12772@amt.cnet>
 <20150324153412.GB21710@potion.brq.redhat.com>
 <CALCETrVR6zb6Nvb+tV9qHvDRtx3fhsinBrd9YwNgT6cvAg4a3Q@mail.gmail.com>
 <20150325110814.GE21522@potion.brq.redhat.com>
 <20150325125212.GC21710@potion.brq.redhat.com>
 <20150325212851.GB3649@amt.cnet>
 <CALCETrU5jdzp2MYOMobgO8MKtDyXsMFCZsJWQFhHnv_pxQbaxQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: kvm list <kvm@vger.kernel.org>, Radim Krcmar <rkrcmar@redhat.com>,
	stable <stable@vger.kernel.org>,
	Paolo Bonzini <pbonzini@redhat.com>
To: Andy Lutomirski <luto@amacapital.net>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:38869 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1750807AbbCYWmB (ORCPT <rfc822;kvm@vger.kernel.org>);
	Wed, 25 Mar 2015 18:42:01 -0400
Content-Disposition: inline
In-Reply-To: <CALCETrU5jdzp2MYOMobgO8MKtDyXsMFCZsJWQFhHnv_pxQbaxQ@mail.gmail.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Wed, Mar 25, 2015 at 03:33:10PM -0700, Andy Lutomirski wrote:
> On Mar 25, 2015 2:29 PM, "Marcelo Tosatti" <mtosatti@redhat.com> wrot=
e:
> >
> > On Wed, Mar 25, 2015 at 01:52:15PM +0100, Radim Kr=C4=8Dm=C3=A1=C5=99=
 wrote:
> > > 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 consiste=
nt data
> > > > from kvmclock.  (VCPU can change outside of this loop too, so i=
t doesn't
> > > > matter if we return a value not fit for this VCPU.)
> > > >
> > > > I think we could drop the second __getcpu if our kvmclock was b=
eing
> > > > 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.
> >
> > The vdso code is only used if host has synchronized tsc.
> >
> > But you have to handle the case where host goes from synchronized t=
sc to
> > unsynchronized tsc (see the clocksource notifier in the host side).
> >
>=20
> Can't we change the host to freeze all vcpus and clear the stable bit
> on all of them if this happens?  This would simplify and speed up
> vclock_gettime.
>=20
> --Andy

Seems interesting to do on 512-vcpus, but sure, could be done.