qemu-devel
[Top][All Lists]
Advanced

[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


From: Eric Farman
Subject: Re: [Qemu-devel] [RFC PATCH v1 0/5] Enable virtio-scsi boot from /dev/sgX
Date: Wed, 26 Apr 2017 12:13:51 -0400
User-agent: 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:

  /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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]