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

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

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

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

--
Mats
> 
>   -- Keir


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