>For what I said about timing, forget about host timing altogether.
>It means nothing to the guest. I don't intend to derive timing
>from the host in any way except to deliver timing events to
>user code such as the screen refresh. Those kinds of things
>have to do with wall-clock time, and have nothing to do with
>the VM. (the VM doesn't care how often you see updates).
We've talked about this before, and I'll spew my point of view again:
this is not a good idea. The guest OS will not "feel" right. On the little
details side, for instance, we'll find that the little clock in the corner
of the windows taskbar runs completely asynchronously (and wrong) wrt the
linux clock --- which also means that if you have date-relates programs (like
you basic mailer application), all times will be wrong !! On the more
important side, we'll have
- Any even remotely real-time application will go wrong.
For instance, movies would be played at too low speeds, sound would come
in chunks, etc.
- Driving of time-related hardware (CD burners) will go wrong, as you
mention below.
We do not want these effects !! To me, the idea that a multimedia
application will not run inside the VM is completely unacceptable in our
modern multimedia-driven computing world.
The problem is that clock skewing, our proposed solution, will make timing
unstable again -- the clock skew only works *per quantum* (we can speed up
or slow down the virtual time per quantum, depending on the previous
execution times, but not inside the quantum!) That means that delay loop
calibration will probably go all wrong again (though it'll probably work
better than it does now, and it would be pretty reliable on a constant
load). I don't really have any idea how to get around this at the
moment...
-- Ramon
