On Wed, Mar 03, 2010 at 11:58:49PM +0100, Alexander Graf wrote:
>
> Am 03.03.2010 um 20:15 schrieb Joerg Roedel <joerg.roe...@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.
> 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).
Joerg
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
