linux-kernel - Re: Use CPUID to communicate with the hypervisor.

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: <1222792958.7330.16.camel@bodhitayantram.eng.vmware.com>
Date:	Tue, 30 Sep 2008 09:42:38 -0700
From:	Zachary Amsden <zach@...are.com>
To:	Gerd Hoffmann <kraxel@...hat.com>
Cc:	Alok Kataria <akataria@...are.com>, Ingo Molnar <mingo@...e.hu>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	the arch/x86 maintainers <x86@...nel.org>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	"avi@...hat.com" <avi@...hat.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Daniel Hecht <dhecht@...are.com>,
	"Jun.Nakajima@...el.Com" <Jun.Nakajima@...el.Com>
Subject: Re: Use CPUID to communicate with the hypervisor.

On Tue, 2008-09-30 at 01:11 -0700, Gerd Hoffmann wrote:
> Alok Kataria wrote:

> Well, that should be clearly defined, that is my point.  When asking the
> hypervisor for the tsc instead of running a calibration loop, then we
> have a small bit of paravirtualization:  The guest is aware that it runs
> on a hypervisor and just asks it directly.  So while we are at it we can
> also define a way to communicate tsc freq changes between host and
> guest, so the cost of trap'n'emulate tsc reads can be avoided.  Or we
> define "tsc is constant" and leave it to the hypervisor to make sure it

For our purposes, we define TSC is constant.

> actually appears being constant to the guest, even in case it changes on
> the host.  But it must be defined one way or another, so the guest knows
> whenever it should expect the tsc frequency change or not.  And in case
> we allow tsc changes, we also need a way to signal that to the guest.

Non-constant TSCs probably won't want to use CPUID based retreival, due
to the extra trap it would require to read TSC frequency, it can't be
done at every TSC read (or else, virtualizing TSC frequency has the same
cost and you haven't won anything by making it dynamic).  It's also not
clean to issue interrupts to the guest telling it TSC frequency has
changed because the guest may not notice the interrupt before making
computations using the old value, and multiple rapid changes would
require multiple interrupt injections for each affected guest.

> Is the tsc cpu leaf interface set in stone already (aka implemented in
> vmware versions released to public)?

Not to my knowledge.

Zach

--
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/