Re: [PATCH 2/2] Allow the SVM CPUID bit in a VM

[Avi Kivity <avi@qumranet.com>]

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