From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 3/6] Nested VMX patch 3 implements vmptrld and vmptrst Date: Sun, 06 Sep 2009 16:52:56 +0300 Message-ID: <4AA3BEB8.3030009@redhat.com> References: <1251905916-2834-1-git-send-email-oritw@il.ibm.com> <1251905916-2834-2-git-send-email-oritw@il.ibm.com> <1251905916-2834-3-git-send-email-oritw@il.ibm.com> <1251905916-2834-4-git-send-email-oritw@il.ibm.com> <4A9ECFF5.60701@redhat.com> <4AA37FFD.3090400@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Abel Gordon , aliguori@us.ibm.com, Ben-Ami Yassour1 , kvm@vger.kernel.org, mday@us.ibm.com, Muli Ben-Yehuda To: Orit Wasserman Return-path: Received: from mx1.redhat.com ([209.132.183.28]:20938 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752602AbZIFNxC (ORCPT ); Sun, 6 Sep 2009 09:53:02 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 09/06/2009 04:36 PM, Orit Wasserman wrote: > >> When we support multiple nested guests, we'll run into a problem of >> where to store shadow_vmcs. I see these options: >> >> - maintain a cache of limited size of shadow_vmcs; when evicting, copy >> the shadow_vmcs into the guest's vmptr] >> - always put shadow_vmcs in the guest's vmptr, and write protect it so >> the guest can't play with it >> - always put shadow_vmcs in the guest's vmptr, and verify everything you >> read (that's what nsvm does) >> >> > The second option looks a bit complicated I prefer one of the other two. > I agree, the third option looks easiest but not sure how much verification is needed. Note other things like the msr bitmaps may need write protection, otherwise you have to re-merge the bitmap on every guest entry, which can be very slow. So we may be forced to add write protection anyway. >>> launched- launched flag >>> >>> >> Can be part of shadow_vmcs >> > I prefer to keep the shadow_vmcs as a separate structure to store only VMCS > fields. > It is a vmcs field - it is manipulated by vmx instructions which operate on the vmcs. You'll need to store it in guest memory when you support multiple nested guests. You can put the vmcs fields in a sub-structure if you want to separate between explicit fields and implicit fields (I can only see one implicit field (launched), but maybe there are more). >> >>> vpid - the vpid allocate by L0 for L2 (we need to store it >>> > somewhere) > >>> >> Note the guest can DoS the host by allocating a lot of vpids. So we to >> allocate host vpids on demand and be able to flush them out. >> > The guest is not allocating the vpids the host(L0) does using > allocate_vpid. > I meant, the guest can force the host to allocate vpids if we don't protect against it. > I agree that with nested the danger for them to run out is bigger. > >> Sorry, don't understand. >> > VMCS02 - the VMCS L0 uses to run L2. > When we create/update VMCS02 we need to read fields from VMCS01 (host state > is taken fully, control fields ). > For L1 the shadow_vmcs is a copy of VMCS01 in a structure format, we used > the same structure. > I don't understand why you need it. Host state shouldn't change. Only the control fields are interesting, and things like exception_bitmap. >> But why do it? Your approach is to store the guest vmcs in the same >> format as the processor (which we don't really know), so you have to use >> vmread/vmwrite to maintain it. Instead, you can choose that the guest >> vmcs is a shadow_vmcs structure and then you can access it using normal >> memory operations. >> > I got it now. > We will need a way to distinguish between processor format VMCS and > structure based VMCS, > we can use the revision id field (create a unique revision id for nested > like 0xffff or 0x0). > No, you can always store guest vmcs in software format, since we'll never load it with vmptrld. We'll only load a real vmcs with vmptrld. Note it also solves live migration, since now all guest vmcss are copied as part of normal guest memory (including their launched state). -- error compiling committee.c: too many arguments to function