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] Calculate correct instruction length for data-fa

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>, Mats <Mats.Petersson@xxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Khoa Huynh <khoa@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Calculate correct instruction length for data-fault VM exits on VT-x systems
From: Leendert van Doorn <leendert@xxxxxxxxxxxxxx>
Date: Sat, 29 Apr 2006 10:54:54 -0400
Delivery-date: Sat, 29 Apr 2006 01:55:27 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <ab349cc8181126e044d8db52186d597a@xxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: IBM T.J. Watson Research Center
References: <907625E08839C4409CE5768403633E0BA7FC0B@xxxxxxxxxxxxxxxxx> <c231609ff1a74b7bbeebd70a7ec94936@xxxxxxxxxxxx> <1146273618.4268.32.camel@xxxxxxxxxxxxxxxxxxxxx> <ab349cc8181126e044d8db52186d597a@xxxxxxxxxxxx>
Reply-to: leendert@xxxxxxxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Sat, 2006-04-29 at 09:00 +0100, Keir Fraser wrote:

> The APIC and IO-APIC are accessed via mmio. The former is written 
> fairly frequently with singleton updates (to the TPR and EOI registers) 
> so we'd want to carry on dealing with those directly in Xen I should 
> think. Still you'd have to deal with the case that one of the 
> Xen-emulated devices is accessed while emulating in qemu-dm -- as you 
> say you'd probably have to pull their state vectors out of Xen when 
> starting emulating. We'll need that for save/restore anyway though.

The state is already partially exposed to qemu-dm through the shared
global I/O data page (include/public/hvm/ioreq.h). This is easy to
extend so that a context switch doesn't involve copying device state.
This is also the place where we should store the vmx_assist_context
information that is required by the emulator.

The mmio *pic operations could just be handled by x86_emulate.

> I don't know if this will make sense for emulated I/O but it does sound 
> like a very sane alternative to vmxassist for dealing with real mode.

The big advantage I see for I/O is that 1) we don't need the instruction
decode support anymore so it cleans up the hypervisor, 2) it has the
potential to greatly reducing the number of exits that are caused by I/O
by emulating subsequent I/O operations before returning to the HVM
partition. Especially for the older devices that we are currently
emulating this could be a major win, but even for modern devices where
you are manipulating ring buffers that reside in I/O space it would be a

I don't think that moving the I/O decoding from the hypervisor to the
device model is going to be a major performance bottleneck. This cost is
dwarfed by the upcall into qemu-dm.


Xen-devel mailing list

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