[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
  • 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
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • 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... 

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.