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 12:49:43 +0200
Cc: Xen devel list <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 18 May 2006 03:49:24 -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: AcZ6Y6ertAN7G5pGTdOh2WgF58olSQABDfeg
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.

I think passing in as part of the struct is the easiest way - since it's
got to know it from the VMC[BS] - but the current code would have to
call out to the respective SVM/VMX code to fetch that info. No big deal.

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

That's what I'd like to see - just get the base address out of an array,
and be done with it - no problems supporting whatever strange things
people come up with... 
> 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.

Yes, I'll get it to work, with current support, inside QEMU first, and
then trickle in added features (such as segment support and FPU/MMX/SSE
support). Naturally, getting the work into QEMU will be a fairly big
patch, as it's touching quite a few areas, and I can't see any obvious
way to split it up into smaller pieces... 

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