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: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
Subject: Re: [Xen-devel] Re: X86_emulate to be moved into qemu...
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Thu, 18 May 2006 13:43:11 +0100
Cc: Xen devel list <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 18 May 2006 05:43:34 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <907625E08839C4409CE5768403633E0BA7FC91@xxxxxxxxxxxxxxxxx>
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>
References: <907625E08839C4409CE5768403633E0BA7FC91@xxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

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

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

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. :-)

 -- keir

Xen-devel mailing list