From: Maxim Levitsky <mlevitsk@redhat.com>
To: qemu-devel@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>, Fam Zheng <fam@euphon.net>,
Ronnie Sahlberg <ronniesahlberg@gmail.com>,
qemu-block@nongnu.org, Peter Lieven <pl@kamp.de>,
Tom Yan <tom.ty89@gmail.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Maxim Levitsky <mlevitsk@redhat.com>,
Max Reitz <mreitz@redhat.com>
Subject: [PATCH v3 0/5] SCSI: fix transfer limits for SCSI passthrough
Date: Thu, 17 Dec 2020 18:56:07 +0200 [thread overview]
Message-ID: <20201217165612.942849-1-mlevitsk@redhat.com> (raw)
This patch series attempts to provide a solution to the problem of the transfer
limits of the raw file driver (host_device/file-posix), some of which I
already tried to fix in the past.
I included 2 patches from Tom Yan which fix two issues with reading the limits
correctly from the */dev/sg* character devices in the first place.
The only change to these patches is that I tweaked a bit the comments in the
source to better document the /dev/sg quirks.
The other two patches in this series split the max transfer limits that qemu
block devices expose in two:
One limit is for the regular IO, and another is for the SG_IO (aka bdrv_*_ioctl),
and the two device drivers (scsi-block and scsi-generic) that use the later
are switched to the new interface.
This should ensure that the raw driver can still advertise the unlimited
transfer length, unless it is used for SG_IO, because that yields the highest
performance.
Also I include a somewhat unrelated fix to a bug I found in qemu's
SCSI passthrough while testing this:
When qemu emulates the VPD block limit page, for a SCSI device that doesn't
implement it, it doesn't really advertise the emulated page to the guest.
I tested this by doing both regular and SG_IO passthrough of my
USB SD card reader.
That device turned out to be a perfect device for the task, since it has max
transfer size of 1024 blocks (512K), and it enforces it.
Also it didn't implement the VPD block limits page,
(transfer size limit probably comes from something USB related) which triggered
the unrelated bug.
I was able to see IO errors without the patches, and the wrong max transfer
size in the guest, and with patches both issues were gone.
I also found an unrelated issue in /dev/sg passthrough in the kernel.
It turns out that in-kernel driver has a limitation of 16 requests in flight,
regardless of what underlying device supports.
With a large multi-threaded fio job and a debug print in qemu, it is easy to
see it, although the errors don't do much harm to the guest as it retries the
IO, and eventually succeed.
It is an open question if this should be solved.
V2: fixed an issue in a patch from Tom Yan (thanks), and removed
refactoring from last patch according to Paulo's request.
V3: few cosmitic changes due to the review feedback.
Maxim Levitsky (3):
block: add max_ioctl_transfer to BlockLimits
block: use blk_get_max_ioctl_transfer for SCSI passthrough
block/scsi: correctly emulate the VPD block limits page
Tom Yan (2):
file-posix: split hdev_refresh_limits from raw_refresh_limits
file-posix: add sg_get_max_segments that actually works with sg
block/block-backend.c | 12 ++++++
block/file-posix.c | 76 +++++++++++++++++++++++++++-------
block/io.c | 2 +
block/iscsi.c | 1 +
hw/scsi/scsi-generic.c | 13 ++++--
include/block/block_int.h | 4 ++
include/sysemu/block-backend.h | 1 +
7 files changed, 90 insertions(+), 19 deletions(-)
--
2.26.2
next reply other threads:[~2020-12-17 17:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-17 16:56 Maxim Levitsky [this message]
2020-12-17 16:56 ` [PATCH v3 1/5] file-posix: split hdev_refresh_limits from raw_refresh_limits Maxim Levitsky
2021-01-07 12:24 ` Max Reitz
2020-12-17 16:56 ` [PATCH v3 2/5] file-posix: add sg_get_max_segments that actually works with sg Maxim Levitsky
2021-01-07 12:42 ` Max Reitz
2020-12-17 16:56 ` [PATCH v3 3/5] block: add max_ioctl_transfer to BlockLimits Maxim Levitsky
2021-01-07 13:09 ` Max Reitz
2020-12-17 16:56 ` [PATCH v3 4/5] block: use blk_get_max_ioctl_transfer for SCSI passthrough Maxim Levitsky
2021-01-07 13:19 ` Max Reitz
2020-12-17 16:56 ` [PATCH v3 5/5] block/scsi: correctly emulate the VPD block limits page Maxim Levitsky
2021-01-07 13:44 ` Max Reitz
2021-01-07 10:23 ` [PATCH v3 0/5] SCSI: fix transfer limits for SCSI passthrough Maxim Levitsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201217165612.942849-1-mlevitsk@redhat.com \
--to=mlevitsk@redhat.com \
--cc=fam@euphon.net \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=pbonzini@redhat.com \
--cc=pl@kamp.de \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=ronniesahlberg@gmail.com \
--cc=stefanha@redhat.com \
--cc=tom.ty89@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).