linux-kernel - Re: [PATCH 0/6] KVM support for TSC scaling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110222111111.GG16508@amd.com>
Date:	Tue, 22 Feb 2011 12:11:11 +0100
From:	"Roedel, Joerg" <Joerg.Roedel@....com>
To:	Avi Kivity <avi@...hat.com>
CC:	Marcelo Tosatti <mtosatti@...hat.com>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Zachary Amsden <zamsden@...hat.com>
Subject: Re: [PATCH 0/6] KVM support for TSC scaling

On Tue, Feb 22, 2011 at 05:41:53AM -0500, Avi Kivity wrote:
> On 02/22/2011 12:35 PM, Roedel, Joerg wrote:
> > >  This doesn't really work, since we don't know on what host the TSC
> > >  calibration loop ran:
> > >
> > >  - start guest on host H1
> > >  - migrate it around, now it's on host H2
> > >  - guest reboots, reruns calibration loop
> > >  - migrate it around some more, now it's on host H3
> > >  - migrate to host with tsc multiplier Hnew
> > >
> > >  So, what should we set the multiplier to? H1, H2, or H3's tsc rate?
> >
> > This scenario doesn't matter. If the guest already detected its TSC to
> > be unstable there is nothing we can do and it doesn't really matter what
> > we set the tsc frequency to. Therefore software will always set the
> > guest tsc frequency to the same value it had on the last host.
> 
> Ok, so your scenario is
> 
> - boot on host H1
> - no intervening migrations
> - migrate to host Hnew
> - all succeeding migrations are only to new hosts or back to H1
> 
> This is somewhat artificial, and not very different from an all-new cluster.

This is at least the scenario where the new hardware feature will make
sense. Its clear that if you migrate a guest between hosts without
tsc-scaling will make the tsc appear unstable for the guest. This is
basically the same situation as we have today.
In fact, for older hosts the feature can be emulated in software by
trapping tsc accesses from the guest. Isn't this what Zachary has been
working on? During my implementation I understood tsc-scaling as a
hardware supported way to do this. And thats the reason I implemented it
the way it is.

> [the whole thing is kind of sad; we went through a huge effort to make 
> clocks work on virtual machines in spite of the tsc issues; then we have 
> a hardware solution, but can't use it because of old hardware.  Same 
> thing happens with the effort put into shadow in the pre-npt days]

The shadow code has a revivial as it is required for emulating
nested-npt and nested-ept, so the effort still has value :)

	Joerg

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/