On Tue, 6 Feb 2024 19:37:46 +0300 Michael Tokarev wrote:
03.02.2024 12:47, Michael Tokarev wrote:
>>> It looks like we broke suspend/resume in this version of qemu.
>> Oops. Is that related to the cryptsetup failure, or a separate issue?
>
> Yes, it is related to cryptsetup autopkgtest failure. It looks
> like this is the only place where suspend/resume code in qemu
> is actually being used, - it's rather rare to suspend (hybernate)
> a virtual machine, and cryptsetup performs testing of how the
> encrypted filesystem is unlocked (or not) on resume.
So, while the problematic upstream commit fixes quite a few real
potential qemu lockups, it introduces a new lockup in suspend-
resume-hibernate cycle. The problem isn't understood yet, and
we're getting close to the 12.5 release.
The problematic upstream commit (on master) is this one:
https://gitlab.com/qemu-project/qemu/-/commit/effd60c878176bcaf97fa7ce2b12d04bb8ead6f7
It has links to 2 bugs it is fixing, and there are quite a few
other bugs which are fixed too.
It turned out this commit was innocent. The bug most likely is
somewhere in qemu, but it is triggered by the guest kernel, it
looks like, not by this qemu commit. Current bookworm kernels
(6.1.19 and 6.1.20) fails in this same suspend/resume test in
all current versions of qemu, including the ones with this
commit applied, including current qemu master, and including
versions much older than that, - including original qemu as
initially released with bookworm, before all updates.
It is not yet clear what's going on here. But we'll have to
live with that somehow, and, - I guess - have to live with
the broken cryptsetup autopkgtests.
I'm preparing a new upstream stable/bugfix version of qemu 7.2.x
for bookworm, which will include a few CVE fixes, many other
fixes all other the place, and re-introduction of this commit
too, - which, as it turns out, has actually nothing to do with
the broken suspend-resume.
Thanks,
/mjt
