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 for Android: free password hash cracker in your pocket

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

Message-ID: <0B53E02A2965CE4F9ADB38B34501A3A15718417A@orsmsx505.amr.corp.intel.com>
Date:	Fri, 26 Sep 2008 17:59:06 -0700
From:	"Nakajima, Jun" <jun.nakajima@...el.com>
To:	"H. Peter Anvin" <hpa@...or.com>,
	"akataria@...are.com" <akataria@...are.com>
CC:	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 5:32:26 PM, H. Peter Anvin wrote:
> Alok Kataria wrote:
> > > >
> > > This is great, obviously... although we'll have to deal with
> > > legacy methods for a while if not indefinitely (just as we have to
> > > for pre-CPUID processors).
> >
> > Ok, do you think we should keep those (legacy) interfaces separate
> > so that they can be phased out whenever the time is right.
> >
>
> I don't, realistically, think we can phase them out for a very long
> time, and then it's usually a "why bother".  What we want to do is
> abstract them so they don't make the rest of the code suck.
>
> >
> > I would like to see this as a generic hypervisor way to get
> > frequency rather than a VMware specific thingy.
> > > In order for *that* to be safe, you'd have to have well-defined
> > > ranges for different virtualization vendors where each of them can
> > > define their own stuff.
> >
> > My motivation for doing this is to have a standard across all the
> > hypervisor's. If all the different hypervisor guys can come to some
> > sought of consensus on the various hypervisor leafs that would help
> > keep this simple and a lot more maintainable.
> >
>
> 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.

>
>         -hpa
             .
Jun Nakajima | Intel Open Source Technology Center