From patchwork Wed Nov 4 17:32:12 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Maxim Levitsky X-Patchwork-Id: 11881745 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id D589F14B4 for ; Wed, 4 Nov 2020 17:33:50 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7257E20759 for ; Wed, 4 Nov 2020 17:33:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="GfxV92J3" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7257E20759 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Received: from localhost ([::1]:46022 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kaMfN-00048q-CU for patchwork-qemu-devel@patchwork.kernel.org; Wed, 04 Nov 2020 12:33:49 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:34372) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kaMe8-0002j5-MK for qemu-devel@nongnu.org; Wed, 04 Nov 2020 12:32:33 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:46352) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1kaMe6-0000dJ-TS for qemu-devel@nongnu.org; Wed, 04 Nov 2020 12:32:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1604511149; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=5wplJQtQuROzoJYf8SyroEJMxVi0a0rlXKO+mYg59tY=; b=GfxV92J3uMA9w/wD3u6WNmv+hXfNFiuR4H6PfytfdsHT3fELXM5aXDsXq1xpxXmRsf66Yb G7anxpWpWTbDI9I3PhfBfjCnFNHdGelqQDqTnRsBuOp1tf7SGwQbD+2EVR8Pu+r6cgAoC9 XGLDSDjFNJ7sl3pPD9hXzJTp5QtuSiA= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-47-Yy1Nh5syMSeIahwutMizIA-1; Wed, 04 Nov 2020 12:32:28 -0500 X-MC-Unique: Yy1Nh5syMSeIahwutMizIA-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 87A8D1084C9A; Wed, 4 Nov 2020 17:32:26 +0000 (UTC) Received: from localhost.localdomain (unknown [10.35.207.23]) by smtp.corp.redhat.com (Postfix) with ESMTP id A1C7E75129; Wed, 4 Nov 2020 17:32:19 +0000 (UTC) From: Maxim Levitsky To: qemu-devel@nongnu.org Subject: [PATCH 0/5] SCSI: fix transfer limits for SCSI passthrough Date: Wed, 4 Nov 2020 19:32:12 +0200 Message-Id: <20201104173217.417538-1-mlevitsk@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=mlevitsk@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Received-SPF: pass client-ip=216.205.24.124; envelope-from=mlevitsk@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/03 00:03:41 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Fam Zheng , Kevin Wolf , Stefan Hajnoczi , qemu-block@nongnu.org, Peter Lieven , Tom Yan , Ronnie Sahlberg , Paolo Bonzini , Maxim Levitsky , Max Reitz Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" 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. 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 | 79 +++++++++++++++++++++++++++------- block/io.c | 2 + block/iscsi.c | 1 + hw/scsi/scsi-generic.c | 32 ++++++++------ include/block/block_int.h | 4 ++ include/sysemu/block-backend.h | 1 + 7 files changed, 103 insertions(+), 28 deletions(-)