On Thu, Dec 14, 2000 at 02:44:30PM -0500, Kevin Lawton wrote:
> There are always details which complicate things. There are
> areas like notions of time in the monitor, and other factors
> peripheral to the CPU/memory state that need to be saved/restored.
Right. That's why this is non-trivial. The trivial parts are already
done <G>.
I'm not certian what the big deal is about time. At present, time for the
guest isn't really linear; it depends on how much time we're scheduled for.
WRT freezing, we've got two choices:
1) Time stops while frozen. This is what I assumed. This shouldn't mess up
anything except for the RTC being off from reality.
2) The amount of time that has taken place in the Real World is reflected
back to the guest. This would cause all sorts of trouble (we'd have
missed a huge number of timer interupts, everything would have timed out,
etc).
I think there's no problem dealing with the minor inconvience of choice 1.
> In the host user space, every plugin (hardware emulation etc),
> every service (time references etc) has to be compliant with
> a save/restore interface.
Yes. This is the hard part. This is why I dropped the thread the last time
it came up.
> There are issues here. The user process does not contain all
> the existing state. Services which it uses which are handled
> by external libs/services, such as graphics, file IO, time, and
> others can complicate a save/restore architecture. Using direct
> graphics libs for example, can complicate things.
Hm, I don't think this is so much a problem. There isn't all that much
state, I think, in most of the services, with the exceptions of:
1) Graphics -- I think it's workable to save all state except the contents
of the video buffer, and make the user refresh that afterwords. C-L, F5, or
somesuch should be enough in most cases.
2) Time -- like I said before, some measures of time (timer interupts) might
remain static, whereas others (RDTSC?) might change. This could screw up
some things, but at present, we do an invalid instruction on the RDTSC.
AFAICS, the only places outside-world time are referenced are:
bios.cc -- fine. We either let the BIOS's view of time be changed to the
wallclock time in the outside world, or restore it from the statefile.
This isn't a problem either way, likely, but restoring it should be
completely safe.
mon-fault.c -- Will need some work, but doesn't look that bad.
Various -- RDTSC is used for LRU caches some places -- but the caches
will be empty. No problem.
mon-system -- this is where plex86-level timers are handled. By
definition, these are in terms of guest CPU cycles, so
obviously no time should count while we're frozen.
Anyway, as far as I can see, what's needed is for vm_rdtsc to subtract a
value from the RDTSC as returned by the CPU st it is zero when plex86 starts
-- and adjust it st it has the same value at thaw as it did at freeze.
> Then there is the issue of formats. First, do you store dumped
> data in binary or text? Binary is easier, but text is more flexible,
> and allows you to potentially restore from a previous dump after
> some modifications.
Binary. The freeze/thaw core shouldn't have to know anything about the void
*data. If you want to modify it, Use the Source, Luke. Unless you know
what you're doing pretty damm well, modifing the statefile, or anything
else, for that matter, is likely to mess stuff up. This approach is plenty
dicey enough without modifing the statefile.
> - We may be getting help in this area, in which case we won't
> have to reinvent this wheel. That's all I'm saying for now.
Wohoo!
-=- James Mastros
--
midendian: She never sleeps.
mousetrout: But I do. I just regret it after I wake up.
AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
ICBM: 40:04:15.100 N, 76:18:53.165 W
