blockcmd: start REPORT_LUNS with the smallest buffer

A number of emulated SCSI devices in QEMU incorrectly return an error
to REPORT_LUNS command when the size of the data returned is smaller
than the allocation length passed in.

To work it around, start with the smallest allocation length possible:
for 1 entry.  This is a slight pessimization because it would require
another REPORT_LUNS iteration if the target has more than a single LUN,
but this appears to have negligible impact on boot times, and makes
REPORT_LUNS enumeration work for more QEMU devices (lsi53c895a,
mptsas1068).

Reported-by: Maciej Józefczyk <maciej.jozefczyk@corp.ovh.com>
Signed-off-by: Roman Kagan <rkagan@virtuozzo.com>

diff --git a/src/hw/blockcmd.c b/src/hw/blockcmd.c
index 324188d7313f9069e8648f3b181cdd82eb3ad2d8..98c06cedad01ff2c3135d9ebc04d3689c7c3d1ee 100644 (file)
--- a/src/hw/blockcmd.c
+++ b/src/hw/blockcmd.c
@@ -215,7 +215,9 @@ static u64 scsilun2u64(struct scsi_lun *scsi_lun)
 int scsi_rep_luns_scan(struct drive_s *tmp_drive, scsi_add_lun add_lun)
 {
     int ret = -1;
-    u32 maxluns = 511;
+    /* start with the smallest possible buffer, otherwise some devices in QEMU
+     * may (incorrectly) error out on returning less data than fits in it */
+    u32 maxluns = 1;
     u32 nluns, i;
     struct cdb_report_luns cdb = {
         .command = CDB_CMD_REPORT_LUNS,