I pulled 7.1, and the megasas driver stopped being able to do reads
from a disk.
It looks to be related to this commit:
https://github.com/qemu/qemu/commit/fe9d8927e265fd723a6dc87cd6d220f4677dbe1f#diffe3f5f30efc54747e0624dca63e5f55f0012736c1875b6e85526b3514e6911be3
which added some command buffer bounds checking to the SCSI subsysem.
Unfortunately,
when the megasas QEMU emulation receives a direct I/O command from the device
driver
in megasas_handle_io(), it synthesizes a SCSI command from it in
megasas_encode_lba(),
but passes the command buffer length from the driver frame instead of the
length of the
buffer it synthesized the SCSI command in. The driver (at least the Linux 4.14
version
I’m using) does not fill in the command buffer length in direct I/O frames, so
scsi_req_new() sees a 0 length command and fails it.
I worked around this issue with:
diff --git a/hw/scsi/megasas.c b/hw/scsi/megasas.c
index 7082456..6e11607 100644
--- a/hw/scsi/megasas.c
+++ b/hw/scsi/megasas.c
@@ -1823,7 +1823,7 @@ static int megasas_handle_io(MegasasState *s, MegasasCmd
*cmd, int frame_cmd)
megasas_encode_lba(cdb, lba_start, lba_count, is_write);
cmd->req = scsi_req_new(sdev, cmd->index,
- lun_id, cdb, cdb_len, cmd);
+ lun_id, cdb, sizeof (cdb), cmd);
if (!cmd->req) {
trace_megasas_scsi_req_alloc_failed(
mfi_frame_desc(frame_cmd), target_id, lun_id);
and the driver can read the disk again, but I’m not sure this is the correct
fix since cdb_len is used for bounds checking elsewhere in megagsas_handle_io(),
although a 0 won’t fail there.
Is there anyone with megasas experience who could comment on this?