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