Re: [Xen-devel] [PATCH 08/17] vmx: nest: L1 <-> L2 context switch

[Tim Deegan <Tim.Deegan@xxxxxxxxxx>]

At 14:49 +0100 on 20 May (1274366991), Qing He wrote:
> I mean, the code doesn't seem to organize well, partly because there
> are many different states to cover, and some tricks are used to
> work with the current code, vmx_set_host_env would be a good example
> of such kind of tricks. Do you have any suggestions on a better code
> orgnization?

TBH I expect that any implementation of this is going to be messy.  It's
a big interface and there are too many special cases.  

The only thing that strikes me is that you seem to do a full translation
of the vvmcs on every vmentry.  Would it be possible (since we already
have to intercept every vmread/vmwrite) to keep the svmcs in sync all
the time?

Cheers,

Tim.

> Another issue is that 64 shadow on 64 shadow is the only case that
> doesn't work, I'm curious about it, I had some initial investigation
> but didn't come with something, do you have some ideas?
> 
> Thanks,
> Qing
> > 
> > Cheers,
> > 
> > Tim.
> > 
> > > Roughly, at virtual VMEntry time, sVMCS is loaded, L2 control
> > > is combined from controls of L0 and vVMCS, L2 state from vVMCS
> > > guest state.
> > > when virtual VMExit, host VMCS is loaded, L1 control is from L0,
> > > L1 state from vVMCS host state.
> > > 
> > > Signed-off-by: Qing He <qing.he@xxxxxxxxx>
> > 
> > -- 
> > Tim Deegan <Tim.Deegan@xxxxxxxxxx>
> > Principal Software Engineer, XenServer Engineering
> > Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, XenServer Engineering
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel