[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eric Farman
Subject: [Qemu-devel] [RFC PATCH v1 0/5] Enable virtio-scsi boot from /dev/sgX
Date: Wed, 26 Apr 2017 16:46:40 +0200

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

Patches 2-N in this series do that, but rely on us to specify the max_sectors
parameter for the virtio-scsi-ccw device:

  /usr/bin/qemu-system-s390x ...
    -device virtio-scsi-ccw,id=scsi0,devno=fe.0.0001,max_sectors=2048

Without this, the default of xFFFF is used and we still end up exceeding
the limit in the host drivers.  Which is why we have Patch 1, and thus the
"RFC" tag on this series.  The backing block device has a maximum transfer
value calculated with the help of the BLKSECTGET ioctl[1][2].

With patch 1 applied, we are able to go through the children devices and
apply any known limit received from this IOCTL, and thus break up our requests
before submitting them to the host.  It is admittedly a little coarse, since
the max_sectors value is associated with the virtio-scsi controller and
multiple devices can be attached to it, not all of which are associated
with our boot device.  Meanwhile, each attached device can have its own
maximum transfer from the backing device.


Eric Farman (5):
  hw/scsi: Override the max_sectors value for virtio-scsi
  pc-bios/s390-ccw: Remove duplicate blk_factor adjustment
  pc-bios/s390-ccw: Move SCSI block factor to outer read
  pc-bios/s390-ccw: Break up virtio-scsi read into multiples
  pc-bios/s390-ccw.img: rebuild image

 hw/scsi/virtio-scsi.c          |  12 ++++++++++++
 pc-bios/s390-ccw.img           | Bin 26456 -> 26456 bytes
 pc-bios/s390-ccw/s390-ccw.h    |   4 ++++
 pc-bios/s390-ccw/virtio-scsi.c |  29 ++++++++++++++++++++---------
 4 files changed, 36 insertions(+), 9 deletions(-)


reply via email to

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