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: <0B53E02A2965CE4F9ADB38B34501A3A1571841FE@orsmsx505.amr.corp.intel.com>
Date:	Fri, 26 Sep 2008 21:52:26 -0700
From:	"Nakajima, Jun" <jun.nakajima@...el.com>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	"akataria@...are.com" <akataria@...are.com>,
	Ingo Molnar <mingo@...e.hu>,
	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>,
	Zach Amsden <zach@...are.com>, Daniel Hecht <dhecht@...are.com>
Subject: RE: Use CPUID to communicate with the hypervisor.

On 9/26/2008 6:55:54 PM, H. Peter Anvin wrote:
> Nakajima, Jun wrote:
> > > >
> > > Agreed.  However, that's obviously beyond our immediate control.
> >
> > Well, actually it's under full control of the Linux community
> > because the _kernel_ defines such virtual or semi-hardware features.
> > I'm not sure if that particular value (0x40000010) is proper, but we
> > should be able to pick reasonable ones/ranges.
> >
>
> Uhm, no, they're defined by the _hypervisor_.
>
>         -hpa

Obviously the hypervisor implements such features, and the features available/exposed are up to the hypervisor. My point is that the kernel community can define such generic hypervisor features for Linux because the Linux kernel code needs to be modified anyway. Otherwise, each VMM vender could start changing the kernel in a random fashion. Or nothing happens...

Today each hypervisor already defines and implements such features (or API), and they would need some kind of translation layer to support such Linux hypervisor features (if defined) or they just need to write code.

Having said that,
+       if (cpu_has_hypervisor) {
+               max_cpuid_leaf = cpuid_eax(HYPERVISOR_INFO_LEAF);
+               if (max_cpuid_leaf >= HYPERVISOR_TIMING_LEAF) {
+                       tsc_khz = cpuid_eax(HYPERVISOR_TIMING_LEAF);
+                       printk(KERN_INFO
+                               "TSC frequency read from hypervisor\n");
+                       return tsc_khz;

To have more flexibility and extendability in terms of "supported/unsupported", I think we should use the bitmap first to detect the features as the native does. For example, some hypervisor does not want to implement HYPERVISOR_TIMING_LEAF, but want to implement something higher one (which could be defined in the future).

             .
Jun Nakajima | Intel Open Source Technology Center