RE: [Xen-devel] Re: X86_emulate to be moved into qemu...

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

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