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

[Eric Farman <farman@linux.vnet.ibm.com>]

On 04/26/2017 11:48 AM, Christian Borntraeger wrote:
> 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?
>

Looking at some old traces I have, I think I misspoke that it's the 
guest kernel.  In the failing case, the host kernel is processing an 
ioctl system call via sg_ioctl, and just passing our I/O transaction to 
the block driver.  It blows up because the number of iovecs needed for 
the transaction exceeds UIO_MAXIOV.  In the working case (boot from 
virtio-scsi as /dev/sdX or virtio-blk), the host kernel goes through 
read system call, and the I/O is broken up by do_generic_file_read.