James Mastros wrote:
>
> 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.
One issue is networking: If a guest OS thinks it has a connection to
some server somewhere, it will still think that once it dies. This is
especially problematic w.r.t. DHCP leases, which will have expired, but
which the guest OS won't be ready to refresh for another X hours.
<SNIP>
--
-Dave Turner
___________________________________________________________
<novalis> Myself, Laurel, Pug, and Pug's other personality.
<pug> I only get two?
