Re: [RFC PATCH] tests/functional/s390x: Add reverse debugging test for s390x

[Ilya Leoshkevich <iii@linux.ibm.com>]

On Mon, 2025-12-01 at 12:17 +0100, Ilya Leoshkevich wrote:
> On Mon, 2025-12-01 at 10:36 +0000, Alex Bennée wrote:
> > Ilya Leoshkevich <iii@linux.ibm.com> writes:
> > 
> > > On Sun, 2025-11-30 at 20:03 +0100, Ilya Leoshkevich wrote:
> > > > On Sun, 2025-11-30 at 19:32 +0100, Ilya Leoshkevich wrote:
> > > > > On Sun, 2025-11-30 at 16:47 +0000, Alex Bennée wrote:
> > > > > > Ilya Leoshkevich <iii@linux.ibm.com> writes:
> > > > > > 
> > > > > > > On Fri, 2025-11-28 at 18:25 +0100, Ilya Leoshkevich
> > > > > > > wrote:
> > > > > > > > On Fri, 2025-11-28 at 14:39 +0100, Thomas Huth wrote:
> > > > > > > > > From: Thomas Huth <thuth@redhat.com>
> > > > > > > > > 
> > > > > > > > > We just have to make sure that we can set the
> > > > > > > > > endianness to
> > > > > > > > > big
> > > > > > > > > endian,
> > > > > > > > > then we can also run this test on s390x.
> > > > > > > > > 
> > > > > > > > > Signed-off-by: Thomas Huth <thuth@redhat.com>
> > > > > > > > > ---
> > > > > > > > >  Marked as RFC since it depends on the fix for this
> > > > > > > > > bug
> > > > > > > > > (so
> > > > > > > > > it
> > > > > > > > > cannot
> > > > > > > > >  be merged yet):
> > > > > > > > >  
> > > > > > > > > https://lore.kernel.org/qemu-devel/a0accce9-6042-4a7b-a7c7-218212818891@redhat.com
> > > > > > > > > /
> > > > > > > > > 
> > > > > > > > >  tests/functional/reverse_debugging.py        |  4
> > > > > > > > > +++-
> > > > > > > > >  tests/functional/s390x/meson.build           |  1 +
> > > > > > > > >  tests/functional/s390x/test_reverse_debug.py | 21
> > > > > > > > > ++++++++++++++++++++
> > > > > > > > >  3 files changed, 25 insertions(+), 1 deletion(-)
> > > > > > > > >  create mode 100755
> > > > > > > > > tests/functional/s390x/test_reverse_debug.py

[...]

> > > I believe now I at least understand what the race is about:
> > > 
> > > - cpu_post_load() fires the TOD timer immediately.
> > > 
> > > - s390_tod_load() schedules work for firing the TOD timer.
> > 
> > Is this a duplicate of work then? Could we just rely on one or the
> > other? If you drop the cpu_post_load() tweak then the vmstate load
> > helper should still ensure everything works right?
> 
> Getting rid of it fixes the problem and makes sense anyway.

Hmm, on the other hand, this appears to have been done this way
deliberately:


commit 7c12f710bad60dc7e509da4e80c77e952ef0490c
Author: David Hildenbrand <david@kernel.org>
Date:   Wed Jun 27 15:44:09 2018 +0200

    s390x/tcg: rearm the CKC timer during migration
    
    If the CPU data is migrated after the TOD clock, the CKC timer of a
CPU
    is not rearmed. Let's rearm it when loading the CPU state.
    
    Introduce tcg-stub.c just like kvm-stub.c for tcg specific stubs.


I guess introducing a dependency on migration order is indeed not great
for maintainability.

> > > - If rr loop sees work and then timer, we get one timer callback.
> > > 
> > > - If rr loop sees timer and then work, we get two timer
> > > callbacks.
> > 
> > If the timer is armed we should expect at least to execute a few
> > instructions before triggering the timer, unless it was armed ready
> > expired.
> 
> Yes, it is armed expired.
> 
> 
> Isn't it a deficiency in record-replay that work and timers are not
> ordered relative to each other? Can't it bite us somewhere else?

[...]
>