[SeaBIOS] [PATCH 0/9] add support for generic lun enumeration

[Paolo Bonzini]

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