qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: steven.seeger@flightsystems.net
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] ppc icount questions
Date: Fri, 12 Jan 2018 18:19:22 +0100	[thread overview]
Message-ID: <15b90f94-f01a-2755-d2c2-ea74ab213576@redhat.com> (raw)
In-Reply-To: <3481129.GfW4dsff78@wirbelwind>

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	other threads:[~2018-01-12 17:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-12 16:19 [Qemu-devel] ppc icount questions Steven Seeger
2018-01-12 16:52 ` Paolo Bonzini
2018-01-12 17:12   ` Steven Seeger
2018-01-12 17:19     ` Paolo Bonzini [this message]
2018-01-12 18:03       ` Steven Seeger
2018-01-12 18:11         ` Paolo Bonzini
2018-01-12 18:35           ` Steven Seeger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=15b90f94-f01a-2755-d2c2-ea74ab213576@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=steven.seeger@flightsystems.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).