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 _______________________________________________ SeaBIOS mailing list [email protected] https://www.coreboot.org/mailman/listinfo/seabios
