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

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

On 20/09/2010 04:13, "Dong, Eddie" <eddie.dong@xxxxxxxxx> wrote:

>>>> 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
>>> 
>>> I see, for the I/O port, right now we are letting L1 handle it
>>> though it doesn't expect to :( How about to remove the capability of
>>> CPU_BASED_ACTIVATE_IO_BITMAP in L1 VMM for now to focus on framework?
>> 
>> Well. It'd be better if just worked really, wouldn't it? :-) How hard
>> can it be?
> 
> You are right. It is easy to do, but we have dillemma to either write-protect
> guest I/O bitmap page, or have to create the shadow I/O bitmap at each
> vmresume of L2 guest.

You need that anyway don't you, regardless of whether you are accurately
deciding whether to inject-to-L1 or emulate-L2 on vmexit to L0? Whether you
inject or emulate, ports that L1 has disallowed for L2 must be properly
represented in the shadow I/O bitmap page.

> Currently we are injecting to L1 guest, but may be not correct in theory. For
> now, VMX can trap L2 guest I/O and emulate them in L0, we can revisit some
> time later to see if we need write-protection of guest I/O bitmap page :)

Are you suggesting to always emulate instead of always inject-to-L1? That's
still not accurate virtualisation of this VMX feature.

Hmm... Are you currently setting up to always vmexit on I/O port accesses by
L2? Even if you are, that doesn't stop you looking at the virtual I/O bitmap
from in your L0 vmexit handler, and doing the right thing (emulate versus
inject-to-L1).

 -- Keir

> But, yes, L0 VMM needs to emulate L2 instruction here :)



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