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:34:59 +0200
Cc: Xen devel list <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 18 May 2006 05:34:28 -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: AcZ6Y6ertAN7G5pGTdOh2WgF58olSQAEl4EA
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 11:09
> To: Petersson, Mats
> Cc: Xen devel list
> Subject: Re: [Xen-devel] Re: X86_emulate to be moved into qemu...
> On 18 May 2006, at 10:50, Petersson, Mats wrote:
> > For the movs (in x86_emaulate.c) the segment override is currently 
> > detected but ignored for protected mode operation (base is 
> assumed to 
> > be zero). This is why Minix doesn't work properly [or at 
> all, really] 
> > - admittedly, I don't think Minix is the most critical operating 
> > system in the world, but one part of fixing this up is to 
> avoid having 
> > to fix furhter "weirdness" in various operating systems, right?
> Well, the core logic calls out to a macro that then ignores the base. 
> The obvious thing to do is have add a new call-out hook in 
> struct x86_mem_emulator to read base address of a specified 
> selector. Or we could simply pass them in as an array, 
> perhaps as structs allowing us to determine other useful info 
> like stack segment address size.
> If we do that then we get rid of all real vs. protected mode 
> segmentation differences in the core emulator. We always call 
> out or read from the array. That gets us support for big real 
> mode too.
> If you want to add extensions or flexibility to x86_emulate 
> for this stuff, please try to trickle piecemeal patches to 
> me. I prefer that to big-bang uber patches. I can also make 
> sure it integrates properly with current uses of the emulator.

I just had a couple of thoughs for "stepwise refinement" of the

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

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

These two changes can be done before I start actually trying to plumb
things into the QEMU model.

Does it make sense to do it this way, and/or do you have some other


>   -- Keir
> >>
> >>   -- Keir
> >>
> >>
> >>>> What header files are those? It builds in tools/test/
> >> without so many
> >>>> header files.
> >>> 'hg status' says:
> >>
> >> I'll fix that.
> >
> > Ok, thanks.

Xen-devel mailing list