Re: [PATCH 6/24] Implement reading and writing of VMX MSRs

[Avi Kivity <avi@redhat.com>]

On 06/23/2010 11:13 AM, Nadav Har'El wrote:
> On Mon, Jun 14, 2010, Avi Kivity wrote about "Re: [PATCH 6/24] Implement reading and writing of VMX MSRs":
>    
>> On 06/13/2010 03:25 PM, Nadav Har'El wrote:
>>      
>>> When the guest can use VMX instructions (when the "nested" module option is
>>> on), it should also be able to read and write VMX MSRs, e.g., to query
>>> about
>>> VMX capabilities. This patch adds this support.
>>>        
>> ...
>>      
>>> @@ -702,7 +702,11 @@ static u32 msrs_to_save[] = {
>>>        
>> ...
>>      
>>> +	MSR_IA32_FEATURE_CONTROL,  MSR_IA32_VMX_BASIC,
>>>        
>> ...
>> These are read only from the guest point of view, but we need write
>> support from the host to allow for tuning the features exposed to the guest.
>>      
> Hi,
>
> I'm afraid I did not understand what you meant.
> There is a KVM_SET_MSRS ioctl, but it appears to do the same thing that a
> guest's WRMSR would do, i.e., eventually call nested_vmx_set_msr().
> In some of these MSRs (like VMX_BASIC) there's no point, if I understand
> correctly, for the guest or the host to change anything (e.g., what would it
> mean to change the VMCS length or revision id?). In others like
> VMX_PROCBASED_CTLS I guess that we can allow it to be set if it doesn't try
> to enable something not supported - is that what you had in mind? Or did you
> mean something else?
>    

I meant allowing host userspace to change the capability MSRs, such as 
VMX_PROCBASED_CTLS.  For example, if live migrating from a version of 
kvm that does not support EPT to a version that does, we want to 
downgrade the reported capabilities so the guest sees exactly the same 
capabilities.

It's the same thing we do with cpuid.

-- 
error compiling committee.c: too many arguments to function