blob: 6bfe1ab10ee41fef970a3c38b90ffbe1dbff2cf3 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
<think>
Okay, I'm trying to figure out whether this bug in QEMU is related to user-mode or system-mode issues. The problem occurs when using the virtio-scsi driver, which interacts with a block device. When the underlying device returns an -EIO error, QEMU segfaults.
Looking at the stack trace provided, it seems like there's an assertion failure in scsi_req_complete. The function is expecting req->status to be -1 but gets something else instead. This suggests that the request handling isn't properly completing or is encountering unexpected states.
The bisected commit points to changes in how error handling works for rerror and werror being ignored. Paolo's fix was about calling scsi_req_complete when these errors are handled, which indicates it's part of the SCSI subsystem handling I/O operations.
Since virtio-scsi is a device driver and deals with block I/O, this falls under system-level functionality. QEMU emulates hardware devices, and issues in drivers like virtio-scsi typically relate to how the virtual machine interacts with these devices at a lower level, which involves more privileged operations.
The stack trace shows calls from SCSI bus handling down into block device operations, and even into DMA helpers and thread management. These are all components that handle system-level tasks such as device I/O, memory management, and concurrency control, which aren't part of the user application space but rather the virtualized hardware and OS layer.
Therefore, this bug is likely related to how QEMU handles errors in its SCSI driver at a low level, affecting the stability and correct operation of the virtual machine's devices. It doesn't seem like it's an issue with user-space applications running inside the VM but rather with the hypervisor's handling of hardware emulation.
</think>
system
|