From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 17/30] nVMX: Prepare vmcs02 from vmcs01 and vmcs12 Date: Mon, 09 May 2011 13:12:17 +0300 Message-ID: <4DC7BE01.80709@redhat.com> References: <1304842511-nyh@il.ibm.com> <201105080823.p488Nuj8018238@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, gleb@redhat.com To: "Nadav Har'El" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:41251 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751114Ab1EIKM0 (ORCPT ); Mon, 9 May 2011 06:12:26 -0400 In-Reply-To: <201105080823.p488Nuj8018238@rice.haifa.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: On 05/08/2011 11:23 AM, Nadav Har'El wrote: > This patch contains code to prepare the VMCS which can be used to actually > run the L2 guest, vmcs02. prepare_vmcs02 appropriately merges the information > in vmcs12 (the vmcs that L1 built for L2) and in vmcs01 (our desires for our > own guests). > +/* > + * prepare_vmcs02 is called when the L1 guest hypervisor runs its nested > + * L2 guest. L1 has a vmcs for L2 (vmcs12), and this function "merges" it > + * with L0's requirements for its guest (a.k.a. vmsc01), so we can run the L2 > + * guest in a way that will both be appropriate to L1's requests, and our > + * needs. In addition to modifying the active vmcs (which is vmcs02), this > + * function also has additional necessary side-effects, like setting various > + * vcpu->arch fields. > + */ > +static int prepare_vmcs02(struct kvm_vcpu *vcpu, struct vmcs12 *vmcs12) > +{ > + vmcs_write64(VMCS_LINK_POINTER, vmcs12->vmcs_link_pointer); I think this is wrong - anything having to do with vmcs linking will need to be emulated, we can't let the cpu see the real value (and even if we don't emulate, we have to translate addresses like you do for the apic access page. > + vmcs_write64(TSC_OFFSET, > + vmx->nested.vmcs01_tsc_offset + vmcs12->tsc_offset); This is probably wrong (everything with time is probably wrong), but we can deal with it (much) later. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.