Re: List of unaccessible x86 states

[Avi Kivity <avi@redhat.com>]

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