[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH v2 0/8] s390x: Enable virtio-scsi boot from
From: |
Cornelia Huck |
Subject: |
Re: [Qemu-devel] [RFC PATCH v2 0/8] s390x: Enable virtio-scsi boot from /dev/sgX |
Date: |
Wed, 17 May 2017 13:48:41 +0200 |
On Tue, 16 May 2017 15:44:43 +0200
Christian Borntraeger <address@hidden> wrote:
> On 05/10/2017 05:53 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 block 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 1-3 read the max_sectors parameter for the virtio-scsi controller,
> > and break up the READ(10) I/Os into something that the host will accept.
> > If not specified, max_sectors defaults to 65535, but could look like this:
> >
> > qemu-system-s390x ...
> > -device virtio-scsi-ccw,id=scsi0,devno=fe.0.0001,max_sectors=2048
> >
> > Patches 4-6 read the max_io_size parameter for the virtio-scsi disk device,
> > and use the minimum of it and the max_sectors from the controller for
> > breaking
> > up the READ(10) I/Os. If not specified, max_io_size defaults to 2147483647
> > but could look like this:
> >
> > qemu-system-s390x ...
> > -drive file=/dev/sda,if=none,id=drive0,format=raw ...
> > -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,
> > drive=drive0,id=disk0,max_io_size=1048576
> >
> > In the two examples above, the maximum parameters are equivalent due to the
> > controller parameter measuring 512-byte blocks, and the disk measuring
> > bytes.
> >
> > Patch 7 establishes a workable default, in case neither the controller nor
> > the disk have the parameters specified (and thus the overly large defaults
> > are taken), or if they are set to something beyond what we can boot from.
> >
> > Patch 8 rebuilds the s390-ccw BIOS with this entire patch set.
> >
> > Changelog:
> >
> > RFC v2:
> > - Dropped patch outside the pc-bios/s390-ccw/ tree
> > - Added Christian's r-b to patch 1 (formerly patch 2)
> > - Added EVPD Inquiry calls to retrieve Block Limits page if supported
> > - Added a default if Block Limits page is not supported, or response is
> > still way to big to allow boot
> > RFC v1:
> > - https://lists.nongnu.org/archive/html/qemu-devel/2017-04/msg05121.html
> >
> > Eric Farman (8):
> > 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: Refactor scsi_inquiry function
> > pc-bios/s390-ccw: Get list of supported VPD pages
> > pc-bios/s390-ccw: Get Block Limits VPD device data
> > pc-bios/s390-ccw: Build a reasonable max_sectors limit
> > pc-bios/s390-ccw.img: rebuild image
> >
> > pc-bios/s390-ccw.img | Bin 26472 -> 26480 bytes
> > pc-bios/s390-ccw/s390-ccw.h | 7 ++++
> > pc-bios/s390-ccw/scsi.h | 30 +++++++++++++++
> > pc-bios/s390-ccw/virtio-scsi.c | 85
> > +++++++++++++++++++++++++++++++++++------
> > pc-bios/s390-ccw/virtio-scsi.h | 2 +
> > pc-bios/s390-ccw/virtio.h | 1 +
> > 6 files changed, 114 insertions(+), 11 deletions(-)
> >
>
> Patch set looks good. Conny, can you apply the series?
>
I had hoped for some comments from folks more familiar with scsi...
Nevertheless, applied to s390-next.
- [Qemu-devel] [RFC PATCH v2 1/8] pc-bios/s390-ccw: Remove duplicate blk_factor adjustment, (continued)
- [Qemu-devel] [RFC PATCH v2 1/8] pc-bios/s390-ccw: Remove duplicate blk_factor adjustment, Eric Farman, 2017/05/10
- [Qemu-devel] [RFC PATCH v2 2/8] pc-bios/s390-ccw: Move SCSI block factor to outer read, Eric Farman, 2017/05/10
- [Qemu-devel] [RFC PATCH v2 4/8] pc-bios/s390-ccw: Refactor scsi_inquiry function, Eric Farman, 2017/05/10
- [Qemu-devel] [RFC PATCH v2 3/8] pc-bios/s390-ccw: Break up virtio-scsi read into multiples, Eric Farman, 2017/05/10
- [Qemu-devel] [RFC PATCH v2 6/8] pc-bios/s390-ccw: Get Block Limits VPD device data, Eric Farman, 2017/05/10
- [Qemu-devel] [RFC PATCH v2 5/8] pc-bios/s390-ccw: Get list of supported VPD pages, Eric Farman, 2017/05/10
- [Qemu-devel] [RFC PATCH v2 7/8] pc-bios/s390-ccw: Build a reasonable max_sectors limit, Eric Farman, 2017/05/10
- [Qemu-devel] [RFC PATCH v2 8/8] pc-bios/s390-ccw.img: rebuild image, Eric Farman, 2017/05/10
- Re: [Qemu-devel] [RFC PATCH v2 0/8] s390x: Enable virtio-scsi boot from /dev/sgX, Cornelia Huck, 2017/05/11
- Re: [Qemu-devel] [RFC PATCH v2 0/8] s390x: Enable virtio-scsi boot from /dev/sgX, Christian Borntraeger, 2017/05/16
- Re: [Qemu-devel] [RFC PATCH v2 0/8] s390x: Enable virtio-scsi boot from /dev/sgX,
Cornelia Huck <=