>It is possible, cleaner, and more modular to structure the
>directories as you have above.
Right, fully agreed. :)
>I always said that timing reference should be derived by the
>monitor, and not the user space code. Ultimately the timing
>framework, and important function such as the PICs/PITs
>should be moved to the monitor, as well as low-level functionality
>from other critical components.
Agreed. If we put as much as possible in the monitor, we beware
unnecessary and costly context switches.
>Though when we do read the TSC, it is very accurate,
Hm, accuracy in timing and virtualization are two things. With only
one os on one hardware, it's no problem: the time the os sees is
the time the hardware delivers and this is the time the clock on
the wall shows. All times are running uniformly. But what to do
with our guest? We can try to let the "guest clock" running like
the "hardware clock", what's like the wall clock. But the the
guest will recognize "leaps": for instance, one time the execution
of an instruction takes 4 cycles, another time 6000 (or what a
large number), because other os'es are running in the meantime,
interrupts are to be handled and so on. May be, this leaps confuse linux.
We can also pretend a continous time to the guest to beware this
leaps, but this isn't only involved (and costly), this leads to
other problems. For instance in driving devices like CD-R-burners
or radio controlled clocks.
Guess you mean "accurate" with regard to the first case: let the
guests clock run as close as possible to the hardware- and wall
clock, no? Then we have to trade of two things: let the guest run
as long as possible without interferences and being interruptable
as good as possible. Not easy, yes.
I know, all you guys know these facts, but perhaps it's not bad
to summarize and remind them... ;)
jens
