Re: [PATCH 3/6] Nested VMX patch 3 implements vmptrld and vmptrst

[Avi Kivity <avi@redhat.com>]

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