From nobody Sat May 4 18:41:39 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; dkim=fail; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=gmail.com Return-Path: Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1528489044128322.66969050272644; Fri, 8 Jun 2018 13:17:24 -0700 (PDT) Received: from localhost ([::1]:38037 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fRNp3-0007pn-Uq for importer@patchew.org; Fri, 08 Jun 2018 16:17:23 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48233) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fRNfx-0008WQ-BC for qemu-devel@nongnu.org; Fri, 08 Jun 2018 16:07:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fRNfv-0007Ln-GZ for qemu-devel@nongnu.org; Fri, 08 Jun 2018 16:07:57 -0400 Received: from mail-qk0-x242.google.com ([2607:f8b0:400d:c09::242]:46098) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fRNfv-0007LY-Aa for qemu-devel@nongnu.org; Fri, 08 Jun 2018 16:07:55 -0400 Received: by mail-qk0-x242.google.com with SMTP id k86-v6so9507439qkh.13 for ; Fri, 08 Jun 2018 13:07:55 -0700 (PDT) Received: from localhost.localdomain ([2804:431:f700:ddd3:8b53:ca1c:8f9e:6815]) by smtp.gmail.com with ESMTPSA id 73-v6sm39213849qkc.96.2018.06.08.13.07.53 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 08 Jun 2018 13:07:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=myhiYCCJIu45/7ZSddyyv7Ni/D4T2YLrK2D36b42Qp8=; b=TUMwkMBfm/DrKFksidXUJma11vzlXv1w+GGqOLBiIMROBfcyFOaVoiYf4tNzXpTlck GTAv3TFZleFqslERC9QXzWRXNBCwOtPPbXUYG0V5sCrR1hOM1RIptlRiH3F00/yBKR80 lf91KOvEglzYByrFFhcF5hZEAT8fmEEbrbJhur7CIinf7IfHRWtXgYEs7wTHNs7aMYuC iNePjUKPIp/wJaFZaiX0BAXEYhIbYpDDlUruWQ/wZ2cZ2JdAbtkt1QfjXx8jTJ9fxw0h GnpNbflsXaYmIgD25VeICkhdJkMM6OpyWMqXqAxg0xmCXKIFshYO+k6MDMI8s2toh80L Yg5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=myhiYCCJIu45/7ZSddyyv7Ni/D4T2YLrK2D36b42Qp8=; b=ohSoJZk0i9Uvhu9NtB2MkAtR5TzeI/gYf+zDERHLykjwVdJKrR9x2BJCvCojhhSIJq VIUAYk7vkOUClJoISuA6aRNm0R/X/UdbxwdLrjElbOtqgCYgVFMEoVe/GaznNgvknpbJ nMmMedMJXmhCn1gY+5lxdOQ3QsW5/x3S23vbDbIyUGm2h60kHrp0FcmsknPV5OgHr3qc ostqiAxoWpAVjpL0SIByNBg+fTc3NG0OcD4tLmnpXF/o58WqmjimmQiD3Y9QsqKHc46L 9ikUGBXz7kDSyVECBdV1Y6yqsRmBcXsi26pL1mtu2ALqd/EMPJG1lJ8ymsvETb4Xmbu5 nPUw== X-Gm-Message-State: APt69E1eZQXRsDbTRQxg3iF6ZwOo+YfNxwA9CAtf4wzLEsFpZtrRrQEC ok+qQ6fCulhBIIUCBZom0kWiX1K7MdGQPw== X-Google-Smtp-Source: ADUXVKJxn8tCfL1rZpO2UEwsgjMSdesXVHcIrLEAwj6zHx9aX7CdjVXRDpA+Wzl+ycy3qhmMht5nGA== X-Received: by 2002:a37:a94a:: with SMTP id s71-v6mr6457468qke.221.1528488474613; Fri, 08 Jun 2018 13:07:54 -0700 (PDT) From: Daniel Henrique Barboza To: qemu-devel@nongnu.org Date: Fri, 8 Jun 2018 17:07:38 -0300 Message-Id: <20180608200740.24915-2-danielhb413@gmail.com> X-Mailer: git-send-email 2.14.3 In-Reply-To: <20180608200740.24915-1-danielhb413@gmail.com> References: <20180608200740.24915-1-danielhb413@gmail.com> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:400d:c09::242 Subject: [Qemu-devel] [PATCH v1 1/3] scsi-block: emulate missing Block Limits response X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: pbonzini@redhat.com, Daniel Henrique Barboza , famz@redhat.com Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail-DKIM: fail (Header signature does not verify) X-ZohoMail: RDKM_2 RSF_0 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" The VPD Block Limits Inquiry page is optional, allowing SCSI devices to not implement it. This is the case for devices like the MegaRAID SAS 9361-8i and Microsemi PM8069. In case of SCSI passthrough, the response of this request is used by the QEMU SCSI layer to set the max_io_sectors that the guest device will support, based on the value of the max_sectors_kb that the device has set in the host at that time. Without this response, the guest kernel is free to assume any value of max_io_sectors for the SCSI device. If this value is greater than the value from the host, SCSI Sense errors will occur because the guest will send read/write requests that are larger than the underlying host device is configured to support. An example of this behavior can be seen in [1]. A workaround is to set the max_sectors_kb host value back in the guest kernel (a process that can be automated using rc.local startup scripts and the like), but this has several drawbacks: - it can be troublesome if the guest has many passthrough devices that needs this tuning; - if a change in max_sectors_kb is made in the host side, manual change in the guests will also be required; - during an OS install it is difficult, and sometimes not possible, to go to a terminal and change the max_sectors_kb prior to the installation. This means that the disk can't be used during the install process. The easiest alternative here is to roll back to scsi-hd, install the guest and then go back to SCSI passthrough when the installation is done and max_sectors_kb can be set. An easier way would be to QEMU handle the absence of the VPD Block Limits device response, setting max_io_sectors accordingly and allowing the guest to use the device without the hassle. This patch is the first step to tackle this. Inside scsi_read_complete, snoop into the io_header and see if there is a SENSE error from a VPD Block Limits request. If that's the case, return an emulated response based on what we already do in scsi-disk. Clean up the io_header fields what would trigger a SCSI sense error later on now that we have a valid response to give. Note that this patch alone does not fix [1] - the guest is still unaware of the VPD Block Limits page support if the hardware does not implement it. This will be taken care of in the next patch. For now, we can see the emulated Block Limits response by using sg3_utils: [root@boston-ess054p2 ~]# sg_vpd --page=3Dbl /dev/sdb --verbose inquiry cdb: 12 01 b0 00 fc 00 Block limits VPD page (SBC): [PQual=3D0 Peripheral device type: disk] Write same no zero (WSNZ): 1 Maximum compare and write length: 0 blocks Optimal transfer length granularity: 0 blocks Maximum transfer length: 512 blocks Optimal transfer length: 0 blocks Maximum prefetch length: 0 blocks Maximum unmap LBA count: 2097152 Maximum unmap block descriptor count: 255 Optimal unmap granularity: 0 Unmap granularity alignment valid: 0 Unmap granularity alignment: 0 Maximum write same length: 0x200 blocks [root@boston-ess054p2 ~]# [1] https://bugzilla.redhat.com/show_bug.cgi?id=3D1566195 Reported-by: Dac Nguyen Signed-off-by: Daniel Henrique Barboza --- hw/scsi/scsi-disk.c | 2 - hw/scsi/scsi-generic.c | 133 +++++++++++++++++++++++++++++++++++++++++++++= +--- include/hw/scsi/scsi.h | 3 ++ 3 files changed, 128 insertions(+), 10 deletions(-) diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c index ded23d36ca..4461a592e5 100644 --- a/hw/scsi/scsi-disk.c +++ b/hw/scsi/scsi-disk.c @@ -50,8 +50,6 @@ do { printf("scsi-disk: " fmt , ## __VA_ARGS__); } while = (0) #define SCSI_MAX_MODE_LEN 256 =20 #define DEFAULT_DISCARD_GRANULARITY 4096 -#define DEFAULT_MAX_UNMAP_SIZE (1 << 30) /* 1 GB */ -#define DEFAULT_MAX_IO_SIZE INT_MAX /* 2 GB - 1 block */ =20 #define TYPE_SCSI_DISK_BASE "scsi-disk-base" =20 diff --git a/hw/scsi/scsi-generic.c b/hw/scsi/scsi-generic.c index 03bce8ff39..579872908c 100644 --- a/hw/scsi/scsi-generic.c +++ b/hw/scsi/scsi-generic.c @@ -76,6 +76,103 @@ static void scsi_free_request(SCSIRequest *req) g_free(r->buf); } =20 +/* + * Takes a buffer and fill it with contents of a SCSI Inquiry VPD + * Block Limits response, based on the attributes of the SCSIDevice + * and other default values, returning the size written in the + * buffer. + * + * This function is a modified version of 'scsi_disk_emulate_inquiry' + * from scsi-disk.c. + */ +static int scsi_emulate_vpd_bl_page(SCSIDevice *s, uint8_t *outbuf) +{ + int buflen =3D 0; + int start; + + outbuf[buflen++] =3D TYPE_DISK & 0x1f; + outbuf[buflen++] =3D 0xb0; + outbuf[buflen++] =3D 0x00; + outbuf[buflen++] =3D 0x00; + start =3D buflen; + + unsigned int unmap_sectors =3D s->conf.discard_granularity / s->blocks= ize; + unsigned int min_io_size =3D s->conf.min_io_size / s->blocksize; + unsigned int opt_io_size =3D s->conf.opt_io_size / s->blocksize; + unsigned int max_unmap_sectors =3D DEFAULT_MAX_UNMAP_SIZE / s->blocksi= ze; + unsigned int max_io_sectors =3D DEFAULT_MAX_IO_SIZE / s->blocksize; + + int max_transfer_blk =3D blk_get_max_transfer(s->conf.blk); + int max_io_sectors_blk =3D max_transfer_blk / s->blocksize; + + max_io_sectors =3D MIN_NON_ZERO(max_io_sectors_blk, max_io_sectors); + + /* min_io_size and opt_io_size can't be greater than max_io_sectors */ + if (min_io_size) { + min_io_size =3D MIN(min_io_size, max_io_sectors); + } + if (opt_io_size) { + opt_io_size =3D MIN(opt_io_size, max_io_sectors); + } + + /* required VPD size with unmap support */ + buflen =3D 0x40; + memset(outbuf + 4, 0, buflen - 4); + + outbuf[4] =3D 0x1; /* wsnz */ + + /* optimal transfer length granularity */ + outbuf[6] =3D (min_io_size >> 8) & 0xff; + outbuf[7] =3D min_io_size & 0xff; + + /* maximum transfer length */ + outbuf[8] =3D (max_io_sectors >> 24) & 0xff; + outbuf[9] =3D (max_io_sectors >> 16) & 0xff; + outbuf[10] =3D (max_io_sectors >> 8) & 0xff; + outbuf[11] =3D max_io_sectors & 0xff; + + /* optimal transfer length */ + outbuf[12] =3D (opt_io_size >> 24) & 0xff; + outbuf[13] =3D (opt_io_size >> 16) & 0xff; + outbuf[14] =3D (opt_io_size >> 8) & 0xff; + outbuf[15] =3D opt_io_size & 0xff; + + /* max unmap LBA count, default is 1GB */ + outbuf[20] =3D (max_unmap_sectors >> 24) & 0xff; + outbuf[21] =3D (max_unmap_sectors >> 16) & 0xff; + outbuf[22] =3D (max_unmap_sectors >> 8) & 0xff; + outbuf[23] =3D max_unmap_sectors & 0xff; + + /* max unmap descriptors, 255 fit in 4 kb with an 8-byte header. */ + outbuf[24] =3D 0; + outbuf[25] =3D 0; + outbuf[26] =3D 0; + outbuf[27] =3D 255; + + /* optimal unmap granularity */ + outbuf[28] =3D (unmap_sectors >> 24) & 0xff; + outbuf[29] =3D (unmap_sectors >> 16) & 0xff; + outbuf[30] =3D (unmap_sectors >> 8) & 0xff; + outbuf[31] =3D unmap_sectors & 0xff; + + /* max write same size */ + outbuf[36] =3D 0; + outbuf[37] =3D 0; + outbuf[38] =3D 0; + outbuf[39] =3D 0; + + outbuf[40] =3D (max_io_sectors >> 24) & 0xff; + outbuf[41] =3D (max_io_sectors >> 16) & 0xff; + outbuf[42] =3D (max_io_sectors >> 8) & 0xff; + outbuf[43] =3D max_io_sectors & 0xff; + + /* done with EVPD */ + assert(buflen - start <=3D 255); + outbuf[start - 1] =3D buflen - start; + + return buflen; +} + /* Helper function for command completion. */ static void scsi_command_complete_noio(SCSIGenericReq *r, int ret) { @@ -146,6 +243,7 @@ static void scsi_read_complete(void * opaque, int ret) { SCSIGenericReq *r =3D (SCSIGenericReq *)opaque; SCSIDevice *s =3D r->req.dev; + SCSISense sense; int len; =20 assert(r->req.aiocb !=3D NULL); @@ -218,14 +316,33 @@ static void scsi_read_complete(void * opaque, int ret) } } if (s->type =3D=3D TYPE_DISK && r->req.cmd.buf[2] =3D=3D 0xb0) { - uint32_t max_transfer =3D - blk_get_max_transfer(s->conf.blk) / s->blocksize; - - assert(max_transfer); - stl_be_p(&r->buf[8], max_transfer); - /* Also take care of the opt xfer len. */ - stl_be_p(&r->buf[12], - MIN_NON_ZERO(max_transfer, ldl_be_p(&r->buf[12]))); + /* + * Take a look to see if this VPD Block Limits request will + * result in a sense error in scsi_command_complete_noio. + * In this case, emulate a valid VPD response. + * + * After that, given that now there are valid contents in the + * buffer, clean up the io_header to avoid firing up the + * sense error. + */ + if (sg_io_sense_from_errno(-ret, &r->io_header, &sense)) { + r->buflen =3D scsi_emulate_vpd_bl_page(s, r->buf); + r->io_header.sb_len_wr =3D 0; + + /* Clean sg_io_sense */ + r->io_header.driver_status =3D 0; + r->io_header.status =3D 0; + + } else { + uint32_t max_transfer =3D + blk_get_max_transfer(s->conf.blk) / s->blocksize; + + assert(max_transfer); + stl_be_p(&r->buf[8], max_transfer); + /* Also take care of the opt xfer len. */ + stl_be_p(&r->buf[12], + MIN_NON_ZERO(max_transfer, ldl_be_p(&r->buf[12]))= ); + } } } scsi_req_data(&r->req, len); diff --git a/include/hw/scsi/scsi.h b/include/hw/scsi/scsi.h index e35137ea78..4fdde102b8 100644 --- a/include/hw/scsi/scsi.h +++ b/include/hw/scsi/scsi.h @@ -18,6 +18,9 @@ typedef struct SCSIReqOps SCSIReqOps; #define SCSI_SENSE_BUF_SIZE_OLD 96 #define SCSI_SENSE_BUF_SIZE 252 =20 +#define DEFAULT_MAX_UNMAP_SIZE (1 << 30) /* 1 GB */ +#define DEFAULT_MAX_IO_SIZE INT_MAX /* 2 GB - 1 block */ + struct SCSIRequest { SCSIBus *bus; SCSIDevice *dev; --=20 2.14.3 From nobody Sat May 4 18:41:39 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; dkim=fail; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=gmail.com Return-Path: Received: from lists.gnu.org (208.118.235.17 [208.118.235.17]) by mx.zohomail.com with SMTPS id 1528489191908820.2413591713723; Fri, 8 Jun 2018 13:19:51 -0700 (PDT) Received: from localhost ([::1]:38046 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fRNrL-0000zZ-90 for importer@patchew.org; Fri, 08 Jun 2018 16:19:43 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48239) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fRNfy-00005V-2K for qemu-devel@nongnu.org; Fri, 08 Jun 2018 16:07:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fRNfw-0007MU-Rl for qemu-devel@nongnu.org; Fri, 08 Jun 2018 16:07:58 -0400 Received: from mail-qk0-x22e.google.com ([2607:f8b0:400d:c09::22e]:35098) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fRNfw-0007MJ-ME for qemu-devel@nongnu.org; Fri, 08 Jun 2018 16:07:56 -0400 Received: by mail-qk0-x22e.google.com with SMTP id d130-v6so9525521qkc.2 for ; Fri, 08 Jun 2018 13:07:56 -0700 (PDT) Received: from localhost.localdomain ([2804:431:f700:ddd3:8b53:ca1c:8f9e:6815]) by smtp.gmail.com with ESMTPSA id 73-v6sm39213849qkc.96.2018.06.08.13.07.54 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 08 Jun 2018 13:07:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=s7wVc/vwFQaFUALqJoxlm82r8dVpBRxumNF5o4BWyO8=; b=Ol7rwmzrrVWAGDzha49cSvHduwZLKY+qsYHhy4tBEQiPBf4M7OgnNirop/Q3H3xomG v8bKbf/8wA0/GNXxZqX/bYbHYQ49TKNPxxKjoPXakkpVOQFhUmNhp5BgwPZPYQ27WoLK HscPEsVYoW+7LKi9Fq3uAbTQ4d+OHaHJFileNpD9Z/Aj5gSjeL+Y1bLv8OglIKFnAaFu PpYzkqWJzOQRWA7FMF/aNZKLXvZqp+sHXRYnxMxboHpEbgQ8On0RJQvz+Zo5En32ntU4 BO59WuLAf+ZeCevvVfSrVC31U1WijOmDKpCUfNyF/7reb8lljhnFZTMac6ePvnd+yOV0 tlow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=s7wVc/vwFQaFUALqJoxlm82r8dVpBRxumNF5o4BWyO8=; b=tL6hOpP67xDCklG0pfv2QTYxMCT83emn9HjJUe/FFFPR52n4nDh4DVyTNJwO5ac87T exfIhqEPYlMq+PYjXDa4kLpCprM4eQxo6IG/Ke4pEq/iAkrxwF/8E3z6AHqbHKNJGUpR VI4ZvgQuOzEjsFc04KX9DcWL/bbou/Ti5EivFZAQdQH8tfFKzs6t2ybR6kyeMgFEq+ML mPvlcLGVuS6HAbvPv9a48RSMMK/bwW58s41iZYWKiHPwoson4wnIAXs5D2jl3oJjkD1m flDxoA2rOBJ8ObYenJ2PEXdPcrkNpSrXuZrVRALjQHNPvj7d+SYTadx0SHA97QkCjFPJ DwDQ== X-Gm-Message-State: APt69E2S7tL/b7DJPvGoslMcvcJCrWqCFm9hVQtU8Vd7FKhQ7c3V8JFc q4drDTre4yEUDitmdc5mU4tpml7rvJ2S0w== X-Google-Smtp-Source: ADUXVKKkiEaM238zo+aldoDN0BiD0I1DnyNMg+KAqT85YveHogXDS9OWn9jYRY97Q+ITG2LTD/CkQw== X-Received: by 2002:a37:6410:: with SMTP id y16-v6mr6788113qkb.56.1528488476096; Fri, 08 Jun 2018 13:07:56 -0700 (PDT) From: Daniel Henrique Barboza To: qemu-devel@nongnu.org Date: Fri, 8 Jun 2018 17:07:39 -0300 Message-Id: <20180608200740.24915-3-danielhb413@gmail.com> X-Mailer: git-send-email 2.14.3 In-Reply-To: <20180608200740.24915-1-danielhb413@gmail.com> References: <20180608200740.24915-1-danielhb413@gmail.com> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:400d:c09::22e Subject: [Qemu-devel] [PATCH v1 2/3] scsi-block: add VPD Block Limits in INQUIRY Supported Pages reply X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: pbonzini@redhat.com, Daniel Henrique Barboza , famz@redhat.com Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail-DKIM: fail (Header signature does not verify) X-ZohoMail: RDKM_2 RSF_0 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" The previous commit added Block Limits emulation for scsi-block devices if the underlying hardware does not implement it. But this is not enough to fix the issue of max_io_sectors mismatch between the guest and the host - the guest is not aware of the Block Limits support we're now providing. This patch changes the INQUIRY Supported Pages reply to add Block Limits support. If the host device already supports it, nothing changes. If it doesn't, add it manually in the reply. With this patch, the guest now queries the Block Limits page during the device configuration because it is being advertised in the Supported Pages response. It will either receive the Block Limits page from the hardware, if it supports it, or will receive an emulated response from QEMU. At any rate, the guest now has the information to set the max_sectors_kb parameter accordingly, sparing the user of SCSI sense errors that would happen without the emulated response and in the absence of Block Limits support from the hardware. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=3D1566195 Reported-by: Dac Nguyen Signed-off-by: Daniel Henrique Barboza --- hw/scsi/scsi-generic.c | 80 ++++++++++++++++++++++++++++++++--------------= ---- 1 file changed, 52 insertions(+), 28 deletions(-) diff --git a/hw/scsi/scsi-generic.c b/hw/scsi/scsi-generic.c index 579872908c..64d3b79518 100644 --- a/hw/scsi/scsi-generic.c +++ b/hw/scsi/scsi-generic.c @@ -244,7 +244,8 @@ static void scsi_read_complete(void * opaque, int ret) SCSIGenericReq *r =3D (SCSIGenericReq *)opaque; SCSIDevice *s =3D r->req.dev; SCSISense sense; - int len; + uint8_t page, page_len; + int len, i; =20 assert(r->req.aiocb !=3D NULL); r->req.aiocb =3D NULL; @@ -315,33 +316,56 @@ static void scsi_read_complete(void * opaque, int ret) s->scsi_version =3D r->buf[2]; } } - if (s->type =3D=3D TYPE_DISK && r->req.cmd.buf[2] =3D=3D 0xb0) { - /* - * Take a look to see if this VPD Block Limits request will - * result in a sense error in scsi_command_complete_noio. - * In this case, emulate a valid VPD response. - * - * After that, given that now there are valid contents in the - * buffer, clean up the io_header to avoid firing up the - * sense error. - */ - if (sg_io_sense_from_errno(-ret, &r->io_header, &sense)) { - r->buflen =3D scsi_emulate_vpd_bl_page(s, r->buf); - r->io_header.sb_len_wr =3D 0; - - /* Clean sg_io_sense */ - r->io_header.driver_status =3D 0; - r->io_header.status =3D 0; - - } else { - uint32_t max_transfer =3D - blk_get_max_transfer(s->conf.blk) / s->blocksize; - - assert(max_transfer); - stl_be_p(&r->buf[8], max_transfer); - /* Also take care of the opt xfer len. */ - stl_be_p(&r->buf[12], - MIN_NON_ZERO(max_transfer, ldl_be_p(&r->buf[12]))= ); + if (s->type =3D=3D TYPE_DISK && (r->req.cmd.buf[1] & 0x01)) { + page =3D r->req.cmd.buf[2]; + if (page =3D=3D 0xb0) { + /* + * Take a look to see if this VPD Block Limits request will + * result in a sense error in scsi_command_complete_noio. + * In this case, emulate a valid VPD response. + * + * After that, given that now there are valid contents in + * the buffer, clean up the io_header to avoid firing up + * the sense error. + */ + if (sg_io_sense_from_errno(-ret, &r->io_header, &sense)) { + r->buflen =3D scsi_emulate_vpd_bl_page(s, r->buf); + r->io_header.sb_len_wr =3D 0; + + /* Clean sg_io_sense */ + r->io_header.driver_status =3D 0; + r->io_header.status =3D 0; + + } else { + uint32_t max_transfer =3D + blk_get_max_transfer(s->conf.blk) / s->blocksize; + + assert(max_transfer); + stl_be_p(&r->buf[8], max_transfer); + /* Also take care of the opt xfer len. */ + stl_be_p(&r->buf[12], + MIN_NON_ZERO(max_transfer, ldl_be_p(&r->buf[1= 2]))); + } + } else if (page =3D=3D 0x00) { + /* + * Now we're capable of supplying the VPD Block Limits + * response if the hardware can't. Inspect if the INQUIRY + * response contains support for the VPD Block Limits page. + * Add it if it doesn't. + * + * This way, the guest kernel will be aware of the support + * and will use it to proper setup the SCSI device. + */ + page_len =3D r->buf[3]; + for (i =3D 4; i < page_len + 4; i++) { + if (r->buf[i] =3D=3D 0xb0) { + break; + } + } + if (i =3D=3D page_len + 4) { + r->buf[i] =3D 0xb0; + r->buf[3] =3D ++page_len; + } } } } --=20 2.14.3 From nobody Sat May 4 18:41:39 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; dkim=fail; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=gmail.com Return-Path: Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1528489307085850.1945266716581; Fri, 8 Jun 2018 13:21:47 -0700 (PDT) Received: from localhost ([::1]:38061 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fRNtK-0002TV-9B for importer@patchew.org; Fri, 08 Jun 2018 16:21:46 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48255) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fRNfz-00007K-Pe for qemu-devel@nongnu.org; Fri, 08 Jun 2018 16:08:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fRNfy-0007NJ-Fe for qemu-devel@nongnu.org; Fri, 08 Jun 2018 16:07:59 -0400 Received: from mail-qk0-x243.google.com ([2607:f8b0:400d:c09::243]:39734) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fRNfy-0007N6-Ak for qemu-devel@nongnu.org; Fri, 08 Jun 2018 16:07:58 -0400 Received: by mail-qk0-x243.google.com with SMTP id g14-v6so9524518qkm.6 for ; Fri, 08 Jun 2018 13:07:58 -0700 (PDT) Received: from localhost.localdomain ([2804:431:f700:ddd3:8b53:ca1c:8f9e:6815]) by smtp.gmail.com with ESMTPSA id 73-v6sm39213849qkc.96.2018.06.08.13.07.56 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 08 Jun 2018 13:07:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=6hO/+ayhJyPYIwvF9bXKHL2SFR7Y7TiJ4kHiBBElEJI=; b=rccI08ABqdEaafEzc7w28IFi5u0FkFrFiQ1oLUsRnneN9EvDVCYHZOW5g/KW/7proR 35aroz8ia+nruy/rgvckp6qaIZMZH3bH8HoDwoIspdHyBnqaEJa40u2qxRvPp6ZsFlsy xnhTBgMrTLgOrUCtHWEWEw+mBtnDFWYChgXgGwB54njL8XRgWsYQKl1EUAlVa/4IPdeK sdk1ACxBLLkVit2+G50ifG/yFdL4gD15ZHdwNYbQML7kdY5RP0HrUK5zT6waI2hjJw2k Z2F02i905Dujzm58Ul4g9BcF7PCgfgcBVZzey56wIffdc+9VAq1ZZiSBft22B+HxAfeU Q3uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=6hO/+ayhJyPYIwvF9bXKHL2SFR7Y7TiJ4kHiBBElEJI=; b=uWQxSwZBEUcBsTky/ipQwoiaXMJOVQnx9c36uUANGfwnOfoeZMHFkECnqvWAqAOOZq rvNYDb5UK4bc0v6DzOcZUH8WhCL6geU9Ve1WIF1FULQJBx8xGexUPcGTXAZJ7iNfbb5c IpHyj9OXqBQFA2ALgaLG8phomTb8Xa/LMzLBnzeJPS7Qax3ul8wetT0SPmZhVA28NEPw ssMg5xEN6R+gUNCDoy533XNwtXj332FZbQ1ddfBxGPlvHaX3sZz0ixjBl7C7br2Af1+t TNKITnc/ikNku+aL/1m0+FvbeBCmWl+kj6Mu3K7neZYBYB8m3JMt70mL/w3d24B99/16 pCCg== X-Gm-Message-State: APt69E0sYZBQaf1gML/x0V4FBiwsXd/u2HJvQxRZiIzd4qoWsqISpETq CEpIq0gYPAp/n2vCH3cPXOF+bwa1jQ7y4g== X-Google-Smtp-Source: ADUXVKIDp4CrhHu7plEw7cQHvGT4sJwyolMqEPFO/ze0g5+j77YQXP+Ydm18uRHS9qh9y9Xfmu4qfg== X-Received: by 2002:a37:6147:: with SMTP id v68-v6mr6398733qkb.1.1528488477710; Fri, 08 Jun 2018 13:07:57 -0700 (PDT) From: Daniel Henrique Barboza To: qemu-devel@nongnu.org Date: Fri, 8 Jun 2018 17:07:40 -0300 Message-Id: <20180608200740.24915-4-danielhb413@gmail.com> X-Mailer: git-send-email 2.14.3 In-Reply-To: <20180608200740.24915-1-danielhb413@gmail.com> References: <20180608200740.24915-1-danielhb413@gmail.com> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:400d:c09::243 Subject: [Qemu-devel] [PATCH v1 3/3] scsi-block: adding flag at realize to enable Block Limits emulation X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: pbonzini@redhat.com, Daniel Henrique Barboza , famz@redhat.com Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail-DKIM: fail (Header signature does not verify) X-ZohoMail: RDKM_2 RSF_0 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" The previous patches implemented a way to deliver an emulated Block Limits (BL) response for the guest in case the underlying hardware does not support this page. However, the approach used is crude. We're executing the logic for all SCSI devices, regardless of whether they need it or not. There's also a possibility that we'll end up masking a legitimate SCSI error of a device that does implement the BL page (thus not needing any BL emulation). This patch refines the solution used in the previous patches by adding a new SCSIDevice attribute called 'needs_vpl_bl_emulation'. This flag is set at scsi_block_realize using a new function called 'scsi_block_set_vpd_bl_emulation'. This new function queries the Inquiry Supported Pages of the device and checks if it supports the BL message. If it doesn't, the emulation flag is set to 'true'. This flag is then used at scsi_read_complete to isolate the emulation logic from the devices that does not require it. Signed-off-by: Daniel Henrique Barboza --- hw/scsi/scsi-disk.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++= +++ hw/scsi/scsi-generic.c | 32 +++++++++++++++----------------- include/hw/scsi/scsi.h | 1 + 3 files changed, 65 insertions(+), 17 deletions(-) diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c index 4461a592e5..cb53d0fdab 100644 --- a/hw/scsi/scsi-disk.c +++ b/hw/scsi/scsi-disk.c @@ -2599,6 +2599,54 @@ static int get_device_type(SCSIDiskState *s) return 0; } =20 +static void scsi_block_set_vpd_bl_emulation(SCSIDevice *s) +{ + uint8_t cmd[6]; + uint8_t buf[250]; + uint8_t sensebuf[8]; + uint8_t page_len; + sg_io_hdr_t io_header; + int ret, i; + + memset(cmd, 0, sizeof(cmd)); + memset(buf, 0, sizeof(buf)); + cmd[0] =3D INQUIRY; + cmd[1] =3D 1; + cmd[2] =3D 0x00; + cmd[4] =3D sizeof(buf); + + memset(&io_header, 0, sizeof(io_header)); + io_header.interface_id =3D 'S'; + io_header.dxfer_direction =3D SG_DXFER_FROM_DEV; + io_header.dxfer_len =3D sizeof(buf); + io_header.dxferp =3D buf; + io_header.cmdp =3D cmd; + io_header.cmd_len =3D sizeof(cmd); + io_header.mx_sb_len =3D sizeof(sensebuf); + io_header.sbp =3D sensebuf; + io_header.timeout =3D 6000; /* XXX */ + + ret =3D blk_ioctl(s->conf.blk, SG_IO, &io_header); + if (ret < 0 || io_header.driver_status || io_header.host_status) { + /* + * Do not assume anything if we can't retrieve the + * INQUIRY response to assert the VPD Block Limits + * support. + */ + s->needs_vpd_bl_emulation =3D false; + return; + } + + page_len =3D buf[3]; + for (i =3D 4; i < page_len + 4; i++) { + if (buf[i] =3D=3D 0xb0) { + s->needs_vpd_bl_emulation =3D false; + return; + } + } + s->needs_vpd_bl_emulation =3D true; +} + static void scsi_block_realize(SCSIDevice *dev, Error **errp) { SCSIDiskState *s =3D DO_UPCAST(SCSIDiskState, qdev, dev); @@ -2648,6 +2696,7 @@ static void scsi_block_realize(SCSIDevice *dev, Error= **errp) =20 scsi_realize(&s->qdev, errp); scsi_generic_read_device_identification(&s->qdev); + scsi_block_set_vpd_bl_emulation(dev); } =20 typedef struct SCSIBlockReq { diff --git a/hw/scsi/scsi-generic.c b/hw/scsi/scsi-generic.c index 64d3b79518..e08ffaa38c 100644 --- a/hw/scsi/scsi-generic.c +++ b/hw/scsi/scsi-generic.c @@ -243,9 +243,8 @@ static void scsi_read_complete(void * opaque, int ret) { SCSIGenericReq *r =3D (SCSIGenericReq *)opaque; SCSIDevice *s =3D r->req.dev; - SCSISense sense; uint8_t page, page_len; - int len, i; + int len; =20 assert(r->req.aiocb !=3D NULL); r->req.aiocb =3D NULL; @@ -328,11 +327,17 @@ static void scsi_read_complete(void * opaque, int ret) * the buffer, clean up the io_header to avoid firing up * the sense error. */ - if (sg_io_sense_from_errno(-ret, &r->io_header, &sense)) { + if (s->needs_vpd_bl_emulation) { + r->buflen =3D scsi_emulate_vpd_bl_page(s, r->buf); r->io_header.sb_len_wr =3D 0; =20 - /* Clean sg_io_sense */ + /* + * We have valid contents in the reply buffer but the + * io_header will report a sense error coming from + * the hardware in scsi_command_complete_noio. Clean it + * up the io_header to avoid reporting it. + */ r->io_header.driver_status =3D 0; r->io_header.status =3D 0; =20 @@ -346,26 +351,19 @@ static void scsi_read_complete(void * opaque, int ret) stl_be_p(&r->buf[12], MIN_NON_ZERO(max_transfer, ldl_be_p(&r->buf[1= 2]))); } - } else if (page =3D=3D 0x00) { + } else if (page =3D=3D 0x00 && s->needs_vpd_bl_emulation) { /* * Now we're capable of supplying the VPD Block Limits - * response if the hardware can't. Inspect if the INQUIRY - * response contains support for the VPD Block Limits page. - * Add it if it doesn't. + * response if the hardware can't. Add it in the INQUIRY + * Supported VPD pages response in case we are using the + * emulation for this device. * * This way, the guest kernel will be aware of the support * and will use it to proper setup the SCSI device. */ page_len =3D r->buf[3]; - for (i =3D 4; i < page_len + 4; i++) { - if (r->buf[i] =3D=3D 0xb0) { - break; - } - } - if (i =3D=3D page_len + 4) { - r->buf[i] =3D 0xb0; - r->buf[3] =3D ++page_len; - } + r->buf[page_len + 4] =3D 0xb0; + r->buf[3] =3D ++page_len; } } } diff --git a/include/hw/scsi/scsi.h b/include/hw/scsi/scsi.h index 4fdde102b8..5fba858b11 100644 --- a/include/hw/scsi/scsi.h +++ b/include/hw/scsi/scsi.h @@ -90,6 +90,7 @@ struct SCSIDevice uint64_t port_wwn; int scsi_version; int default_scsi_version; + bool needs_vpd_bl_emulation; }; =20 extern const VMStateDescription vmstate_scsi_device; --=20 2.14.3