Re: [PATCH 06/16] vmx: nest: handling VMX instruction exits

[Keir Fraser <keir.fraser@eu.citrix.com>]

On 15/09/2010 10:08, "Dong, Eddie" <eddie.dong@intel.com> wrote:

>> But yes I can see that emulation of L2 guest instructions is needed
>> in some other cases. Like instructions performing I/O in areas which
>> L1 thinks it has given L2 direct unmediated access to, but which Xen
>> is actually filtering or emulating.
> 
> That may be an issue in plan when we support virtual VT-d for nested I/O
> performance. But not now :)

Actually it is an issue now. This has nothing to do with VT-d (ie. IOMMU,
irq remapping, etc) but with basic core VMX functionality -- per I/O port
direct execute versus vmexit; per virtual-address page direct access versus
#PF vmexit; per physical-frame direct access versus nexted-paging vmexit. In
any of these cases the L1 may think it has given direct unfettered access to
the L2, but L0 (Xen) is actually blocking it. In this case any resulting
required instruction emulations have to be performed by Xen on behalf of the
L2, without L1's help or knowledge. Consider that even in Xen we give all
HVM guests direct access to thinks like port 0x80 for perf reasons. Maybe a
VMM running in L1 would give direct access to more even than that -- in such
cases Xen must be able to emulate those 'direct' accesses.

Now this shouldn't be hard to arrange anyhow. When you vmexit to Xen from
running L2 guest, the saved general-purpose CPU state will be the L2's
state, and that is what you would want x86_emulate to see. But it does
require some thought, and it is merely not an extension to be dealt with
later. It is core VMX stuff and hence core nested VMX stuff.

 -- Keir

> I suggest we leave that to future at least for nested VMX side where L0 VMM
> doesn't directly emulate L0 VMM instruction.
> 
> We can see if there are other needs for that kind of case.