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: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, 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: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Date: Wed, 15 Sep 2010 20:36:56 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, "Dong, Eddie" <eddie.dong@xxxxxxxxx>, "He, Qing" <qing.he@xxxxxxxxx>
Delivery-date: Wed, 15 Sep 2010 05:41:54 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C8B66EFB.2304C%keir.fraser@xxxxxxxxxxxxx>
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: <1A42CE6F5F474C41B63392A5F80372B22A8C22C9@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C8B66EFB.2304C%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: ActUrjFTQ+ojJjAnSDWc/9iRkRslWQAAQqD5AAF/29AABVpPLQABspUg
Thread-topic: [Xen-devel] [PATCH 06/16] vmx: nest: handling VMX instruction exits
Keir Fraser wrote:
> On 15/09/2010 10:08, "Dong, Eddie" <eddie.dong@xxxxxxxxx> wrote:
>>> But yes I can see that emulation of L2 guest instructions is needed
>>> in some other cases. Like instructions performing I/O in areas which
>>> L1 thinks it has given L2 direct unmediated access to, but which Xen
>>> is actually filtering or emulating.
>> That may be an issue in plan when we support virtual VT-d for nested
>> I/O performance. But not now :)
> 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?

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

> it has given direct unfettered access to the L2, but L0 (Xen) is
> actually blocking it. In this case any resulting required instruction
> emulations have to be performed by Xen on behalf of the L2, without
> L1's help or knowledge. Consider that even in Xen we give all HVM
> guests direct access to thinks like port 0x80 for perf reasons. Maybe
> a VMM running in L1 would give direct access to more even than that
> -- in such cases Xen must be able to emulate those 'direct' accesses. 


> Now this shouldn't be hard to arrange anyhow. When you vmexit to Xen
> from running L2 guest, the saved general-purpose CPU state will be
> the L2's state, and that is what you would want x86_emulate to see.
> But it does require some thought, and it is merely not an extension
> to be dealt with later. It is core VMX stuff and hence core nested
> VMX stuff. 

Yes. For I/O issue, emulating by L0 should be fine.

Thx, Eddie
Xen-devel mailing list

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