[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH v1 0/5] Enable virtio-scsi boot from /dev/sg
Re: [Qemu-devel] [RFC PATCH v1 0/5] Enable virtio-scsi boot from /dev/sgX
Wed, 26 Apr 2017 12:13:51 -0400
Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
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:
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.