Nakajima, Jun wrote:
I don't understand the purpose of returning the max leaf. Who is that
information useful for?
Well, this is the key info to the user of CPUID. It tells which leaves
are valid to use. Otherwise, the user cannot tell whether the results of
CPUID.0x4000000N are valid or not (i.e. junk). BTW, this is what we are
doing on the native (for the leaf 0, 0x80000000, for example). The fact
that Xen returns 0x40000002 means it only uses 3 leaves today.
Then it's just a version ID. You pretty much have to treat it as a
version id because if it returns 0x4000 0003 and you only know what 0002
is, then you can't actually use it.
I much prefer the current use of CPUID in KVM. If 1000 returns the KVM
signature, then 1001 *must* be valid and contain a set of feature bits.
If we wish to use additional CPUID leaves in the future, then we can
just use a feature bit. The real benefit to us is that we can use a
discontiguous set of leaves whereas the Xen approach is forced to use a
linear set (at least for the result to be meaningful).
I like Jeremy's suggesting of starting with 0x40001000 for KVM. Xen
has
an established hypercall interface and that isn't going to change.
However, in the future, if other Operating Systems (like the BSDs)
choose to implement the KVM paravirtualization interface, then that
leaves open the possibility for Xen to also support this interface to
get good performance for those OSes. It's necessary to be able to
support both at once if you wish to support these interfaces without
user interaction.
Using CPUID.0x4000000N (N > 2) does not prevent Xen from doing that,
either. If you use 0x40001000, 1) you need to say the leaves from
0x40000000 through 0x40001000 are all valid, OR 2) you create/fork a
new/odd leaf (with 0x1000 offset) repeating the detection redundantly.
Why do 0000-1000 have to be valid? Xen is not going to change what they
have today--they can't. However, if down the road, they decided that
since so many guests use KVM's paravirtualization interface other than
Linux, there's value in supporting it, by using 1000, they can.
There's no tangible benefit to us to use 0x40000000. Therefore I'm
inclined to lean toward making things easier for others.
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.
I'm starting to lean toward just using 0000. If for no other reason
than the hypercall space is unsharable.
Regards,
Anthony Liguori
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.
Regards,
Anthony Liguori
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
Jun
---
Intel Open Source Technology Center
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
