Kevin Lawton wrote:
> Ulrich Weigand wrote:
>
> > Why are you worrying about the performance of code that
> > does nothing but wait? As long as we skew the values
> > returned from RDTSC properly, that loop should run for
> > exactly the same amount of (guest) wall-clock time, no
> > matter whether it will take a million or a thousand
> > passes through the loop ...
>
> Two reasons. One is that I don't want the guest OS to run
> slow in the VM. Under the wrong conditions performance
> could be sluggish, only because of bogus delay loops.
Why? If a single RDTSC takes long, then the loop is simply
executed fewer times ... The same could e.g. happen on
Linux if an interrupt happens while looping; the total time
spent in the loop will still be the same.
Only timing *accuracy* might be affected. I'm not sure
this a problem, though.
> A second reason is that there is a host OS running, which
> may be able to schedule a user task to do something useful,
> if the udelay() value is high. I don't want to bog down
> the host OS either while wasting time virtualizing a
> guest busy loop.
If the udelay() value is high, this is a bug anyway, as it
would stop the OS running natively for extended periods of
time, which is not supposed to happen.
In any case, I don't see why this is an argument for *not*
virtualizing RDTSC. If RDTSC executes natively, you cannot
schedule in the host, because the host doesn't even get
control ...
> Given the RDTSC code in the Linux kernel, I think we'll
> be cool without any changes except to let RDTSC execute
> normally, and save/restore it during transitions between
> host<-->monitor/guest.
For Linux this is probably be OK, but I'm not sure in general:
normally, you have a correlation between RDTSC values and
external timer interrupts, for example. If we skew the
interrupts, but don't skew the RDTSC values (or skew them
differently: just cutting out the host execution time is
also a form of skewing), some guest OSes might notice?
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
