Comment 13 for bug 2051965

Hi Sergio,

Thank you for your reply! I'm glad the explanations helped!

> Right now, I'm trying to reproduce the problem with qemu from Jammy (I managed to reproduce it using Mantic). I'm a little bit puzzled to see that the qemu crashed quicker on Mantic (I've been running the test on Jammy for more than 2 hours now, and it still hasn't crashed). Anyway, I'll leave it running overnight.

I also noticed that it was easier to have QEmu crashed on Mantic than on Jammy. On the other hand, when I first tried to reproduce the issue on Jammy, most of the time, it was taking around 50 iterations to hit the kernel panic. Sometimes, it was taking < 10 iterations, but also sometimes around ~150/200.

> Huh, the test has just finished on Jammy and the crash didn't happen.

Arf, sorry for that :-/
I guess 'virtme' was correctly patched not to use KVM, right?

Maybe try with more than 250 iterations by modifying the ".virtme-exec-run" file? e.g. 500? Or no limit by using 'run_loop' instead of 'run_loop_n 250' and leave it running overnight? It is hard to predict when a concurrency bug will happen.

> Another thing that's concerning is the difference in the codebase from qemu 6.2 (the version from Jammy) and 8.x. I started backporting the upstream patches into Jammy and noticed that there are non-trivial conflicts to be solved.

Thank you for having looked at that! Maybe the QEmu community can help for that? I don't know how it usually work.

> I apologize for the slow progress here. I'm spread thin across many tasks so I have to timebox my work on this bug.

That's OK, take your time. On my side, I have a workaround by using a kernel patch. I will be happy to remove it, but I mainly reported the issue to help other people also using QEmu < 8.1 without KVM and with a guest kernel >= 6.3, because it might not be obvious the issue is due to QEmu and not the guest kernel.