On Tue, Mar 14, 2017 at 07:13:19PM +0100, Paolo
On 14/03/2017 16:16, Roman Kagan wrote:
REPORT LUNS fails, then I don't think we need to iterate over
every possible lun. If this is just to workaround qemu issues, then
falling back to just using the first lun should be fine.
Perhaps. As it was trivial to code scsi_sequential_scan in addition to
scsi_rep_luns_scan, I went ahead and did it. Yes the two places where
it's used in the patchset are the ones where REPORT LUNS is known to
fail due to QEMU issues. At least for mpt-scsi it increases the number
of drives supported by SeaBIOS with the existing QEMU (it supports 2
luns per target). And no, I don't see it as very important.
At least for mpt-scsi we should fix it. lsi-scsi might be a SeaBIOS bug
too, but I don't know the hardware too well.
Do you mean fixing in SeaBIOS or in QEMU?
OK let me sum up the limitations in various places:
* in SeaBIOS:
1) only lun #0 is scanned
2) mpt_scsi_cmd() bails out on lun != 0
3) the code assumes uint8_t per lun #
The patchset removes 2), and scans with REPORT LUNS and, failing
that, sequentially luns ##0-7.
* in QEMU:
1) mptsas_scsi_info.max_lun = 1 (i.e. one can only create 2 luns per
2) the code assumes that lun# fits in uint8_t
For reference, mptsas driver in Linux allows up to 16895 luns (the
limit is tunable via module parameter).
We can remove (1), making max_lun 255, and we can fix any problems with
REPORT LUNS too.