From nobody Mon Feb 9 23:38:06 2026 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