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: Wed, 15 Sep 2010 14:12:43 +0100
Cc: Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, "He, Qing" <qing.he@xxxxxxxxx>
Delivery-date: Wed, 15 Sep 2010 06:13:25 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1A42CE6F5F474C41B63392A5F80372B22A8C236B@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/29AABVpPLQABspUgAAGP4pY=
Thread-topic: [Xen-devel] [PATCH 06/16] vmx: nest: handling VMX instruction exits
User-agent: Microsoft-Entourage/
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

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

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?

 -- Keir

Xen-devel mailing list

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