This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Christoph Egger <Christoph.Egger@xxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH 06/16] vmx: nest: handling VMX instruction exits
From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Date: Mon, 20 Sep 2010 21:14:54 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: Deegan <Tim.Deegan@xxxxxxxxxxxxx>, Tim, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Dong, Eddie" <eddie.dong@xxxxxxxxx>, "He, Qing" <qing.he@xxxxxxxxx>
Delivery-date: Mon, 20 Sep 2010 06:19:18 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <201009201141.13325.Christoph.Egger@xxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C8BCD4F2.2380F%keir.fraser@xxxxxxxxxxxxx> <201009201141.13325.Christoph.Egger@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: ActYqHCwwZNQjwE+Q/uI1GArmqEBAQAHNJwg
Thread-topic: [Xen-devel] [PATCH 06/16] vmx: nest: handling VMX instruction exits
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.

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>