On 12/01/2018 19:03, Steven Seeger wrote:
>> That's probably because the CPU runs in the background while the timers
>> run. So QEMU_CLOCK_VIRTUAL is _not_ latched while the timers run.
>> Would that explain it?
>
> Yes that would explain it. QEMU_CLOCK_VIRTUAL should increase with number of
> executed instructions, but it seems as I said above that this is still
> factoring time in somewhere. Even though time is a factor (the host must be
> able to wake up determinstically to handle the next timer deadline in the
> guest) surely the concept of QEMU_CLOCK_VIRTUAL as tied to number of executed
> instructions could remain stable.
I think this is the issue:
I/O thread vCPU thread
-----------------------------------------------------------------------
executes 1,000,000,000-th instruction
wakes up I/O thread
finds 1st timer
runs 1st timer
executes 1,000 instructions
----------- QEMU_CLOCK_VIRTUAL now is 1,000,001,000 --------------------
1st timer finishes
executes 10,000 instructions
----------- QEMU_CLOCK_VIRTUAL now is 1,000,011,000 --------------------
runs 2nd timer
> I can obtain "sort-of" decent results by using QEMU_CLOCK_VIRTUAL_RT for my
> tx
> char timer in serial.c which allows fast bootup and approximately
> determinstic
> virtual time later on in execution, but I still have issues with the number
> of
> cpu instructions executed varying between timer responses.
QEMU_CLOCK_VIRTUAL_RT is for internal use (by -icount sleep, -icount
shift=auto, etc.). You almost certainly don't need it.
Paolo
> With an interrupt every 1 second, and an interrupt every 10 ms, I would
> expect
> the vxWorks guest to respond to these interrupts with a rather accurate delay
> between them at the time the 10ms and 1 second interrupt occur at "the same
> time."
