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


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.

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

--
Mats

> 
>   -- 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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel