Re: [Qemu-devel] ppc icount questions

[Paolo Bonzini <pbonzini@redhat.com>]

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."