From patchwork Tue Jul 9 20:38:02 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dmitry Fomichev X-Patchwork-Id: 11037489 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 7631113A4 for ; Tue, 9 Jul 2019 20:40:59 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5C703212D9 for ; Tue, 9 Jul 2019 20:40:59 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 4CF4E2839C; Tue, 9 Jul 2019 20:40:59 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.0 required=2.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id C2120212D9 for ; Tue, 9 Jul 2019 20:40:58 +0000 (UTC) Received: from localhost ([::1]:55980 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hkwv1-0007Pb-J0 for patchwork-qemu-devel@patchwork.kernel.org; Tue, 09 Jul 2019 16:40:57 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60259) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hkwsx-0005oU-AG for qemu-devel@nongnu.org; Tue, 09 Jul 2019 16:38:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hkwsv-0000r0-5M for qemu-devel@nongnu.org; Tue, 09 Jul 2019 16:38:47 -0400 Received: from esa2.hgst.iphmx.com ([68.232.143.124]:50348) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hkwso-0000VW-J6; Tue, 09 Jul 2019 16:38:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=wdc.com; i=@wdc.com; q=dns/txt; s=dkim.wdc.com; t=1562704725; x=1594240725; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=2cHvew4j0kTTwMBw/J8yB3CzzPWRi34LzSyhNAsUwLc=; b=rhhp2k+gQjptpeUIG8pcA9xs2Y1NSydSdkctUdnK0+uokfbnz0VsqxFx kchZLC2w9wXUado8U0o0fsNBe/44h0OnsQ+E3wx7QiMw3rQ0mHzhspZI+ wTDOKwiEhUkiZNEAPaGM+3FQEUrRMu+xijQVNozKdVP/MAazfM/74NMhp YEkFjYF1shSYTfkn6UVGiH2Xt8hvHAIpnO4uRs2hHnBKjHUda2YNM5bt8 3jpzVM4P66nhyPBPpc7XdXOrYTukP6CYH8KSRaWW21fCJxDKLuUf7bXMR c/kDfBmckEPQI2wY2tL1e+hlVaEnJXt+z2e7mW69XnE2k2lR6HS1VGBv9 g==; IronPort-SDR: 2YMZgvMMb5udoI5R6t7TA4KR9jWwmNi12tn+RFTujp5hffhUKhNx3DRiDZtVh6Vp3FHhJUfHJX CZYRRVlyvNNmGJ2mm35icKhe9E+6mac4RMzGWUaqR4p31Um12t9Bd9qPHMuG01zmMOtYTNxqZh sepz6CFq+RXvJpleRapDFizY3fFN3ySkGp7xufazXyrPIUCjcIEGUyQqmjwpXVqyZFOmy0hI1+ eewJ1aRgH47Y0m6sLf9DkVey4oN8kp9PwEpIpBWblmjlcdl3mdjFnVLLNVdkksqj9qMzTcnnO0 JXo= X-IronPort-AV: E=Sophos;i="5.63,471,1557158400"; d="scan'208";a="212488447" Received: from uls-op-cesaip02.wdc.com (HELO uls-op-cesaep02.wdc.com) ([199.255.45.15]) by ob1.hgst.iphmx.com with ESMTP; 10 Jul 2019 04:38:42 +0800 IronPort-SDR: A3BTeqfWSRPy8QwXJiIUM/9cMLxbs97INgRS12iimzJfBdP78qDV0ZEZpYNfQsGnZNxh+EBhks qO5syFIC2Alm29rPhcGh4/VPI3Ju2si1gKidePFQITa+8wgPK63JmNWKotIewWG2wFL2iJZhnQ BNMotDE+kM0KqA0NiJ95/reXcukgP2XYOk5tZ8HorDjy0VzFiZ/RpArL003NIgVT6Zx2I5tmeX tEmhn5DAHe8yrxyq6TKC5KptRRMNdK1BV3dcxh9imM621bjqP4ABNbzqLY/p+vlFXPX0a+e4EL C13Ns3/T95/IgUyL64NYJcMJ Received: from uls-op-cesaip02.wdc.com ([10.248.3.37]) by uls-op-cesaep02.wdc.com with ESMTP; 09 Jul 2019 13:37:23 -0700 IronPort-SDR: g3ggYWh8rJQfMZy0OO4SmoUgp9Nri9MjZy51HUHDvUTmq/YE2Oooms5LScSCZtEHgPzgABY3Dt i/cguienSgIFQl5bLspVPFG5uyw7hX35RnJ/MJQgu7HQaHcYs4bue2ClAo8V/YWgJiVkEDYj/D DOx0qebhP9eHPbMSgPD9pNZid8+kjVtiWgdWmrKzCwlzqc8OXl/lMfxawsx8lpK8kQWV7ernSF t1LHkplDtqs+6QVflSTDfiyEG76jo6RjZByIu05Fwb4/5v6/7tXyl+BkjO1e59XZ2r/QvEOdQp Bh8= Received: from dhcp-10-88-173-43.hgst.com ([10.88.173.43]) by uls-op-cesaip02.wdc.com with ESMTP; 09 Jul 2019 13:38:36 -0700 From: Dmitry Fomichev To: kwolf@redhat.com, mreitz@redhat.com, mst@redhat.com, stefanha@redhat.com, pbonzini@redhat.com, fam@euphon.net, qemu-block@nongnu.org, qemu-devel@nongnu.org Date: Tue, 9 Jul 2019 16:38:02 -0400 Message-Id: <20190709203806.17550-1-dmitry.fomichev@wdc.com> X-Mailer: git-send-email 2.21.0 MIME-Version: 1.0 X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x X-Received-From: 68.232.143.124 Subject: [Qemu-devel] [PATCH 0/4] virtio: handle zoned backing devices 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: Dmitry Fomichev Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Virus-Scanned: ClamAV using ClamSMTP Currently, attaching zoned block devices (i.e. storage devices compliant to ZAC/ZBC standards) using several virtio methods doesn't work - the zoned devices appear as regular block devices at the guest. This may cause unexpected i/o errors and, potentially, some data corruption. To be more precise, attaching a zoned device via virtio-pci-blk, virtio-scsi-pci/scsi-disk or virtio-scsi-pci/scsi-hd demonstrates the above behavior. A simple fix is needed to make virtio-scsi-pci/scsi-block work and this is covered by a different patch. The virtio-scsi-pci/scsi-generic method appears to handle zoned devices without problems. This patchset adds code to check if the backing device that is being opened is zoned. If this is the case, the new code prohibits virtualization of the device for all use cases lacking proper zoned support. Considering that there is still a couple of different working ways to virtualize a ZBD, this patchset provides a reasonable short-term solution for this problem. What about long term? It appears to be beneficial to add proper ZBD support to virtio-blk. In order to support this use case properly, some virtio-blk protocol changes will be necessary. They are needed to allow the host code to propagate some ZBD properties that are required for virtio guest driver to configure the guest block device as ZBD, such as zoned device model, zone size and the total number of zones. Further, some support needs to be added for REPORT ZONES command as well as for zone operations, such as OPEN ZONE, CLOSE ZONE, FINISH ZONE and RESET ZONE. These additions to the protocol are relatively straightforward, but they need to be approved by the virtio TC and the whole process may take some time. ZBD support for virtio-scsi-pci/scsi-disk and virtio-scsi-pci/scsi-hd does not seem as necessary. Users will be expected to attach zoned block devices via virtio-scsi-pci/scsi-block instead. This patchset contains some Linux-specific code. This code is necessary to obtain Zoned Block Device model value from Linux sysfs. Dmitry Fomichev (3): block: Add zoned device model property raw: Recognize zoned backing devices virtio-blk: Don't realize zoned block devices Shin'ichiro Kawasaki (1): hw/scsi: Don't realize zoned block devices for virtio-scsi legacy drivers block.c | 14 +++++++ block/block-backend.c | 20 ++++++++++ block/file-posix.c | 69 ++++++++++++++++++++++++++++------ block/raw-format.c | 8 ++++ hw/block/virtio-blk.c | 5 +++ hw/scsi/scsi-disk.c | 5 +++ include/block/block.h | 9 +++++ include/block/block_int.h | 4 ++ include/sysemu/block-backend.h | 2 + 9 files changed, 125 insertions(+), 11 deletions(-)