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

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

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?

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

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?

 -- Keir



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