Re: [Qemu-devel] [RFC PATCH v1 0/5] Enable virtio-scsi boot from /dev/sgX

[Christian Borntraeger]

On 04/26/2017 04:46 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 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.

Out of curiosity. Why is the guest kernel submitting "short enough" requests?
If it querying the device itself via scsi commands before issuing commands?