RE: [kvm-devel] [PATCH] Refactor hypercall infrastructure

[Nakajima, Jun]

Jeremy Fitzhardinge wrote:
> Nakajima, Jun wrote:
> 
> > Again, 0x40000000 is not Xen specific. If the leaf 0x40000000 is
used
> > for any guest to detect any hypervisor, that would be compelling
> > benefit. For future Xen-specific features, it's safe for Xen to use
> > other bigger leaves (like 0x40001000) because the guest starts
looking
> > at them after detection of Xen.
> > 
> > Likewise if KVM paravirtualization interface (as kind of "open
source
> > paravirtualization interface") is detected in the generic areas (not
in
> > vender-specific), any guest can check the features available without
> > knowing which hypervisor uses which CPUID for that.
> > 
> 
> This just seems a bit grotty.  You're relying on the fact that you can
> overlay Xen's current use of 0x4000000x for the generic interface by
> freezing Xen's current use of 40000000-2.  0x40000000 becomes a more
or
> less useless hypervisor-identification signature (useless because you
> need to assume that leaves 4000000x, x>2 implement the generic
interface
> anyway, where x=1,2 are reserved for Xen (=hypervisor-specific) uses).

No, really. Xen just _implemented_ the generic interface from the
beginning, at least for 0 and 1 (version). The 0x40000002 (hypercall
page) looks specific to Xen, but it can be used for KVM as well, thus
can be generic (or a hypervisor can tell it's not supported by returning
0 pages for hypercall pages). If Xen implements the new generic feature
(defined by 0x40000003, for example), then it returns 40000003 or large
for the max leaf upon CPUID.0x40000000.

> 
> In other words, what mechanism can a guest use to explicitly identify
> the existence of the generic interface?  There needs to be a signature
> for that somewhere.
> 
>     J
So you don't need a signature for that. 

As I wrote before:
1. detect Xen or KVM <the list> using CPUID.0x40000000 
2. Check the version if necessary using CPUID.0x40000001
3. Check the generic features available using CPUID.0x4000000Y, if the
max leaf returned >= 0x4000000Y.

A guest wants to want to know who the hypervior is for practical
purposes (e.g. debuggging) anyway. This is equivalent to what a native
OS would do to detect a generic CPU feature.

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/