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>
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 21:37:06 -0400
Cc: Mats <Mats.Petersson@xxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Khoa Huynh <khoa@xxxxxxxxxx>
Delivery-date: Sat, 29 Apr 2006 12:40:37 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <3adf04d5b121d8f8bd17e78d90e37e86@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> <1146322494.2528.19.camel@xxxxxxxxxxxxxxxxxxxxx> <18dbf8579f22244039cabdf6da372735@xxxxxxxxxxxx> <1146353053.2528.36.camel@xxxxxxxxxxxxxxxxxxxxx> <3adf04d5b121d8f8bd17e78d90e37e86@xxxxxxxxxxxx>
Reply-to: leendert@xxxxxxxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Sat, 2006-04-29 at 19:54 +0100, Keir Fraser wrote:

> > In the BIOS (realmode) these devices are initialized and the subsequent
> > 32-bit code depends on the proper initialization. For the common I/O
> > emulation case this should hopefully be rare.
> How does this work now? Do we really have two copies of each device 
> model? I doubt that's implemented safely.

Right now the realmode code runs inside the VMX partition where it is
partially emulated by vmxassist. So all accesses to the emulated devices
go through the hypervisor first before they (potentially) end up in
qemu-dm. When a transition is made to 32/64-bit code all the initialized
device state is still there.

The problem of keeping the the hypervisor state and the qemu-dm state in
sync is introduced when we alternate between emulation and real
execution. This becomes more interesting when we consider MP guests
where one CPU is running inside the emulator and another on the real


Xen-devel mailing list

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