[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: |
Fam Zheng |
Subject: |
Re: [Qemu-devel] [RFC PATCH v1 0/5] Enable virtio-scsi boot from /dev/sgX |
Date: |
Fri, 5 May 2017 15:41:43 +0800 |
User-agent: |
Mutt/1.8.0 (2017-02-23) |
On Wed, 04/26 16:46, Eric Farman wrote:
> 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
Can you instead do an INQUIRY from the bios code to check the Block Limits page?
The response is intercepted by hw/scsi/scsi-generic.c to merge in the host LUN's
limits. That's how Linux kernel finds the granularity for request splitting.
That way, patch 1 is not necessary too. I don't like it because it doesn't
always work considering LUN hotplug.
Fam
- Re: [Qemu-devel] [RFC PATCH v1 0/5] Enable virtio-scsi boot from /dev/sgX,
Fam Zheng <=