> -----Original Message-----
> From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx]
> Sent: 18 May 2006 13:43
> To: Petersson, Mats
> Cc: Xen devel list
> Subject: Re: [Xen-devel] Re: X86_emulate to be moved into qemu...
>
>
> On 18 May 2006, at 13:34, Petersson, Mats wrote:
>
> > 1. Add a pointer to a struct (or opaque void *) the
> > x86_emulate_memop() to allow us to pass extra data from HVM
> that can
> > be used inside the call-back functions when needed. For the current
> > usage, that would be null.
>
> I was considering packing all the current emulator parameter
> into an args structure, then passing a pointer to that to the
> callback functions. That'll let them get at potentially
> interesting things like execution mode, and they can use
> container_of() to get at a containing structure if there is
> other stuff of interest to them out side the scope of
> emulator parameters.
>
> That would also clean up calls to the emulator (imo) as if we
> add many more parameters we'll end up with unwieldy parameter
> lists. Packing a structure then making the emulator call
> would be cleaner as you'd assign to each argument structure
> field on a separate source code line, and the field your
> assigning to would be explicitly named (rather than having to
> work out what the ordering of parameters to the function is,
> as you do now).
So, that would be a struct that could have the "struct ioreq" field in
it, which is optionally filled in depending on where it's called from,
for example?
Yes, I agree with this.
I'll work on something that uses this method, and I'll send you a patch
before I go any further.
>
> > 2. Add new interface functionality - add a
> "fetch_insn_byte" function
> > pointer, and use that instead of/inside the macro insn_fetch. This
> > will be necessary if we pass a translated CS:rIP to the
> QEMU version.
> > Or if we pass along a buffer of instruction bytes from the
> guest code,
> > we'd need to fetch from that. The current code doesn't make any
> > difference between reading code-bytes or any other reads of
> guest memory...
>
> I think we should pass that buffer in as an array, plus count
> of bytes it contains. Two extra fields for the args sturcture. :-)
Yes, that's what I was planning on [and yes, the length can is handy, in
case we run into the back end of a page and the next page isn't there -
we don't handle that well right now. Still, I'm not sure what we do if
the next page isn't there and the instruction ends on the next page, but
I guess we'll just have to inject back in a page-fault and see what
happens... ;-)]
--
Mats
>
> -- keir
>
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home