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@xxxxxxx>: >> >> >>> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
