On Tue, 16 May 2017 15:44:43 +0200 Christian Borntraeger <borntrae...@de.ibm.com> wrote:
> On 05/10/2017 05:53 PM, Eric Farman wrote: > > Today, trying to boot a guest from a SCSI LUN on s390x yields the following: > > > > virtio-blk = OK > > virtio-scsi and /dev/sdX = OK > > virtio-scsi and /dev/sgX = FAIL > > > > Example of the failing scenario: > > > > /usr/bin/qemu-system-s390x ... > > -device virtio-scsi-ccw,id=scsi0,devno=fe.0.0001 > > -drive file=/dev/sg2,if=none,id=drive0,format=raw > > -device > > scsi-generic,bus=scsi0.0,channel=0,scsi-id=0,drive=drive0,id=disk0 > > LOADPARM=[........] > > Using virtio-scsi. > > Using SCSI scheme. > > .. > > ! virtio-scsi:read_many: STATUS=02 RSPN=70 KEY=0b CODE=00 QLFR=06, sure ! > > > > Why do we care? Well, libvirt converts a virtio-scsi device from the host > > SCSI address (host:bus:target:lun) into the associated /dev/sgX device, > > which means we can't boot from virtio-scsi and have to rely on virtio-blk > > for this action. > > > > The short version of what happens is the host block device driver rejects > > our > > requests because the transfer lengths are too long for it to satisfy. > > A virtio-scsi disk connected via scsi-generic is fine as a non-boot device > > because the guest kernel is able to break up the requests for us. So we > > just > > need to handle this situation for the boot process. > > > > Patches 1-3 read the max_sectors parameter for the virtio-scsi controller, > > and break up the READ(10) I/Os into something that the host will accept. > > If not specified, max_sectors defaults to 65535, but could look like this: > > > > qemu-system-s390x ... > > -device virtio-scsi-ccw,id=scsi0,devno=fe.0.0001,max_sectors=2048 > > > > Patches 4-6 read the max_io_size parameter for the virtio-scsi disk device, > > and use the minimum of it and the max_sectors from the controller for > > breaking > > up the READ(10) I/Os. If not specified, max_io_size defaults to 2147483647 > > but could look like this: > > > > qemu-system-s390x ... > > -drive file=/dev/sda,if=none,id=drive0,format=raw ... > > -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0, > > drive=drive0,id=disk0,max_io_size=1048576 > > > > In the two examples above, the maximum parameters are equivalent due to the > > controller parameter measuring 512-byte blocks, and the disk measuring > > bytes. > > > > Patch 7 establishes a workable default, in case neither the controller nor > > the disk have the parameters specified (and thus the overly large defaults > > are taken), or if they are set to something beyond what we can boot from. > > > > Patch 8 rebuilds the s390-ccw BIOS with this entire patch set. > > > > Changelog: > > > > RFC v2: > > - Dropped patch outside the pc-bios/s390-ccw/ tree > > - Added Christian's r-b to patch 1 (formerly patch 2) > > - Added EVPD Inquiry calls to retrieve Block Limits page if supported > > - Added a default if Block Limits page is not supported, or response is > > still way to big to allow boot > > RFC v1: > > - https://lists.nongnu.org/archive/html/qemu-devel/2017-04/msg05121.html > > > > Eric Farman (8): > > pc-bios/s390-ccw: Remove duplicate blk_factor adjustment > > pc-bios/s390-ccw: Move SCSI block factor to outer read > > pc-bios/s390-ccw: Break up virtio-scsi read into multiples > > pc-bios/s390-ccw: Refactor scsi_inquiry function > > pc-bios/s390-ccw: Get list of supported VPD pages > > pc-bios/s390-ccw: Get Block Limits VPD device data > > pc-bios/s390-ccw: Build a reasonable max_sectors limit > > pc-bios/s390-ccw.img: rebuild image > > > > pc-bios/s390-ccw.img | Bin 26472 -> 26480 bytes > > pc-bios/s390-ccw/s390-ccw.h | 7 ++++ > > pc-bios/s390-ccw/scsi.h | 30 +++++++++++++++ > > pc-bios/s390-ccw/virtio-scsi.c | 85 > > +++++++++++++++++++++++++++++++++++------ > > pc-bios/s390-ccw/virtio-scsi.h | 2 + > > pc-bios/s390-ccw/virtio.h | 1 + > > 6 files changed, 114 insertions(+), 11 deletions(-) > > > > Patch set looks good. Conny, can you apply the series? > I had hoped for some comments from folks more familiar with scsi... Nevertheless, applied to s390-next.
