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

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

Christoph Egger wrote:
> On Monday 20 September 2010 10:08:02 Keir Fraser wrote:
>> 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.
> 
> You need to do additional range-checking to determine if the guest
> actually touched the IO bitmap page in case Xen uses a super page.
> 

We may have many alternatives to this. If we treat this address space as MMIO, 
we can hook handler for MMIO emulation.

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