[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Re: Re-using the x86_emulate_memop() to perform MMIO for HVM.
> Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> wrote on 05/04/2006 04:10:06 AM: > > > > > On 3 May 2006, at 15:50, Petersson, Mats wrote: > > > > > A third, easier, but less pleasing way to solve it would be retain the > > > current two decode/emulate code-paths, and just add everythign twice > > > when new scenarios are needed to be decoded - I don't quite like this > > > idea, but it certainly is the least amount of effort to implement! > > > > > > Thoughts and comments (aside from the obvious "You should have thought > > > about this earlier!" ;-) would be welcome... > > > > We need an emulator both in Xen and in the device model. The current > > split decode-emulate is pretty barking. My plan for now would be to > > copy x86_emulate.c and plumb it into qemu-dm: so we do duplicate the > > code but it's actually only one source file to maintain. > > Would this be sufficient to support real mode in qemu-dm with > x86_emulate in it (at least for Intel) ? If we were to run all real mode in x86_emulate then it would need extending for quite a few more instructions. Currently it handles only instructions with at least one memory operand. I don't think it's that bad though, but it depends how complete we want to be (e.g., FPU instructions). Are we just trying to get a good range of bootloaders running robustly, or do we want to run MS-DOS and Win95 with decent performance? The latter would in any case probably require something more powerful (like the qemu cpu emulation engine) as running entirely on x86_emulate is not going to have very good performance. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |