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