[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] ppc icount questions
From: |
Steven Seeger |
Subject: |
Re: [Qemu-devel] ppc icount questions |
Date: |
Fri, 12 Jan 2018 13:03:59 -0500 |
On Friday, January 12, 2018 12:19:22 PM EST Paolo Bonzini wrote:
>
> Correct. I mentioned it because you also had "-icount sleep=off" in
> your previous message.
Yes I have tried both. With sleep=off, I get the faster interrupt response
(better granularity) but with sleep=on, it is poor. Again, a timer that should
fire every 87us fires every 0.040000 seconds (always this precision) while
guest is booting up and loading applications (very little guest idle time)
> Note that in general you'll have different paces when the CPU is idle
> and when it is not (because it's unlikely that emulation speed is
> exactly 10^9/2^shift; "-icount shift=auto" achieves what you want but
> loses more in determinism). This won't be visible if the guest is
> mostly idle though.
It seems to me that if the TCG keeps track of number of instructions, we
should be able to tie this to virtual timer increase. However it seems this is
not the case. There's still some processing of a notion of "time" even when
icount is used. We can be deterministic but only to some granularity and I
can't seem to figure out where that is set.
> 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.
Perhaps this is the case and I am doing something wrong somewhere.
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.
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."
Steven