[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |