> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> On 26/11/2014 11:40, Pavel Dovgalyuk wrote:
> > + * @QEMU_CLOCK_VIRTUAL_RT: realtime clock used for icount warp
> > + *
> > + * This clock runs as a realtime clock, but is used for icount warp
> > + * and thus should be traced with record/replay to make warp function
> > + * behave deterministically.
> > */
>
> I think it should also stop/restart across "stop" and "cont" commands,
> similar to QEMU_CLOCK_VIRTUAL. This is as simple as changing
> get_clock() to cpu_get_clock().
>
> This way, QEMU_CLOCK_VIRTUAL_RT is "what QEMU_CLOCK_VIRTUAL does without
> -icount". This makes a lot of sense and can be merged in 2.3
> independent of the rest of the series.
I've updated QEMU to master and started testing changed that you proposed.
And one more problem came out here. The problem is related to patch
60e68042cf70f271308dc6b4b22b609d054af929
It changes x86_cpu_has_work function. And this function instead of just
checking the CPU state changes it:
- return ((cs->interrupt_request & (CPU_INTERRUPT_HARD |
- CPU_INTERRUPT_POLL)) &&
+#if !defined(CONFIG_USER_ONLY)
+ if (cs->interrupt_request & CPU_INTERRUPT_POLL) {
+ apic_poll_irq(cpu->apic_state);
+ cpu_reset_interrupt(cs, CPU_INTERRUPT_POLL);
+ }
+#endif
+
+ return ((cs->interrupt_request & CPU_INTERRUPT_HARD) &&
These changes break the deterministic execution, because cpu_has_work() may be
called at
any moment of the execution.
When POLL interrupt request is processed by x86_cpu_exec_interrupt function, as
it were before,
everything is ok, because I ensure that these calls occur at the same moments
in record/replay.
Pavel Dovgalyuk
