From patchwork Thu Sep 26 10:14:26 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Anthony PERARD X-Patchwork-Id: 13813198 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org 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 smtp.lore.kernel.org (Postfix) with ESMTPS id E42C9CCF9E9 for ; Thu, 26 Sep 2024 10:33:59 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1stloK-00040f-Sl; Thu, 26 Sep 2024 06:33:25 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1stloJ-0003vc-7n for qemu-devel@nongnu.org; Thu, 26 Sep 2024 06:33:23 -0400 Received: from mail136-20.atl41.mandrillapp.com ([198.2.136.20]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1stloH-0002B9-9w for qemu-devel@nongnu.org; Thu, 26 Sep 2024 06:33:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1727345667; x=1727606167; 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=tp4PIaaIl69Ttun2mNGvvB5A61t+EhtSwSsVvqLwiL5B7uZoWd0uqGre7CRd+xv+X 9aiqKbbK+fmWzod7/ybr1RDcLDixpzctIn9S+3Rl9QVWzEceuuf3tDUGY9cMrP0vZB Cz8alBkd9/1nKAS8licKkP5Vp/4jVFZJcdm2HUgvV5v8XfzMqeL/texwM7Zm8gMs7x pZbcDSxkpNmpURHqgkVrIlaVlvhwZXu+BuL1pzQqOSp1C7kaj7gsB+oJYv8rjpXGU6 mPlvqFS5jjWi4B67MGFqXRyerlCixikTQBZ5SjG8VVbLdwXG47H2+HtVnRQTnGEj0j R8MD2xoQcaheQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1727345667; x=1727606167; 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=JFzeOgt+OvofUo8sxjJQGQA4x58mgj2gGF5E0wMN5NsOyevINP8sScBBBnlUjOn7u uPg1kewvMgLaoodpraIUfBGSrEq3owXOARAqXUE2mP83Zw3GFZ1llxhKq2DXOW+xx6 adHUn3pcER6S1JDkNvAAo93PHjqUUZtf9QaxeUmlTU2IDcTBrA+YKACG49LIuuUW+z a44rRBI6RwpYZLkvDB4Gu8xW85XKbh5lLsPSbk3X0mpTDYwN8U9VUGNKNl2qxo0eLE 2TWApaFygskt+/egL0rdWGX7xEqZvsIrKpdDMiBo25DCcLktu/hrGT/IJQRf4SBO6a R5EJktSuC0pUQ== Received: from pmta11.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail136-20.atl41.mandrillapp.com (Mailchimp) with ESMTP id 4XDqFt74XgzCfBkVf for ; Thu, 26 Sep 2024 10:14:26 +0000 (GMT) From: Anthony PERARD Subject: =?utf-8?q?=5BPATCH_1/2=5D_include=3A_update_Xen_public_headers_io/b?= =?utf-8?q?lkif=2Eh?= Received: from [37.26.189.201] by mandrillapp.com id bed7b4e8d2e64ca6923f6d14752892a7; Thu, 26 Sep 2024 10:14:26 +0000 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.bed7b4e8d2e64ca6923f6d14752892a7?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20240926:md Date: Thu, 26 Sep 2024 10:14:26 +0000 MIME-Version: 1.0 Received-SPF: pass client-ip=198.2.136.20; envelope-from=bounce-md_30504962.66f53402.v1-bed7b4e8d2e64ca6923f6d14752892a7@bounce.vates.tech; helo=mail136-20.atl41.mandrillapp.com 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_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-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.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org 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 should + * 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 possibly + * '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 and * 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 Windows + * PV block frontend. Other backends and frontends supported 'sector-size' + * values greater than 512 before such feature was added. Frontends should + * not expose this node, neither should backends make any decisions based + * on it being exposed by the frontend. */ /* @@ -619,11 +629,14 @@ #define BLKIF_MAX_INDIRECT_PAGES_PER_REQUEST 8 /* - * 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 units + * 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 Properties' + * section. */ struct blkif_request_segment { grant_ref_t gref; /* reference to I/O buffer frame */ @@ -634,6 +647,10 @@ struct blkif_request_segment { /* * 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 == BLKIF_OP_DISCARD * sizeof(struct blkif_request_discard) <= 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; +/* + * 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} */ From patchwork Thu Sep 26 10:14:26 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Anthony PERARD X-Patchwork-Id: 13813200 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org 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 smtp.lore.kernel.org (Postfix) with ESMTPS id A257BCCFA13 for ; Thu, 26 Sep 2024 10:34:37 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1stlpI-0007On-Rk; Thu, 26 Sep 2024 06:34:26 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1stlpD-0006q7-AB for qemu-devel@nongnu.org; Thu, 26 Sep 2024 06:34:19 -0400 Received: from mail177-9.suw61.mandrillapp.com ([198.2.177.9]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1stlp3-0002IQ-JW for qemu-devel@nongnu.org; Thu, 26 Sep 2024 06:34:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1727345667; x=1727606167; 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=YxtWIggBTflIkpwreiigs3s3C/ixmLF6QvMrUtb/1YvQ5nYUTgxJvLoKQtMbpigA4 mlxy+iQrNCUdUa0HbzUEgVo73HkzkTwQy88XYMc8LJhgyOXJIZg2jpRPMWDSxSSzNw wCkSsWpwoDoHg6cQlvr1gBxBU/WygD3ki25nUfrp1+byiPW516Ek9aNtqMuzW/YEvs SIgewiGjh5NQ6lo2EWi+Mj+P8s4C2G4lNjK0arUuh8yUK7ahOT94zg3fhVCJaAAJzm mLHvfufez3qWfDS1CS9Kpk63pLdrSGTzHqqXEFauEi0foa9c+/8IbBf0mVkzPggi7D uGCB02oVTWimA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1727345667; x=1727606167; 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=a/jTHymjWLABeOl0YvoklvLJ2raGhtWUw1L62ibkXJLEUMfhATptKhYvxfIcmXSZ5 yUr5kgIVpmLSLRlWVwpGvlIb7wgsC5fKxTeL0MCaYG2LCZGZZqKjMn2HAm8YiuZ7+g xo2bOrnKK6yzPhVZ+W1iQ2JyfjpJJdnHifFe/ksEHQXUsS1UDoNls4kipG6qNYFJoP wZY3v/Qq6FT/CLtbMoEbtaABtABH/9m7RoUNX0BGzsERlfPa8uz1TyIXDmVMnT2UtZ KaOrhrn87tnyXw8ic3k8SWNeR5OBC3IKGwHMo6ihLQTEuN1Ykf+WFcpGEzWEvZb9d5 LxQ4i4izMNnBA== Received: from pmta14.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail177-9.suw61.mandrillapp.com (Mailchimp) with ESMTP id 4XDqFv0WdkzK5vrsx for ; Thu, 26 Sep 2024 10:14:27 +0000 (GMT) From: Anthony PERARD Subject: =?utf-8?q?=5BPATCH_2/2=5D_hw/block/xen-block=3A_Update_sector-size_?= =?utf-8?q?handling?= Received: from [37.26.189.201] by mandrillapp.com id 468271bc01d8452aa5f20c3e490bcf15; Thu, 26 Sep 2024 10:14:26 +0000 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.468271bc01d8452aa5f20c3e490bcf15?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20240926:md Date: Thu, 26 Sep 2024 10:14:26 +0000 MIME-Version: 1.0 Received-SPF: pass client-ip=198.2.177.9; envelope-from=bounce-md_30504962.66f53402.v1-468271bc01d8452aa5f20c3e490bcf15@bounce.vates.tech; helo=mail177-9.suw61.mandrillapp.com 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_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-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.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org 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" != 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=xen.git;a=commit;h=221f2748e8dabe8361b8cdfcffbeab9102c4c899 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 *request) goto err; } - request->start = request->req.sector_number * dataplane->sector_size; + request->start = 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 = 0; i < request->req.nr_segments; i++) { if (i == BLKIF_MAX_SEGMENTS_PER_REQUEST) { error_report("error: nr_segments too big"); @@ -186,14 +190,23 @@ static int xen_block_parse_request(XenBlockRequest *request) error_report("error: first > last sector"); goto err; } - if (request->req.seg[i].last_sect * dataplane->sector_size >= + if (request->req.seg[i].last_sect * XEN_BLKIF_SECTOR_SIZE >= 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_SIZE)) { + error_report("error: first_sect missaligned with sector-size"); + goto err; + } len = (request->req.seg[i].last_sect - - request->req.seg[i].first_sect + 1) * dataplane->sector_size; + 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 += len; } if (request->start + request->size > blk_getlength(dataplane->blk)) { @@ -227,17 +240,17 @@ static int xen_block_copy_request(XenBlockRequest *request) if (to_domain) { segs[i].dest.foreign.ref = request->req.seg[i].gref; segs[i].dest.foreign.offset = request->req.seg[i].first_sect * - dataplane->sector_size; + XEN_BLKIF_SECTOR_SIZE; segs[i].source.virt = virt; } else { segs[i].source.foreign.ref = request->req.seg[i].gref; segs[i].source.foreign.offset = request->req.seg[i].first_sect * - dataplane->sector_size; + XEN_BLKIF_SECTOR_SIZE; segs[i].dest.virt = virt; } segs[i].len = (request->req.seg[i].last_sect - request->req.seg[i].first_sect + 1) * - dataplane->sector_size; + XEN_BLKIF_SECTOR_SIZE; virt += segs[i].len; } @@ -331,12 +344,12 @@ static bool xen_block_split_discard(XenBlockRequest *request, /* 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; } - byte_offset = sec_start * dataplane->sector_size; - byte_remaining = sec_count * dataplane->sector_size; + byte_offset = sec_start * XEN_BLKIF_SECTOR_SIZE; + byte_remaining = sec_count * XEN_BLKIF_SECTOR_SIZE; do { byte_chunk = 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, Error **errp) feature_large_sector_size = 0; } - if (feature_large_sector_size != 1 && + if (feature_large_sector_size == 1 && conf->logical_block_size != XEN_BLKIF_SECTOR_SIZE) { - error_setg(errp, "logical_block_size != %u not supported by frontend", - XEN_BLKIF_SECTOR_SIZE); + error_setg(errp, + "\"feature-large-sector-size\" not supported by backend"); return; } @@ -294,7 +294,7 @@ static void xen_block_set_size(XenBlockDevice *blockdev) const char *type = object_get_typename(OBJECT(blockdev)); XenBlockVdev *vdev = &blockdev->props.vdev; BlockConf *conf = &blockdev->props.conf; - int64_t sectors = blk_getlength(conf->blk) / conf->logical_block_size; + int64_t sectors = blk_getlength(conf->blk) / XEN_BLKIF_SECTOR_SIZE; XenDevice *xendev = XEN_DEVICE(blockdev); trace_xen_block_size(type, vdev->disk, vdev->partition, sectors);