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: <97D612E30E1F88419025B06CB4CF1BE10379EDA0@scsmsx412.amr.corp.intel.com>
Date:	Fri, 14 Sep 2007 23:11:22 -0700
From:	"Nakajima, Jun" <jun.nakajima@...el.com>
To:	"Jeremy Fitzhardinge" <jeremy@...p.org>
Cc:	"Anthony Liguori" <anthony@...emonkey.ws>,
	<kvm-devel@...ts.sourceforge.net>, <linux-kernel@...r.kernel.org>,
	"Avi Kivity" <avi@...ranet.com>
Subject: RE: [kvm-devel] [PATCH] Refactor hypercall infrastructure

Jeremy Fitzhardinge wrote:
> Nakajima, Jun wrote:
> > The hypervisor detection machanism is generic, and the signature
> > returned is implentation specific. Having a list of all hypervisor
> > signatures sounds fine to me as we are detecting vendor-specific
> > processor(s) in the native. And I don't expect the list is large.
> > 
> > 
> 
> I'm confused about what you're proposing.  I was thinking that a
kernel
> looking for the generic hypervisor interface would check for a
specific
> signature at some cpuid leaf, and then go about using it from there.
If
> not, how does is it supposed to detect the generic hypervisor
interface?
> 
>     J

I'm suggesting that we use CPUID.0x4000000Y (Y: TBD, e.g. 6) for Linux
paravirtualization.  The ebx, ecx and edx return the Linux
paravirtualization features available on that hypervisor. Those features
are defined architecturally (not VMM specific).

Like CPUID.0, CPUID.0x40000000 is used to detect the hypervisor with the
vendor identification string returned in ebx, edx, and ecx (as we are
doing in Xen). The eax returns the max leaf (which is 0x40000002 on Xen
today). And like CPUID.1, CPUID.0x40000001 returns the version number in
eax, and each VMM should be able to define a number of VMM-specific
features available in ebx, ecx, and edx returned (which are reserved,
i.e. not used in Xen today). 

Suppose we knew (i.e. tested) Xen and KVM supported Linux
paravirtualization, the Linux code does:
1. detect Xen or KVM <the list> using CPUID.0x40000000 
2. Check the version if necessary using CPUID.0x40000001
3. Check the Linux paravirtualization features available using
CPUID.0x4000000Y.

Jun
---
Intel Open Source Technology Center
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ