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

["Dong, Eddie" <eddie.dong@xxxxxxxxx>]

Keir Fraser wrote:
> On 15/09/2010 13:36, "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.

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 :)

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

MSR bitmap will have similar situation. Currently VMX removed MSR bitmap 
features, but we may do like I/O bitmap to write-protect the page, though it is 
slightly complicated.

> 
>>> direct access versus #PF vmexit; per physical-frame direct access
>>> versus nexted-paging vmexit. In any of these cases the L1 may think
>> 
>> Didn't quit catch. The memory direct access is always guarded by L0
>> shadow or nested EPT/NPT. Missing something?
> 
> L1 gives L2 direct access to, say, HPET (memory-mapped IO) which is
> actually (unknown to L1) a virtual HPET emulated by Xen? Yeah, okay,
> that may be more unlikely to happen in practice but it *is* allowable
> by the architecture and it *should* be supported.

Agree, thanks!

> 
> I would be inclined to add test cases for nestedhvm to hvmloader (we
> already test various other tricky things in there) to test these
> kinds of cases. Broadly speaking it's just a case of walking VVMCS
> structures to check IO_BITMAP, or shadow pagetables, or EPT, and jump
> to the emulator with L2 state if the L1 would have permitted
> execution. It's really a core bit of logic in properly doing nested
> VMX. The unfortunate thing is that the necessary checks will slow
> down nested-hvm further, I guess, but perhaps it's not too bad?

Agree. Thanks.
Need write-protection, otherwise generating shadow bitmap is expansive. 
Checking bitmap at I/O exit is fine.

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