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(-)
--
2.10.2
