This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: RE: [Xen-devel] Re: X86_emulate to be moved into qemu...
From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
Date: Thu, 18 May 2006 14:58:57 +0200
Cc: Xen devel list <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 18 May 2006 05:58:35 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcZ6eWLMra8ogShySU+ITLAXjhZU6QAANK+g
Thread-topic: [Xen-devel] Re: X86_emulate to be moved into qemu...

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

>   -- keir

Xen-devel mailing list