From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: [PATCH 3/24] Implement VMXON and VMXOFF Date: Tue, 15 Jun 2010 17:18:17 -0300 Message-ID: <20100615201817.GB3395@amt.cnet> References: <1276431753-nyh@il.ibm.com> <201006131224.o5DCO63N012897@rice.haifa.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: avi@redhat.com, kvm@vger.kernel.org To: "Nadav Har'El" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:52028 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754915Ab0FOXsO (ORCPT ); Tue, 15 Jun 2010 19:48:14 -0400 Content-Disposition: inline In-Reply-To: <201006131224.o5DCO63N012897@rice.haifa.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: On Sun, Jun 13, 2010 at 03:24:06PM +0300, Nadav Har'El wrote: > This patch allows a guest to use the VMXON and VMXOFF instructions, and > emulates them accordingly. Basically this amounts to checking some > prerequisites, and then remembering whether the guest has enabled or disabled > VMX operation. > > Signed-off-by: Nadav Har'El > --- > --- .before/arch/x86/kvm/vmx.c 2010-06-13 15:01:28.000000000 +0300 > +++ .after/arch/x86/kvm/vmx.c 2010-06-13 15:01:28.000000000 +0300 > @@ -117,6 +117,16 @@ struct shared_msr_entry { > u64 mask; > }; > > +/* The nested_vmx structure is part of vcpu_vmx, and holds information we need > + * for correct emulation of VMX (i.e., nested VMX) on this vcpu. For example, > + * the current VMCS set by L1, a list of the VMCSs used to run the active > + * L2 guests on the hardware, and more. > + */ > +struct nested_vmx { > + /* Has the level1 guest done vmxon? */ > + bool vmxon; > +}; > + > struct vcpu_vmx { > struct kvm_vcpu vcpu; > struct list_head local_vcpus_link; > @@ -168,6 +178,9 @@ struct vcpu_vmx { > u32 exit_reason; > > bool rdtscp_enabled; > + > + /* Support for guest hypervisors (nested VMX) */ > + struct nested_vmx nested; > }; > > static inline struct vcpu_vmx *to_vmx(struct kvm_vcpu *vcpu) > @@ -3353,6 +3366,93 @@ static int handle_vmx_insn(struct kvm_vc > return 1; > } > > +/* Emulate the VMXON instruction. > + * Currently, we just remember that VMX is active, and do not save or even > + * inspect the argument to VMXON (the so-called "VMXON pointer") because we > + * do not currently need to store anything in that guest-allocated memory > + * region. Consequently, VMCLEAR and VMPTRLD also do not verify that the their > + * argument is different from the VMXON pointer (which the spec says they do). > + */ > +static int handle_vmon(struct kvm_vcpu *vcpu) > +{ > + struct kvm_segment cs; > + struct vcpu_vmx *vmx = to_vmx(vcpu); > + > + /* The Intel VMX Instruction Reference lists a bunch of bits that > + * are prerequisite to running VMXON, most notably CR4.VMXE must be > + * set to 1. Otherwise, we should fail with #UD. We test these now: > + */ > + if (!nested) { > + kvm_queue_exception(vcpu, UD_VECTOR); > + return 1; > + } > + > + if (!(vcpu->arch.cr4 & X86_CR4_VMXE) || > + !(vcpu->arch.cr0 & X86_CR0_PE) || kvm_read_cr0_bits, kvm_read_cr4_bits.