BTW, how do you save the CPU state? It's easy to store the state of all
the devices and to load them, since they're emulated... but not the CPU.
We really should have a 's' structure for the CPU that gets unpacked to
the main CPU structure, when the guest is running, and gets compacted
back to 's' when the guest exits. Thus one could start executing the
guest where one left off, e.g. elliminate boot time.
The only disadvantage is the clock will suddenly 'jump' to the new time,
but that's alright since we can make the CMOS begin at any arbitrary
time and, if we wish, we can make it begin at the time it left off. It
will then be out of synch with the real world but that is alright; I
suppose we could also generate a bunch of IRQ 0's at an accelerated
rate, "emulating" the time that has ellapses, te he! ;-)
A challenge is expanding from the saved cpu state to the actual cpu
state. Basically this is done when you switch back to the guest (running
natively) but, now we've got to synch the emulated paging mech. to the
actual one.
This is tricky but the actual paging does not need to be restored to the
way it was upon exitting. It just needs to act as if this is the case.
Any ideas? IMHO this could simplefy further development since we can
save the state, run a program, and exit; then make changes to the source
code and rebuild, then restore the state, run the program, and exit; the
state will begin precisely the same when each program is run, except the
new changes we made will take effect. Thus we can easilly develop.
Kevin Lawton wrote:
>
> >From ChangeLog:
>
> - "Kevin P. Lawton" <[EMAIL PROTECTED]>: Sun Jun 10 12:34:56 EDT 2001
> ACK! I had a goto jumping around the native CS:EIP fetch accelerations,
> in emulation/emulation.c. Forgot and left that in there. Man,
> do things work faster now!!! Check this out:
>
> Yesterday Today
> Pragma 5:50 2:54
> Win95 3:23 1:59
>
> And we still have many performance tweaks to do, running app code
> natively, better video (still getting wacked with 1E+06 redirects for
> VGA 640x480x16color latches), drivers, better page-on-demand logic,
> etc. Pragma is getting hit with a lot of redirects to the CMOS
> in user space. That can be fixed also, by a move to VM space, like
> I did with the PICs/PITs already.
>
> Next on the agenda... speculative page mapping; mapping in more than
> 1 guest page at a time. Makes sense to map in a few neighboring pages
> too, and reduce page faults from native accesses.
>
> With future enhancements, I'd like to see a low 1+ minute
> boot time. That plus application code running native should
> yield a real usable piece o' software!
>
> -Kevin
>
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Kevin Lawton [EMAIL PROTECTED]
> MandrakeSoft, Inc. Plex86 developer
> http://www.linux-mandrake.com/ http://www.plex86.org/
