qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] -rtc clock=vm with -icount 1, sleep=off introduces unex


From: Pavel Dovgalyuk
Subject: Re: [Qemu-devel] -rtc clock=vm with -icount 1, sleep=off introduces unexpected delays in device interactions
Date: Tue, 14 Mar 2017 15:10:19 +0300

> From: Alex Bennée [mailto:address@hidden
> > I also encountered icount problems with new MTTCG patches.
> >
> > Record/replay now cannot work, because iothread requests timers
> > without kicking the CPU. And cpu thread updates icount (that
> > are used for the clock).
> 
> The interaction of kicking the vCPU while grabbing the BQL was a
> side-effect. This is now done explicitly for single-threaded emulation
> by (6546706d28):
> 
>   tcg: add kick timer for single-threaded vCPU emulation

This is not the same.
BQL helped in making execution deterministic - no io and timer
callbacks were performed while CPU is executing.
Now iothread and CPU thread work simultaneously and timers can't
query virtual time correctly, because (if we could query number of executed
instructions) it may have different values on different runs.

I guess you'll have to bring kicking CPU back on iothread invocation
to make execution deterministic in icount mode.

> 
> > Therefore invocation of iothread uses incorrect clock and
> > all virtual timers behave incorrectly.
> >
> > Record/replay is also broken because current icount is requested
> > from iothread where current_cpu (and icount progress stored in icount_extra)
> > is unavailable.
> 
> I'm working through Paolo's series now but I don't see it as
> insurmountable. The aim of keeping current_cpu set only during the
> cpu-exec loop was intentional because the system as a whole can't make
> assumptions about it always being valid.


Pavel Dovgalyuk




reply via email to

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