WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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: Mon, 20 Sep 2010 11:13:33 +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: Sun, 19 Sep 2010 20:19:37 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C8B684DB.230B8%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: <1A42CE6F5F474C41B63392A5F80372B22A8C236B@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C8B684DB.230B8%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: ActUrjFTQ+ojJjAnSDWc/9iRkRslWQAAQqD5AAF/29AABVpPLQABspUgAAGP4pYA5kz3IA==
Thread-topic: [Xen-devel] [PATCH 06/16] vmx: nest: handling VMX instruction exits
Keir Fraser wrote:
> 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?

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.

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 :)

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

MSR bitmap will have similar situation. Currently VMX removed MSR bitmap 
features, but we may do like I/O bitmap to write-protect the page, though it is 
slightly complicated.

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

Agree, thanks!

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

Agree. Thanks.
Need write-protection, otherwise generating shadow bitmap is expansive. 
Checking bitmap at I/O exit is fine.

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

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