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