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. > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
