On 15/03/2017 12:33, Roman Kagan wrote:
On Tue, Mar 14, 2017 at 07:13:19PM +0100, Paolo Bonzini wrote:
On 14/03/2017 16:16, Roman Kagan wrote:
- if 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:
mpt-scsi:
in SeaBIOS:
- only lun #0 is scanned
- mpt_scsi_cmd() bails out on lun != 0
- 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:
- mptsas_scsi_info.max_lun = 1 (i.e. one can only create 2 luns per
target) 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.
Paolo