Fred Weigel wrote:
> Now, if the program attempts to time instruction execution,
> it will have to look at an external time base, and then
> execute. What saves us is that the time base can be caught.
> [Pull a scheduling window over the next piece of code, giving
> the program virtually 100% of CPU for the next second or so.
> This covers most uses of RDTSC and other time-base checks,
> such as the "Zen timer"]. I also propose that allowing
> for execution windows and interrupt throttling can help
> with interrupt re-entrance issues as well.
You seem to assume knowledge of the code we execute...
which we don't have. It would be rather silly, if
we gave the guest "virtually 100% of CPU for the next second
or so" every time a PIT tick transpires !!
About multimedia, timing, etc., clock skewing will solve
all problems (I think!), it's only a problem when you try
to time instruction length on a rapidly varying load.
Setting bounds on the maximum delta of the clock skew,
as Kevin proposes, sounds like a good solution to me.
-- Ramon
