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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

> > 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).
Yes, you'd only invoke qemu-dm for the non-Xen devices.

> 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...
Pretty much. As you say below, we also need to provide access to 
segment bases. But actually most instructions are okay because we know 
the faulting linear address of one of the memory operands (and usually 
there is only one).
> 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 think it's in the noise compared with the context-switch cost. 
However we could save the FPU state on demand, only if it turns out 
that qemu-dm needs it. FXSAVE will only be needed if the guest has 
actually been using the FPU. Otherwise we already have the up-to-date 
FPU state saved in memory.
> 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.
Yes, definitely, and this will require some modifications to the 
emulator itself. Either an extra block of state passed in to the 
emulator, or adding a call-out function hook from the emulator to 
obtain segment bases on demand. I think the former is probably simpler.
> Anything else we should think to pass along as well "while we're at 
> it"?
No, I think that's it.

> 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...)
Well, sometimes device register accesses happen in clusters, and it 
would be nice to amortise the cost of switching to qemu-dm across 
emulation of an entire cluster of accesses. It might well be a win in 
many cases, but it's also fair amount of work I think.
 -- Keir


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