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


[Xen-devel] RE: Re-using the x86_emulate_memop() to perform MMIO for HVM

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: [Xen-devel] RE: Re-using the x86_emulate_memop() to perform MMIO for HVM.
From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
Date: Thu, 4 May 2006 15:32:58 +0200
Cc: Khoa Huynh <khoa@xxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 04 May 2006 06:33:25 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcZvW/FFK+gAdpm+SGaByGhUk3TfxAAISuhg
Thread-topic: Re-using the x86_emulate_memop() to perform MMIO for HVM.
> -----Original Message-----
> From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx] 
> Sent: 04 May 2006 10:10
> To: Petersson, Mats
> Cc: xen-devel; Khoa Huynh
> Subject: Re: Re-using the x86_emulate_memop() to perform MMIO for HVM.
> On 3 May 2006, at 15:50, Petersson, Mats wrote:
> > A third, easier, but less pleasing way to solve it would be 
> retain the 
> > current two decode/emulate code-paths, and just add 
> everythign twice 
> > when new scenarios are needed to be decoded - I don't quite 
> like this 
> > idea, but it certainly is the least amount of effort to implement!
> >
> > Thoughts and comments (aside from the obvious "You should 
> have thought 
> > about this earlier!" ;-) would be welcome...
> We need an emulator both in Xen and in the device model. The 
> current split decode-emulate is pretty barking. My plan for 
> now would be to copy x86_emulate.c and plumb it into qemu-dm: 
> so we do duplicate the code but it's actually only one source 
> file to maintain.

That does indeed sound like a good plan. 

And it sounds like it would work. But isn't the "emulate within Xen"
going to have a problem with that? Or do we use the Xen version of
x86_emulate for the Xen devices (as we can obviously read/write those
without switching to another context, and thus don't have the problems
I've been hitting). 

So what you're essentially saying is make a soft link from current
x86_emulate.[ch] into the tools/ioemu/, and set up suitable read/write
functions, and then use that in helper2.c, yes? [Sorry if I'm asking
obvious questions, but it's usually better to ask first than to have to
do things twice because you didn't ask...]
> So, Xen would take the page fault and look up the 
> corresponding mmio area. If it's an area corresponding to a 
> device emulated by qemu-dm then Xen hands off the entire 
> problem. It does not bother to decode the instruction at all. 
> Instead it stuffs register state into the shared memory area 
> and hands off to qemu-dm in dom0.

Makes life a whole lot simpler, I should think - but for the MMX/SSE
support, that would mean that we need to FXSAVE/FXRSTOR those around
this code, right? Will that not cost unnecessarily much?

I guess we should also supply the segment base (and limit?) information
in this memory block, so that x86_emulate can do things like
big-real-mode and other segmented operations that may happen at some

Anything else we should think to pass along as well "while we're at it"?

> There are plans afoot to try using the full qemu cpu 
> emulator. Done well, that would provide fuller and faster 
> emulation, but there is a bigger up-front cost to getting 
> that plumbed in correctly and even if someone runs with this 
> plan I don't see it being completed to a high degree of 
> robustness in the very near future.

Yes, I saw that discussion. I'm not sure if it's much help to do that
(for AMD at least, Intel has a problem because they don't support
paged-real-mode, which of course is a bit of a nuisance to them...)

>   -- Keir

Xen-devel mailing list

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