linux-kernel - Re: [kvm-devel] [PATCH] Refactor hypercall infrastructure

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]

Date:	Mon, 17 Sep 2007 13:27:10 -0500
From:	Anthony Liguori <aliguori@...ibm.com>
To:	"Nakajima, Jun" <jun.nakajima@...el.com>
CC:	Jeremy Fitzhardinge <jeremy@...p.org>,
	kvm-devel@...ts.sourceforge.net, Avi Kivity <avi@...ranet.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [kvm-devel] [PATCH] Refactor hypercall infrastructure

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 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/