Avi Kivity <avi@xxxxxxxxxx> wrote on 06/09/2009 16:52:56: > From: > > Avi Kivity <avi@xxxxxxxxxx> > > To: > > Orit Wasserman/Haifa/IBM@IBMIL > > Cc: > > Abel Gordon/Haifa/IBM@IBMIL, aliguori@xxxxxxxxxx, Ben-Ami Yassour1/ > Haifa/IBM@IBMIL, kvm@xxxxxxxxxxxxxxx, mday@xxxxxxxxxx, Muli Ben- > Yehuda/Haifa/IBM@IBMIL > > Date: > > 06/09/2009 16:53 > > Subject: > > Re: [PATCH 3/6] Nested VMX patch 3 implements vmptrld and vmptrst > > 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. We will also need to write protected L1's EPT tables , to allow L1 to swap out his guests. > > >>> 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). OK. > > >> > >>> 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. You meant by launching a lot of guests ? We can limit the number of guests as a very quick solution. More complicated is limiting the number of vpids per L1 hypervisor and reusing them. This means we will sometime need to invalidate the vpid when switching between L2 guests. > > > 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. I think that when KVM switches to Qemu the host state can change (L0 host state). If this happens between different runs of L2 we will need to update VMCS02 host state. Of course we can optimize and update it only than. > > >> 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. You are right , a new VMCS will be zeroed. > > Note it also solves live migration, since now all guest vmcss are copied > as part of normal guest memory (including their launched state). Great. > > -- > error compiling committee.c: too many arguments to function > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
