Alexander Graf wrote:
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.
But then userspace needs to know when capabilities userspace actually sees.
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.
The flow I have in mind is:
- kernel exports which cpuid bits it supports (global information; not
tied to a guest; this way it can be used to calculate g-c-d)
- userspace merges this information with its own ideas
- userspace tells the kernel what cpuid bits to present to the guest
(lying is allowed)
This gives the maximum flexibility and visibility.
NX and SVM are masked for backward compatibility with older userspace;
we could probably remove this masking now.
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.
There is a new interface in place (quite old by now), unfortunately it
isn't used by qemu.
--
error compiling committee.c: too many arguments to function
--
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
