On Sep 3, 2008, at 9:55 AM, Gerd Hoffmann wrote:
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.
I guess I didn't express myself correctly, sorry for that :-). I think
that kvm kernel module capabilities should be masked out in the kernel
module, while "other" stuff, like migration masking or additional
CPUIDs (do these work atm?) should of course reside in the userspace.
The code I was referring to was the removal of the NX bit and the SVM
bit. These are definitely kernel capabilities. If the kernel module
doesn't implement these, it should just mask them out instead of
having userspace figure out what's there and what isn't.
I hope I didn't completely confuse everybody now :-). On a sidenote:
We really need to switch to the newer cpuid kernel<->userspace
interface. The way it currently is, CPUID 4 is severely broken.
Alex
--
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
