Re: [PATCH 2/2] QEMU-KVM: Ask kernel about supported svm features

[Alexander Graf <agraf@suse.de>]

Joerg Roedel wrote:
> On Wed, Mar 03, 2010 at 11:58:49PM +0100, Alexander Graf wrote:
>   
>> Am 03.03.2010 um 20:15 schrieb Joerg Roedel <joerg.roedel@amd.com>:
>>
>>     
>>> This patch adds code to ask the kernel about the svm
>>> features it supports for its guests and propagates them to
>>> the guest. The new capability is necessary because the old
>>> behavior of the kernel was to just return the host svm
>>> features but every svm-feature needs emulation in the nested
>>> svm kernel code. The new capability indicates that the
>>> kernel is aware of that when returning svm cpuid
>>> information.
>>>       
>> Do we really need that complexity?
>>     
>
> Yes :-)
>
>   
>> By default the kernel masks out unsupported cpuid features anyway. So
>> if we don't have npt guest support (enabled), the kernel module should
>> just mask it out.
>>     
>
> The kernel does not mask out unsupported features. I also don't think
> this would be a good idea because userspace won't be aware of that
> change.
> Fact it, we need a way to report the npt-emulation feature to userspace
> because old kvm versions don't support it. So we can't pass the npt bit
> unconditionally. The get_supported_cpuid ioctl is the way of choice
> here.
> But the current way get_supported_cpuid works for function 0x8000000a is
> broken because it reports the host features. This was the reason to
> introduce the new capability.
>   

That's what I mean by masking. It used to happen implicitly, but has
been changed to directly asking the kernel for its capabilities apparently.

>> IOW, always passing npt should work. No capability should make it
>> get masked out.
>>     
>
> No, as stated above always passing npt-bit into the kernel and letting
> it mask out there isn't a good way to go (not only because this will
> break if you use new qem-kvm on old kernel-space).
>   

Ah, so we did have a bug in old KVM kernel modules. Sigh.


Alex