On 10/26/2009 11:11 AM, Alexander Graf wrote:
L1 hsave stores the architected state saved by vmrun, e.g. cs.sel,
next_rip, cr0, cr3, etc. The host intercept bitmap is not state
since it is calculated from the L1 intercept bitmap and host code.
Indeed it can be different from host to host even with the same guest
state.
Ah, so you'd only save off the cpu state parts of the vmcb.
Currently we save off control parts too, so we can easily swap them in
on #vmexit.
These can still be saved in a host memory area as an optimization, and
regenerated if needed.
So if we'd migrate off when inside the nested guest, we'd have to save
off the resume control state, OR them again with the guest vmcb
control states and be inside the nested guest.
Right, if the new state bit (guest mode) is set, we look at the control
bits and OR them into the vmcb. That part can be reused with the VMRUN
code.
Wouldn't it be much easier to not migrate / save state when inside a
nested guest? I'm afraid the code will become overly complex if we do
allow migration while in a nested context.
I can't really see why but then I don't know the code as well as you
do. The current code won't work for guests which don't intercept
external interrupts (probably only malware). For nested vmx it may be
necessary since vmx has a mode where interrupts are acknowledged during
#VMEXIT and the interrupt vector is saved into a register; you can't
fake an interrupt #VMEXIT since you can't fake the vector. Xen is one
guest which uses this mode.
--
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
