From nobody Tue Oct 22 22:30:36 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass header.i=anthony.perard@vates.tech; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=quarantine dis=none) header.from=vates.tech ARC-Seal: i=1; a=rsa-sha256; t=1727345705; cv=none; d=zohomail.com; s=zohoarc; b=QOfGMpw67axduwNaZpWFJmRDVdqBv7ivza6WbqMK2g2VTiDnwRtuuLzfUs1wkXe0zZFQeQSzoJdzQMLD6AHXjy1hrMTs6iBeQb0183qA+aCfsDQ/UfG4sPPODW+p9lSbsUpDIU4Ssb73VlqOwireP+eqiCjYxzF6R/BrkxuEgUw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1727345705; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=v3B/Sq5q797M597CcyjXUiFgMC2JpYVkeXzk/0VKvek=; b=lll3fM9INVoZ2JXIS43kTKhgH3GcHeTbUwpviO3mGKuM31MYCTVrYL4KB1Livgf5PGa2b/GpQhrf1PsCjOo0xQyhcmCOMtvRqgbmleQ1eX+CNRShn+RP+rAyvIfmY6j8jc28rKZtOEziaakOR8C1QYCEBDYXYgQuChm4rV3eAL0= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=anthony.perard@vates.tech; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=quarantine dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1727345705640403.42449006312006; Thu, 26 Sep 2024 03:15:05 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.805156.1216210 (Exim 4.92) (envelope-from ) id 1stlW5-0005zi-B2; Thu, 26 Sep 2024 10:14:33 +0000 Received: by outflank-mailman (output) from mailman id 805156.1216210; Thu, 26 Sep 2024 10:14:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1stlW5-0005zb-7e; Thu, 26 Sep 2024 10:14:33 +0000 Received: by outflank-mailman (input) for mailman id 805156; Thu, 26 Sep 2024 10:14:31 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1stlW3-0005XB-MC for xen-devel@lists.xenproject.org; Thu, 26 Sep 2024 10:14:31 +0000 Received: from mail136-20.atl41.mandrillapp.com (mail136-20.atl41.mandrillapp.com [198.2.136.20]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 1c6acf6f-7bf0-11ef-a0ba-8be0dac302b0; Thu, 26 Sep 2024 12:14:29 +0200 (CEST) Received: from pmta11.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail136-20.atl41.mandrillapp.com (Mailchimp) with ESMTP id 4XDqFt5zH9zCfBkVd for ; Thu, 26 Sep 2024 10:14:26 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id b04c8c0a2027475f899eab81071c77c5; Thu, 26 Sep 2024 10:14:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1c6acf6f-7bf0-11ef-a0ba-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1727345666; x=1727606166; bh=v3B/Sq5q797M597CcyjXUiFgMC2JpYVkeXzk/0VKvek=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=x3v/zXYLudVNeoT5epbibVp7Z2Fus60mjLrkLPV75Oa0PFzXGlULZCWx8VPaNldxW zYVWwNd7tUCT+/XkmL4ZzcIu3h/FA1707PHc2FuxeF5pQZ6Li0gQMzbihgJNzjdBK3 lTMXKv8kMGOQj+TqjEsXyflIfGhnl+qZ7o+MdF9oEHuh3Ww7szw93udnTPYSgnOTDc /9XEdAw2iXwyHnCQiwBM7iY7Ykz6n8ytxCQ2wYAJutP4MK1DZlAs3l3+U4jWKMbmO3 58VpPSZdruW6AITaxqt3n+fSRTvIoBjo/4FyYuaPbjeXI/f09h+YCiOpSUnLF0JDHG 9TTn8RkaxXLHA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1727345666; x=1727606166; i=anthony.perard@vates.tech; bh=v3B/Sq5q797M597CcyjXUiFgMC2JpYVkeXzk/0VKvek=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=IedPJ6Y5U44VdUxNbq7KszUFxT0ffqUfY+0OS9fFlGuxn2qNkfwkvD99MQd2k90d+ 9sTUSOyYVG6MvIfss0WY6OcsYlEaiT/TIv7hjW77cuCpw7ZJYmbvjF08t1lE9DV8tO dkIHnO9mhjiNTfv8rtSsumMWjA+LRFlVXGTxIdR0attY131a++BTo9Ic9fEREbHL9R LU+yib404y9xuBJAIdI94QwevNH8ZFYJAEN5lUI6ccPDRN/pPoHLRHIRpleNi6Xxfu lU8PeMqM+SJMOu4G3Lysfov3Kvt5PG8JJ2PeW8zP804VTXcmRB/BPp3peXUvZRoF7C IvbJPQB5iJGoA== From: Anthony PERARD Subject: =?utf-8?Q?[PATCH=201/2]=20include:=20update=20Xen=20public=20headers=20io/blkif.h?= X-Mailer: git-send-email 2.39.2 X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1727345665475 To: qemu-devel@nongnu.org Cc: Anthony PERARD , Stefano Stabellini , Anthony PERARD , Paul Durrant , "Edgar E. Iglesias" , xen-devel@lists.xenproject.org Message-Id: <20240926101334.2388-2-anthony.perard@vates.tech> In-Reply-To: <20240926101334.2388-1-anthony.perard@vates.tech> References: <20240926101334.2388-1-anthony.perard@vates.tech> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.b04c8c0a2027475f899eab81071c77c5?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20240926:md Date: Thu, 26 Sep 2024 10:14:26 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @mandrillapp.com) (identity anthony.perard@vates.tech) X-ZM-MESSAGEID: 1727345708263116600 Content-Type: text/plain; charset="utf-8" Signed-off-by: Anthony PERARD --- include/hw/xen/interface/io/blkif.h | 52 +++++++++++++++++++++-------- 1 file changed, 39 insertions(+), 13 deletions(-) diff --git a/include/hw/xen/interface/io/blkif.h b/include/hw/xen/interface= /io/blkif.h index 22f1eef0c0..9b00d633d3 100644 --- a/include/hw/xen/interface/io/blkif.h +++ b/include/hw/xen/interface/io/blkif.h @@ -237,12 +237,16 @@ * sector-size * Values: * - * The logical block size, in bytes, of the underlying storage. This - * must be a power of two with a minimum value of 512. + * The logical block size, in bytes, of the underlying storage. This = must + * be a power of two with a minimum value of 512. The sector size sh= ould + * only be used for request segment length and alignment. * - * NOTE: Because of implementation bugs in some frontends this must be - * set to 512, unless the frontend advertizes a non-zero value - * in its "feature-large-sector-size" xenbus node. (See below). + * When exposing a device that uses a logical sector size of 4096, the + * only difference xenstore wise will be that 'sector-size' (and poss= ibly + * 'physical-sector-size' if supported by the backend) will be 4096, = but + * the 'sectors' node will still be calculated using 512 byte units. = The + * sector base units in the ring requests fields will all be 512 byte + * based despite the logical sector size exposed in 'sector-size'. * * physical-sector-size * Values: @@ -254,9 +258,9 @@ * sectors * Values: * - * The size of the backend device, expressed in units of "sector-size= ". - * The product of "sector-size" and "sectors" must also be an integer - * multiple of "physical-sector-size", if that node is present. + * The size of the backend device, expressed in units of 512b. The + * product of "sectors" * 512 must also be an integer multiple of + * "physical-sector-size", if that node is present. * *************************************************************************= **** * Frontend XenBus Nodes @@ -338,6 +342,7 @@ * feature-large-sector-size * Values: 0/1 (boolean) * Default Value: 0 + * Notes: DEPRECATED, 12 * * A value of "1" indicates that the frontend will correctly supply a= nd * interpret all sector-based quantities in terms of the "sector-size" @@ -411,6 +416,11 @@ *(10) The discard-secure property may be present and will be set to 1 if = the * backing device supports secure discard. *(11) Only used by Linux and NetBSD. + *(12) Possibly only ever implemented by the QEMU Qdisk backend and the Wi= ndows + * PV block frontend. Other backends and frontends supported 'sector-= size' + * values greater than 512 before such feature was added. Frontends s= hould + * not expose this node, neither should backends make any decisions ba= sed + * on it being exposed by the frontend. */ =20 /* @@ -619,11 +629,14 @@ #define BLKIF_MAX_INDIRECT_PAGES_PER_REQUEST 8 =20 /* - * NB. 'first_sect' and 'last_sect' in blkif_request_segment, as well as - * 'sector_number' in blkif_request, blkif_request_discard and - * blkif_request_indirect are sector-based quantities. See the description - * of the "feature-large-sector-size" frontend xenbus node above for - * more information. + * NB. 'first_sect' and 'last_sect' in blkif_request_segment are all in un= its + * of 512 bytes, despite the 'sector-size' xenstore node possibly having a + * value greater than 512. + * + * The value in 'first_sect' and 'last_sect' fields must be setup so that = the + * resulting segment offset and size is aligned to the logical sector size + * reported by the 'sector-size' xenstore node, see 'Backend Device Proper= ties' + * section. */ struct blkif_request_segment { grant_ref_t gref; /* reference to I/O buffer frame */ @@ -634,6 +647,10 @@ struct blkif_request_segment { =20 /* * Starting ring element for any I/O request. + * + * The 'sector_number' field is in units of 512b, despite the value of the + * 'sector-size' xenstore node. Note however that the offset in + * 'sector_number' must be aligned to 'sector-size'. */ struct blkif_request { uint8_t operation; /* BLKIF_OP_??? */ @@ -648,6 +665,10 @@ typedef struct blkif_request blkif_request_t; /* * Cast to this structure when blkif_request.operation =3D=3D BLKIF_OP_DIS= CARD * sizeof(struct blkif_request_discard) <=3D sizeof(struct blkif_request) + * + * The 'sector_number' field is in units of 512b, despite the value of the + * 'sector-size' xenstore node. Note however that the offset in + * 'sector_number' must be aligned to 'sector-size'. */ struct blkif_request_discard { uint8_t operation; /* BLKIF_OP_DISCARD */ @@ -660,6 +681,11 @@ struct blkif_request_discard { }; typedef struct blkif_request_discard blkif_request_discard_t; =20 +/* + * The 'sector_number' field is in units of 512b, despite the value of the + * 'sector-size' xenstore node. Note however that the offset in + * 'sector_number' must be aligned to 'sector-size'. + */ struct blkif_request_indirect { uint8_t operation; /* BLKIF_OP_INDIRECT */ uint8_t indirect_op; /* BLKIF_OP_{READ/WRITE} */ --=20 Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From nobody Tue Oct 22 22:30:36 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass header.i=anthony.perard@vates.tech; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=quarantine dis=none) header.from=vates.tech ARC-Seal: i=1; a=rsa-sha256; t=1727345710; cv=none; d=zohomail.com; s=zohoarc; b=nf+HtnwM/5yI0vKrVUexRVuA81DE/v/ObkGfSfyE4QfHYIoIvG1VZERcuMv0js4svwY0cmg03krbjnAFyn2BUwc84ITP66WtbFYPhgaa9ZM/CKrJUObLmsWogYBTsvgK4S0Yjp0ejjSAMl+M1xa27/dMdzInbIvRx160ksI18cA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1727345710; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=DRimZkyYpcmRSMJFhksb4hjZDJ7L7Xbrn74CwG57nLQ=; b=PZsjVLQ6NoyvPPfOu3AsiSW7zLFEACULlwruTgFMy0my46Fp765kJgz80M2zfKRd2GGlE8HlxuOMJ5pe9sLEE0M873EEiNLOn0Uav7VYOsBDwif3ALrBig3NLMkFnr9p5iosuHbcxZmz3S6MZcO/yXlHx+3HjMi4vGT/+4zLpMc= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=anthony.perard@vates.tech; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=quarantine dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1727345707706391.5847359389212; Thu, 26 Sep 2024 03:15:07 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.805155.1216201 (Exim 4.92) (envelope-from ) id 1stlW4-0005lY-49; Thu, 26 Sep 2024 10:14:32 +0000 Received: by outflank-mailman (output) from mailman id 805155.1216201; Thu, 26 Sep 2024 10:14:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1stlW4-0005lR-16; Thu, 26 Sep 2024 10:14:32 +0000 Received: by outflank-mailman (input) for mailman id 805155; Thu, 26 Sep 2024 10:14:31 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1stlW3-0005XB-0K for xen-devel@lists.xenproject.org; Thu, 26 Sep 2024 10:14:31 +0000 Received: from mail177-9.suw61.mandrillapp.com (mail177-9.suw61.mandrillapp.com [198.2.177.9]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 1c950d43-7bf0-11ef-a0ba-8be0dac302b0; Thu, 26 Sep 2024 12:14:29 +0200 (CEST) Received: from pmta14.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail177-9.suw61.mandrillapp.com (Mailchimp) with ESMTP id 4XDqFt4t2GzK5vrtM for ; Thu, 26 Sep 2024 10:14:26 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 8b1e87364ec749e9a3ab06a7add22449; Thu, 26 Sep 2024 10:14:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1c950d43-7bf0-11ef-a0ba-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1727345666; x=1727606166; bh=DRimZkyYpcmRSMJFhksb4hjZDJ7L7Xbrn74CwG57nLQ=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=PcNK7XF9kRnnlvT9kGbORay6vWsL6O+Rtr0rnOG24qAZrkA+/HIf7lrTq3PNi2vpa aiJjklG1TCPArzdY4YU+1cqR0OzCk5jmDk7dnNqH12OiW0+j8LmW0qK0YCbFEgWtrc kZyfNZImwJY/WM0Q8xZcD9jwGJ/8zfCm1TI5mhslpZjIPoZNwUMPnKK4piqmhB+x07 F/SZOu3JvJFY8Vx1eHJ30w4YFlnLB9BGpCaKsY+AMq5pfgP/Zw03NlVI41vQJms58b IQIL5c5rkbnVz+aOqPbzrBcXWOwzT9TyPmYO/snnaZ7xgXd6ElEldptlmiHUebW/+o wlFsRViXzAWhw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1727345666; x=1727606166; i=anthony.perard@vates.tech; bh=DRimZkyYpcmRSMJFhksb4hjZDJ7L7Xbrn74CwG57nLQ=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=z394Zolb7zwu51I2V02EKnuWI1LoPjiI4ff/pA04qh80FrJYDFXuTf0RDkyRTCOop F34fKxGDYAyOMoEJwu72SryC442VwNtFz3gEcZcl55bzq9+hmxshoQrHYgIKh5+WOe le2IZV56UYP4viMzB+kUyDN67dab/iYoNe9D2tgs99qViSh/6J9LzpMTvsHRSQhYQ7 XNNNJWm9QIt9pJA8v3Zpapja477MDrSGUKCrl5l1P3e9z749Xs2v65xATbcdyoMS6f C5qBjU6bOl9qW+opVcLCZp2hoIlfg3rLWOqQl3PZR2JqExS354FYwND7G9M0YJ+iFt tgK0NcfrABdUA== From: Anthony PERARD Subject: =?utf-8?Q?[PATCH=202/2]=20hw/block/xen-block:=20Update=20sector-size=20handling?= X-Mailer: git-send-email 2.39.2 X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1727345665867 To: qemu-devel@nongnu.org Cc: Anthony PERARD , Stefano Stabellini , Anthony PERARD , Paul Durrant , "Edgar E. Iglesias" , Stefan Hajnoczi , Kevin Wolf , Hanna Reitz , xen-devel@lists.xenproject.org, qemu-block@nongnu.org Message-Id: <20240926101334.2388-3-anthony.perard@vates.tech> In-Reply-To: <20240926101334.2388-1-anthony.perard@vates.tech> References: <20240926101334.2388-1-anthony.perard@vates.tech> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.8b1e87364ec749e9a3ab06a7add22449?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20240926:md Date: Thu, 26 Sep 2024 10:14:26 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity anthony.perard@vates.tech) (identity @mandrillapp.com) X-ZM-MESSAGEID: 1727345712069116600 Content-Type: text/plain; charset="utf-8" The use of "feature-large-sector-size" have been removed from the protocol, as it hasn't been evenly implemented across all backend and frontend. Linux for example will happily expose "sector-size" !=3D 512 even when "feature-large-sector-size" hasn't been set by the frontend. The specification have been clarified regarding what "sector" is by Xen commit 221f2748e8da ("blkif: reconcile protocol specification with in-use implementations"). https://xenbits.xenproject.org/gitweb/?p=3Dxen.git;a=3Dcommit;h=3D221f2748e= 8dabe8361b8cdfcffbeab9102c4c899 So change QEMU to follow the updated specification. Frontends that exposes "feature-large-sector-size" will most certainly misbehave if "sector-size" is different than 512, so don't even try. (Windows driver is likely to be the only one having implemented it.) Signed-off-by: Anthony PERARD --- hw/block/dataplane/xen-block.c | 31 ++++++++++++++++++++++--------- hw/block/xen-block.c | 8 ++++---- 2 files changed, 26 insertions(+), 13 deletions(-) diff --git a/hw/block/dataplane/xen-block.c b/hw/block/dataplane/xen-block.c index 98501e6885..43be97b4f3 100644 --- a/hw/block/dataplane/xen-block.c +++ b/hw/block/dataplane/xen-block.c @@ -176,7 +176,11 @@ static int xen_block_parse_request(XenBlockRequest *re= quest) goto err; } =20 - request->start =3D request->req.sector_number * dataplane->sector_size; + request->start =3D request->req.sector_number * XEN_BLKIF_SECTOR_SIZE; + if (!QEMU_IS_ALIGNED(request->start, dataplane->sector_size)) { + error_report("error: sector_number missaligned with sector-size"); + goto err; + } for (i =3D 0; i < request->req.nr_segments; i++) { if (i =3D=3D BLKIF_MAX_SEGMENTS_PER_REQUEST) { error_report("error: nr_segments too big"); @@ -186,14 +190,23 @@ static int xen_block_parse_request(XenBlockRequest *r= equest) error_report("error: first > last sector"); goto err; } - if (request->req.seg[i].last_sect * dataplane->sector_size >=3D + if (request->req.seg[i].last_sect * XEN_BLKIF_SECTOR_SIZE >=3D XEN_PAGE_SIZE) { error_report("error: page crossing"); goto err; } + if (!QEMU_IS_ALIGNED(request->req.seg[i].first_sect, + dataplane->sector_size / XEN_BLKIF_SECTOR_SIZ= E)) { + error_report("error: first_sect missaligned with sector-size"); + goto err; + } =20 len =3D (request->req.seg[i].last_sect - - request->req.seg[i].first_sect + 1) * dataplane->sector_siz= e; + request->req.seg[i].first_sect + 1) * XEN_BLKIF_SECTOR_SIZE; + if (!QEMU_IS_ALIGNED(len, dataplane->sector_size)) { + error_report("error: segment size missaligned with sector-size= "); + goto err; + } request->size +=3D len; } if (request->start + request->size > blk_getlength(dataplane->blk)) { @@ -227,17 +240,17 @@ static int xen_block_copy_request(XenBlockRequest *re= quest) if (to_domain) { segs[i].dest.foreign.ref =3D request->req.seg[i].gref; segs[i].dest.foreign.offset =3D request->req.seg[i].first_sect= * - dataplane->sector_size; + XEN_BLKIF_SECTOR_SIZE; segs[i].source.virt =3D virt; } else { segs[i].source.foreign.ref =3D request->req.seg[i].gref; segs[i].source.foreign.offset =3D request->req.seg[i].first_se= ct * - dataplane->sector_size; + XEN_BLKIF_SECTOR_SIZE; segs[i].dest.virt =3D virt; } segs[i].len =3D (request->req.seg[i].last_sect - request->req.seg[i].first_sect + 1) * - dataplane->sector_size; + XEN_BLKIF_SECTOR_SIZE; virt +=3D segs[i].len; } =20 @@ -331,12 +344,12 @@ static bool xen_block_split_discard(XenBlockRequest *= request, =20 /* Wrap around, or overflowing byte limit? */ if (sec_start + sec_count < sec_count || - sec_start + sec_count > INT64_MAX / dataplane->sector_size) { + sec_start + sec_count > INT64_MAX / XEN_BLKIF_SECTOR_SIZE) { return false; } =20 - byte_offset =3D sec_start * dataplane->sector_size; - byte_remaining =3D sec_count * dataplane->sector_size; + byte_offset =3D sec_start * XEN_BLKIF_SECTOR_SIZE; + byte_remaining =3D sec_count * XEN_BLKIF_SECTOR_SIZE; =20 do { byte_chunk =3D byte_remaining > BDRV_REQUEST_MAX_BYTES ? diff --git a/hw/block/xen-block.c b/hw/block/xen-block.c index aed1d5c330..8c150c6c69 100644 --- a/hw/block/xen-block.c +++ b/hw/block/xen-block.c @@ -189,10 +189,10 @@ static void xen_block_connect(XenDevice *xendev, Erro= r **errp) feature_large_sector_size =3D 0; } =20 - if (feature_large_sector_size !=3D 1 && + if (feature_large_sector_size =3D=3D 1 && conf->logical_block_size !=3D XEN_BLKIF_SECTOR_SIZE) { - error_setg(errp, "logical_block_size !=3D %u not supported by fron= tend", - XEN_BLKIF_SECTOR_SIZE); + error_setg(errp, + "\"feature-large-sector-size\" not supported by backend= "); return; } =20 @@ -294,7 +294,7 @@ static void xen_block_set_size(XenBlockDevice *blockdev) const char *type =3D object_get_typename(OBJECT(blockdev)); XenBlockVdev *vdev =3D &blockdev->props.vdev; BlockConf *conf =3D &blockdev->props.conf; - int64_t sectors =3D blk_getlength(conf->blk) / conf->logical_block_siz= e; + int64_t sectors =3D blk_getlength(conf->blk) / XEN_BLKIF_SECTOR_SIZE; XenDevice *xendev =3D XEN_DEVICE(blockdev); =20 trace_xen_block_size(type, vdev->disk, vdev->partition, sectors); --=20 Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech