qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] ppc icount questions


From: Paolo Bonzini
Subject: Re: [Qemu-devel] ppc icount questions
Date: Fri, 12 Jan 2018 18:19:22 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0

On 12/01/2018 18:12, Steven Seeger wrote:
> On Friday, January 12, 2018 11:52:57 AM EST Paolo Bonzini wrote:
>> What is the guest doing in the meanwhile?
> 
> The guest is running vxWorks with several threads. The CPU does idle at 
> times. 
> 
>> virtual time increases only when instructions are executed, or when the
>> CPUs are idle (in the latter case, behavior depends on "-icount sleep":
>> if on, it increases at the same pace as real time, if off, it jumps
>> immediately to the next deadline).
> 
> If we jump to the next available deadline, won't that run faster than 
> realtime?

Correct.  I mentioned it because you also had "-icount sleep=off" in
your previous message.

> The preferred goal here is to run realtime (sleep as appropriate) 
> but slow down if the guest or model world requires too many host resources. 
> But, the desire would be to maintain proportionality between number of 
> instructions executed and increase in virtual 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.

> One of the things happening in the guest code is there is a once-per-second 
> interrupt and a once-per-10ms interrupt that the software expects to see in-
> phase with each other. If not, then errors occur. I am seeing errors when I 
> do 
> more work in the device model. However, even with this extra work disabled I 
> still do not see the timer granularity I expect.

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?

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]