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: "Dong, Eddie" <eddie.dong@xxxxxxxxx>, Christoph Egger <Christoph.Egger@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 06/16] vmx: nest: handling VMX instruction exits
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Mon, 20 Sep 2010 09:08:02 +0100
Cc: Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, "He, Qing" <qing.he@xxxxxxxxx>
Delivery-date: Mon, 20 Sep 2010 01:08:53 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1A42CE6F5F474C41B63392A5F80372B22A95F800@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: ActUrjFTQ+ojJjAnSDWc/9iRkRslWQAAQqD5AAF/29AABVpPLQABspUgAAGP4pYA5kz3IAAKg/kr
Thread-topic: [Xen-devel] [PATCH 06/16] vmx: nest: handling VMX instruction exits
User-agent: Microsoft-Entourage/
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

 -- Keir

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

Xen-devel mailing list

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