[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH v1 0/9] MTTCG and record/replay fixes for rc
|
From: |
Paolo Bonzini |
|
Subject: |
Re: [Qemu-devel] [RFC PATCH v1 0/9] MTTCG and record/replay fixes for rc3 |
|
Date: |
Mon, 3 Apr 2017 19:03:55 +0200 |
|
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 |
On 03/04/2017 14:45, Alex Bennée wrote:
> cpus: check cpu->running in cpu_get_icount_raw()
>
> I'm not sure the race happens and once outside of cpu->running the
> icount counters should be zero. However it seems a sensible
> precaution.
Yeah, I think this is unnecessary with patch 7's new assertions.
> I think the cpus: patches should probably go into the next
> pull-request while we see if we can come up with a better final
> solution for fixing record/replay. However given how long this
> regression has run during the release candidate process I wanted to
> update everyone on the current status and get feedback ASAP.
I agree. I'm not sure exactly how the final race happens, but if it
causes divergence it would be caught later by the record/replay
mechanism, I think.
Paolo
[Qemu-devel] [RFC PATCH v1 9/9] replay: gracefully handle backward time events, Alex Bennée, 2017/04/03
[Qemu-devel] [RFC PATCH v1 4/9] target/i386/misc_helper: wrap BQL around another IRQ generator, Alex Bennée, 2017/04/03
[Qemu-devel] [RFC PATCH v1 3/9] scripts/replay-dump.py: replay log dumper, Alex Bennée, 2017/04/03
Re: [Qemu-devel] [RFC PATCH v1 0/9] MTTCG and record/replay fixes for rc3,
Paolo Bonzini <=