Hi, > On a sidenote I'm really not fond of the userspace CPUID capability > restrictions in the first place. Shouldn't this all be determined in the > kernel module? It doesn't make since IMHO to restrict NX usage from > userspace. The kernel module knows best what it's capable of.
I think cpuid handling will be a quite interesting when it comes to merging qemu and kvm. Doing it completely in the kernel isn't going to work. There are several reasons why you might want to change the cpuid presented to the guest. First, you might want to mask out cpuid bits not supported by all machines in your pool, for migration compatibility. Second, you might want to present a specific CPU to the guest (like qemu -cpu pentium). At least as close as possible, of course there are some restrictions. I think even if you mask out the sse cpuid bit sse instructions will actually work. Also having a virtual intel cpu on amd and visa versa probably isn't going to work unless we'll fall back to the emulator for the missing instructions. Third, there is the hypervisor cpuid range (0x40000000+). That one needs to be configurable by userspace as well. cheers, Gerd -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
