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

[Avi Kivity <avi@redhat.com>]

On 09/06/2009 07:55 PM, Orit Wasserman wrote:
>> 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.
>    

That comes naturally with the shadow mmu.  In the same way normal shadow 
mmu protects guest page tables, nested EPT shadow should protect the 
guest's EPT pages.

(unfortunately there is no INVEPT instruction that accepts a gpa 
operand; this would make write protection unnecessary).

>> 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 ?
>    

Yes.

> We can limit the number of guests as a very quick solution.
>    

How?  There is no way to tell the guest not to launch more guests.

> More complicated is limiting the number of vpids per L1 hypervisor and
> reusing them.
>    

When the bitmap is full, clear it.  Use a generation count to tell vcpus 
to reload.  svm does that (svm only has 63 asids).

> This means we will sometime need to invalidate the vpid when switching
> between L2 guests.
>    

Yes.

>> 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.
>    

No, I don't think any host state changes, except for cr0.ts.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.