Branch: refs/heads/staging-8.2
Home: https://github.com/qemu/qemu
Commit: 9c605185c2e0ad1d47a5008027ef27d90f57fcbd
https://github.com/qemu/qemu/commit/9c605185c2e0ad1d47a5008027ef27d90f57fcbd
Author: Daan De Meyer <[email protected]>
Date: 2025-04-10 (Thu, 10 Apr 2025)
Changed paths:
M hw/smbios/smbios.c
Log Message:
-----------
smbios: Fix buffer overrun when using path= option
We have to make sure the array of bytes read from the path= file
is null-terminated, otherwise we run into a buffer overrun later on.
Fixes: bb99f4772f54017490e3356ecbb3df25c5d4537f ("hw/smbios: support loading
OEM strings values from a file")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2879
Signed-off-by: Daan De Meyer <[email protected]>
Reviewed-by: Daniel P. Berrangé <[email protected]>
Tested-by: Valentin David <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit a7a05f5f6a4085afbede315e749b1c67e78c966b)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: fc2b3245692eb54a626ead17d47cc43942069673
https://github.com/qemu/qemu/commit/fc2b3245692eb54a626ead17d47cc43942069673
Author: Kevin Wolf <[email protected]>
Date: 2025-04-10 (Thu, 10 Apr 2025)
Changed paths:
M hw/scsi/scsi-disk.c
Log Message:
-----------
scsi-disk: Use positive return value for status in dma_readv/writev
In some error cases, scsi_block_sgio_complete() never calls the passed
callback, but directly completes the request. This leads to bugs because
its error paths are not exact copies of what the callback would normally
do.
In preparation to fix this, allow passing positive return values to the
callbacks that represent the status code that should be used to complete
the request.
scsi_handle_rw_error() already handles positive values for its ret
parameter because scsi_block_sgio_complete() calls directly into it.
Signed-off-by: Kevin Wolf <[email protected]>
Acked-by: Paolo Bonzini <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit cfe0880835cd364b590ffd27ef8dbd2ad8838bc5)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: f4c342a0797e119478ff3a583d75c2f0fe782399
https://github.com/qemu/qemu/commit/f4c342a0797e119478ff3a583d75c2f0fe782399
Author: Kevin Wolf <[email protected]>
Date: 2025-04-10 (Thu, 10 Apr 2025)
Changed paths:
M hw/scsi/scsi-disk.c
Log Message:
-----------
scsi-block: Don't skip callback for sgio error status/driver_status
Instead of calling into scsi_handle_rw_error() directly from
scsi_block_sgio_complete() and skipping the normal callback, go through
the normal cleanup path by calling the callback with a positive error
value.
The important difference here is not only that the code path is cleaner,
but that the callbacks set r->req.aiocb = NULL. If we skip setting this
and the error action is BLOCK_ERROR_ACTION_STOP, resuming the VM runs
into an assertion failure in scsi_read_data() or scsi_write_data()
because the dangling aiocb pointer is unexpected.
Fixes: a108557bbf ("scsi: inline sg_io_sense_from_errno() into the callers.")
Buglink: https://issues.redhat.com/browse/RHEL-50000
Signed-off-by: Kevin Wolf <[email protected]>
Acked-by: Paolo Bonzini <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit 622a70161ac258e4a166a7dca4b5be267e0652d9)
(Mjt: also remove locking code which has been removed by
v8.2.0-126-g1404226804 "scsi: don't lock AioContext in I/O code path")
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 9da48f6f0fce18642e77498c592655669c1332e2
https://github.com/qemu/qemu/commit/9da48f6f0fce18642e77498c592655669c1332e2
Author: Kevin Wolf <[email protected]>
Date: 2025-04-10 (Thu, 10 Apr 2025)
Changed paths:
M hw/scsi/scsi-disk.c
Log Message:
-----------
scsi-disk: Add warning comments that host_status errors take a shortcut
scsi_block_sgio_complete() has surprising behaviour in that there are
error cases in which it directly completes the request and never calls
the passed callback. In the current state of the code, this doesn't seem
to result in bugs, but with future code changes, we must be careful to
never rely on the callback doing some cleanup until this code smell is
fixed. For now, just add warnings to make people aware of the trap.
Signed-off-by: Kevin Wolf <[email protected]>
Acked-by: Paolo Bonzini <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit 8a0495624f23f8f01dfb1484f367174f3b3572e8)
(Mjt: fix for e7fc3c4a8cc "scsi: remove outdated AioContext lock comment")
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 2870b84a298e5821d24304ae593485db14d91b4d
https://github.com/qemu/qemu/commit/2870b84a298e5821d24304ae593485db14d91b4d
Author: Kevin Wolf <[email protected]>
Date: 2025-04-10 (Thu, 10 Apr 2025)
Changed paths:
M hw/scsi/scsi-disk.c
Log Message:
-----------
scsi-disk: Always report RESERVATION_CONFLICT to guest
In the case of scsi-block, RESERVATION_CONFLICT is not a backend error,
but indicates that the guest tried to make a request that it isn't
allowed to execute. Pass the error to the guest so that it can decide
what to do with it.
Without this, if we stop the VM in response to a RESERVATION_CONFLICT
(as is the default policy in management software such as oVirt or
KubeVirt), it can happen that the VM cannot be resumed any more because
every attempt to resume it immediately runs into the same error and
stops the VM again.
One case that expects RESERVATION_CONFLICT errors to be visible in the
guest is running the validation tests in Windows 2019's Failover Cluster
Manager, which intentionally tries to execute invalid requests to see if
they are properly rejected.
Buglink: https://issues.redhat.com/browse/RHEL-50000
Signed-off-by: Kevin Wolf <[email protected]>
Acked-by: Paolo Bonzini <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit 9da6bd39f92434f55573acd017841b195c60188f)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: e16c98b0e0db2f9a012e313159b263a8f347f80a
https://github.com/qemu/qemu/commit/e16c98b0e0db2f9a012e313159b263a8f347f80a
Author: Kevin Wolf <[email protected]>
Date: 2025-04-10 (Thu, 10 Apr 2025)
Changed paths:
M hw/scsi/scsi-disk.c
Log Message:
-----------
scsi-disk: Apply error policy for host_status errors again
Originally, all failed SG_IO requests called scsi_handle_rw_error() to
apply the configured error policy. However, commit f3126d65, which was
supposed to be a mere refactoring for scsi-disk.c, broke this and
accidentally completed the SCSI request without considering the error
policy any more if the error was signalled in the host_status field.
Apart from the commit message not describing the change as intended,
errors indicated in host_status are also obviously backend errors and
not something the guest must deal with independently of the error
policy.
This behaviour means that some recoverable errors (such as a path error
in multipath configurations) were reported to the guest anyway, which
might not expect it and might consider its disk broken.
Make sure that we apply the error policy again for host_status errors,
too. This addresses an existing FIXME comment and allows us to remove
some comments warning that callbacks weren't always called. With this
fix, they are called in all cases again.
The return value passed to the request callback doesn't have more free
values that could be used to indicate host_status errors as well as SAM
status codes and negative errno. Store the value in the host_status
field of the SCSIRequest instead and use -ENODEV as the return value (if
a path hasn't been reachable for a while, blk_aio_ioctl() will return
-ENODEV instead of just setting host_status, so just reuse it here -
it's not necessarily entirely accurate, but it's as good as any errno).
Cc: [email protected]
Fixes: f3126d65b393 ('scsi: move host_status handling into SCSI drivers')
Signed-off-by: Kevin Wolf <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Stefan Hajnoczi <[email protected]>
Reviewed-by: Hanna Czenczek <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit 61b6d9b749ba233784c7214cfe9585ea321159dc)
(Mjt: comment fixup for previous fixup)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: edbf58cfd227467767916edd331a0dd815b49e6d
https://github.com/qemu/qemu/commit/edbf58cfd227467767916edd331a0dd815b49e6d
Author: Pierrick Bouvier <[email protected]>
Date: 2025-04-15 (Tue, 15 Apr 2025)
Changed paths:
M plugins/loader.c
Log Message:
-----------
plugins/loader: fix deadlock when resetting/uninstalling a plugin
Reported and fixed by Dmitry Kurakin.
Fixes: https://gitlab.com/qemu-project/qemu/-/issues/2901
Signed-off-by: Pierrick Bouvier <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Alex Bennée <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit c07cd110a1824e2d046581af7375f16dac26e96f)
Signed-off-by: Michael Tokarev <[email protected]>
Compare: https://github.com/qemu/qemu/compare/1c1110ebbb2b...edbf58cfd227
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
