From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 3/24] Implement VMXON and VMXOFF Date: Mon, 14 Jun 2010 11:21:36 +0300 Message-ID: <4C15E690.3000707@redhat.com> References: <1276431753-nyh@il.ibm.com> <201006131224.o5DCO63N012897@rice.haifa.ibm.com> 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]:21348 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754325Ab0FNIVk (ORCPT ); Mon, 14 Jun 2010 04:21:40 -0400 In-Reply-To: <201006131224.o5DCO63N012897@rice.haifa.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: On 06/13/2010 03:24 PM, 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. > > Should probably reorder with next patch. > +/* 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. > + */ > Please (here and elsewhere) use the standard kernel style for multiline comments - start with /* on a line by itself. > > +/* 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) || > + (vmx_get_rflags(vcpu)& X86_EFLAGS_VM)) { > + kvm_queue_exception(vcpu, UD_VECTOR); > + return 1; > + } > + > + vmx_get_segment(vcpu,&cs, VCPU_SREG_CS); > + if (is_long_mode(vcpu)&& !cs.l) { > + kvm_queue_exception(vcpu, UD_VECTOR); > + return 1; > + } > + > + if (vmx_get_cpl(vcpu)) { > + kvm_inject_gp(vcpu, 0); > + return 1; > + } > + > + vmx->nested.vmxon = 1; > = true > + > + skip_emulated_instruction(vcpu); > + return 1; > +} > Need to block INIT signals in the local apic as well (fine for a separate patch). -- error compiling committee.c: too many arguments to function