Re: [Qemu-devel] [RFC PATCH v2 0/8] s390x: Enable virtio-scsi boot from /dev/sgX

[Cornelia Huck]

On Wed, 10 May 2017 17:53:51 +0200
Eric Farman <address@hidden> 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.

This patch set looks reasonable to me, but I have not delved into the
scsi particulars :)

The code changes seem to be fine, so if someone with more scsi
knowledge than me could give their ok as well, I'll be happy to take
this through my s390 tree.