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:
* 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.