From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: IA32_FEATURE_CONTROL MSR in nested virt Date: Wed, 3 Jul 2013 12:14:46 +0300 Message-ID: <20130703091446.GH18508@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm , Paolo Bonzini , Jan Kiszka To: Arthur Chunqi Li Return-path: Received: from mx1.redhat.com ([209.132.183.28]:56111 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754270Ab3GCJOu (ORCPT ); Wed, 3 Jul 2013 05:14:50 -0400 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Jul 03, 2013 at 04:24:33PM +0800, Arthur Chunqi Li wrote: > Hi Gleb and Paolo, > When I write test cases for nested virt and found that reading/writing > IA32_FEATURE_CONTROL will be simply ignored or return 0 (in > arch/x86/kvm/vmx.c) in VM. Checking this MSR will be done by some > hypervisors (e.g. NOVA) and may cause error then, so it is necessary > to behave right when read/write it in VM. > NOVA cannot write to it and expect anything but #GP since BIOSes usually lock the MSR. So I agree with Paolo about returning 5 on read and #GP on write. Later we can implement locking functionality and make BIOS enable/disable nested vmx. > Are there any difficulties to handle this MSR? I have two solutions. > The first one is return the value of physical CPU's and always return > true when write. This is simple but may behave as if it is a VM > because write to it after VMXON will not return GP exception. This > solution can solve most basic problems since this MSR is not commonly > used. Another solution is adding a field in VCPU to handle this MSR. > This is a complex but better method. > > I think I can complete this if needed. > > Thanks, > Arthur > > -- > Arthur Chunqi Li > Department of Computer Science > School of EECS > Peking University > Beijing, China -- Gleb.