From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 07/29] nVMX: Hold a vmcs02 for each vmcs12 Date: Sun, 06 Feb 2011 11:16:16 +0200 Message-ID: <4D4E66E0.3060209@redhat.com> References: <1296116987-nyh@il.ibm.com> <201101270833.p0R8XQ4w002480@rice.haifa.ibm.com> <4D45372E.2050605@redhat.com> <20110203125732.GA19503@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, gleb@redhat.com To: "Nadav Har'El" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:46547 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751843Ab1BFJQ1 (ORCPT ); Sun, 6 Feb 2011 04:16:27 -0500 In-Reply-To: <20110203125732.GA19503@fermat.math.technion.ac.il> Sender: kvm-owner@vger.kernel.org List-ID: On 02/03/2011 02:57 PM, Nadav Har'El wrote: > On Sun, Jan 30, 2011, Avi Kivity wrote about "Re: [PATCH 07/29] nVMX: Hold a vmcs02 for each vmcs12": > >.. > > >+static int nested_create_current_vmcs(struct kvm_vcpu *vcpu) > > >+{ > >... > > >+ if (vmx->nested.vmcs02_num>= NESTED_MAX_VMCS) > > >+ return -ENOMEM; > > > > I asked to replace this by dropping the entire vmcs02_list (or perhaps > > just its tail). > > Hi, here is a completely rewritten patch. > > Now we make no guarantee to keep one vmcs02 for each vmcs12. Rather, we > have a limited pool of vmcs02. If we can find the same vmcs02 that we > previously used for the current vmcs12. Otherwise, we can take any of them > (we take the least recently used) and just use that. Of course, if the > pool is not yet fool, we can also allocate a new vmcs02. > > The current default size for the pool is 1, meaning that we just keep one > vmcs02 (per vcpu) for use in any L2, potentially many of them. Because in > this version prepare_vmcs02 each time sets all vmcs02 fields, and doesn't > try to avoid setting rarely modified fields, there's nothing to gain by > trying to start from the previous vmcs02 used to run a certain L2. > In the future, when we do have an optimized prepare_vmcs02 which doesn't > set every field each time, it will make sense to increase the pool size. > > > > Subject: [PATCH 07/29] nVMX: Introduce vmcs02: VMCS used to run L2 > > We saw in a previous patch that L1 controls its L2 guest with a vcms12. > L0 needs to create a real VMCS for running L2. We call that "vmcs02". > A later patch will contain the code, prepare_vmcs02(), for filling the vmcs02 > fields. This patch only contains code for allocating vmcs02. > > In this version, prepare_vmcs02() sets *all* of vmcs02's fields each time we > enter from L1 to L2, so keeping just one vmcs02 for the vcpu would have > sufficed: It could be reused even when L1 runs multiple L2 guests. > However, in future versions we'll probably want to add an optimization where > vmcs02 fields that rarely change will not be set each time. For that reason > it is beneficial to keep around several vmcs02s of L2 guests that have > recently run, so that potentially we could run these L2s again more quickly > because less vmwrites to vmcs02 will be needed. > > This patch adds to each vcpu a vmcs02 pool, vmx->nested.vmcs02_pool, > which remembers the vmcs02s last used to run up to VMCS02_POOL_SIZE L2s. > Because in the current version prepare_vmcs02() sets all vmcs02 fields no > matter what we start with, we choose VMCS02_POOL_SIZE=1. I.e., one vmcs02 > is allocated (and loaded onto the processor), and it is reused to enter any > L2 guest. In the future, when prepare_vmcs02() is optimized not to set all > fields every time, VMCS02_POOL_SIZE should be increased. > Thanks, that looks much nicer. -- error compiling committee.c: too many arguments to function