* d/p/u/lp2059272-2-qemu-Wait-qemuProcessReconnect-threads-in-cleanup.patch:
Remove patch. It is not possible to wait for qemuProcessReconnect()
in cleanup: it talks to QEMU monitor, which blocks on replies from
event loop, but it's already stopped at cleanup, delaying shutdown.
* d/p/u/lp2059272-2-qemu-Do-not-save-XML-in-shutdown-on-init.patch:
Instead of waiting at cleanup for threads which might be blocked
thus would _not even reach_ the function that causes the problem,
just skip that function if it is _actually reached_ while daemon
shutdown is in progress. That is in the init path and would just
run again anyway the next time libvirtd is started (LP: #2059272)
* NOTE: This package contains the changes from 6.0.0-0ubuntu8.18 and
6.0.0-0ubuntu8.17 in focal-proposed (with symbolic changelog entry)
superseded by 6.0.0-0ubuntu8.19 in focal-security.
* d/p/u/lp2059272-1-qemu-Fix-potential-crash-during-driver-cleanup.patch:
On QEMU driver cleanup, release (stop) the worker thread pool _first_,
before other data used by possibly running worker threads (LP: #2059272)
* d/p/u/lp2059272-2-qemu-Wait-qemuProcessReconnect-threads-in-cleanup.patch:
On QEMU driver cleanup, also wait for qemuProcessReconnect() threads,
as they are independent of the worker thread pool. (LP: #2059272)
Focal needs this as it has no .stateShutdownWait() callback yet.
(The wait timeout is set in LIBVIRT_QEMU_STATE_CLEANUP_WAIT_TIMEOUT:
-1 = wait indefinitely; 0 = do not wait; N = wait up to N seconds.)
This bug was fixed in the package libvirt - 6.0.0-0ubuntu8.20
---------------
libvirt (6.0.0-0ubuntu8.20) focal; urgency=medium
* d/p/u/lp2059272 -2-qemu- Wait-qemuProces sReconnect- threads- in-cleanup. patch: nnect()
Remove patch. It is not possible to wait for qemuProcessReco
in cleanup: it talks to QEMU monitor, which blocks on replies from
event loop, but it's already stopped at cleanup, delaying shutdown.
* d/p/u/lp2059272 -2-qemu- Do-not- save-XML- in-shutdown- on-init. patch:
Instead of waiting at cleanup for threads which might be blocked
thus would _not even reach_ the function that causes the problem,
just skip that function if it is _actually reached_ while daemon
shutdown is in progress. That is in the init path and would just
run again anyway the next time libvirtd is started (LP: #2059272)
* NOTE: This package contains the changes from 6.0.0-0ubuntu8.18 and 0-0ubuntu8. 17 in focal-proposed (with symbolic changelog entry)
6.0.
superseded by 6.0.0-0ubuntu8.19 in focal-security.
libvirt (6.0.0- 0ubuntu8. 20~ubuntu8. 18) focal; urgency=medium
* d/p/u/lp2059272 -1-qemu- Fix-potential- crash-during- driver- cleanup. patch:
On QEMU driver cleanup, release (stop) the worker thread pool _first_,
before other data used by possibly running worker threads (LP: #2059272)
* d/p/u/lp2059272 -2-qemu- Wait-qemuProces sReconnect- threads- in-cleanup. patch: nnect() threads, ait() callback yet. QEMU_STATE_ CLEANUP_ WAIT_TIMEOUT:
On QEMU driver cleanup, also wait for qemuProcessReco
as they are independent of the worker thread pool. (LP: #2059272)
Focal needs this as it has no .stateShutdownW
(The wait timeout is set in LIBVIRT_
-1 = wait indefinitely; 0 = do not wait; N = wait up to N seconds.)
libvirt (6.0.0- 0ubuntu8. 20~ubuntu8. 17) focal; urgency=medium
* d/p/u/lp- 1989078- *.patch: allow arm64 to lock its OVMF/AAVMF resources
(LP: #1989078)
-- Mauricio Faria de Oliveira <email address hidden> Tue, 16 Apr 2024 14:20:13 -0300