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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > > > > > > > > > > > > > > > > > > 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 <[email protected]> > > > > > > > > > --- > > > > > > > > > Marked as RFC since it depends on the fix for this > > > > > > > > > bug > > > > > > > > > (so > > > > > > > > > it > > > > > > > > > cannot > > > > > > > > > be merged yet): > > > > > > > > > > > > > > > > > > https://lore.kernel.org/qemu-devel/[email protected] > > > > > > > > > / > > > > > > > > > > > > > > > > > > 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 <[email protected]> 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? [...] >
