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