| Message ID | 1380037969-26411-1-git-send-email-pbonzini@redhat.com |
|---|---|
| State | New |
| Headers | show |
On 25 September 2013 00:52, Paolo Bonzini <pbonzini@redhat.com> wrote: > If -icount is enabled with multiprocessor guests, all CPUs increment > the same counter, which then basically runs too fast by a factor of > smp_cpus. This makes little sense and complicates further a feature > whose implementation is pretty obscure already. Just forbidding -icount with SMP configs seems like the wrong fix, though -- why wouldn't you want the deterministic execution icount (claims it) gives you with an SMP config? -- PMM
Il 25/09/2013 01:39, Peter Maydell ha scritto: > On 25 September 2013 00:52, Paolo Bonzini <pbonzini@redhat.com> wrote: >> If -icount is enabled with multiprocessor guests, all CPUs increment >> the same counter, which then basically runs too fast by a factor of >> smp_cpus. This makes little sense and complicates further a feature >> whose implementation is pretty obscure already. > > Just forbidding -icount with SMP configs seems like the wrong > fix, though -- why wouldn't you want the deterministic execution > icount (claims it) gives you with an SMP config? Right now, the SMP version of icount is all but deterministic. I/O and rt_clock timers cause the TCG thread to relinquish the BQL, and the round-robin will switch to the next VCPU. Perhaps once the TCG loop breaks free of the BQL we can modify icount to trigger a VCPU switch every 2^16 instructions or something like that, and revert this patch. Paolo
diff --git a/cpus.c b/cpus.c index 6fb2bc8..e74166e 100644 --- a/cpus.c +++ b/cpus.c @@ -401,6 +401,11 @@ void configure_icount(const char *option) return; } + if (smp_cpus > 1) { + fprintf(stderr, "-icount is not allowed with SMP guests\n"); + exit(1); + } + icount_warp_timer = timer_new_ns(QEMU_CLOCK_REALTIME, icount_warp_rt, NULL); if (strcmp(option, "auto") != 0) {
If -icount is enabled with multiprocessor guests, all CPUs increment the same counter, which then basically runs too fast by a factor of smp_cpus. This makes little sense and complicates further a feature whose implementation is pretty obscure already. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> --- cpus.c | 5 +++++ 1 file changed, 5 insertions(+)