From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 6/24] Implement reading and writing of VMX MSRs Date: Wed, 23 Jun 2010 11:24:24 +0300 Message-ID: <4C21C4B8.40808@redhat.com> References: <1276431753-nyh@il.ibm.com> <201006131225.o5DCPctX012929@rice.haifa.ibm.com> <4C15EB93.6040101@redhat.com> <20100623081318.GA23957@fermat.math.technion.ac.il> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: "Nadav Har'El" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:11129 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751209Ab0FWIY2 (ORCPT ); Wed, 23 Jun 2010 04:24:28 -0400 In-Reply-To: <20100623081318.GA23957@fermat.math.technion.ac.il> Sender: kvm-owner@vger.kernel.org List-ID: 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