> 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