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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
