From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 394EE2F2910 for ; Thu, 18 Jun 2026 07:41:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781768495; cv=none; b=DeklDiUGdLyPnC5HqCdPttONzFtjSE2dIJ8FakeCOPdKw/MDZDQ7qznub/x9aWvaesr40ysTQ0xRc4p50K+KqdgctBuNPwidF8HjzoDQT+vZY0XjVDJKZcJXfVZHcJpl73grFDY479DJrVxdJrnBv0mr08nfobMHlDBvelENLpA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781768495; c=relaxed/simple; bh=gZkwZs34r2bbac54SVywYC/jPjvgeK3vRDRUywn0qf0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=hRStXXWfipq6H+TCINUgFRSk0Z3p0jsC9YvsX/peydr4H0DtIfE1UFn3W2AL7sjAr8ghTqllmCaEPFaY8LdDCScJQvAEHPp9zA7Bv4GCYAdxK9G2uwtO0ptKHjcfDW5rvj+zEtOcwA9LbF1bVYu4oJIF70LIV3TQTTokOTQONl8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=JhJMOwXZ; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=nLoV/r2a; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="JhJMOwXZ"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="nLoV/r2a" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1781768493; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Y7/6GMFySLjEAnNbADHN8HTqTCVaGwns6zVzwQSvgaU=; b=JhJMOwXZmKszw6eq5HhdiDBBRWeCFomlDpwKeT+9atGBVlwQ7ZmxuqUmVSMMppoocYbI/Y p11sC8ePMn9YAUf5u3Unl6ELxP5tXIyd7gGPCF57H9MqXIA+vHlhj1xOfXZxr1bYLnf/Lm Dc/4t1vzRKPv0jJfRr3SpZBV/2hUDMk= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-31-nHRH7zomMfSgnwTrCd46Vg-1; Thu, 18 Jun 2026 03:41:31 -0400 X-MC-Unique: nHRH7zomMfSgnwTrCd46Vg-1 X-Mimecast-MFC-AGG-ID: nHRH7zomMfSgnwTrCd46Vg_1781768490 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-490b4d3d3e6so3379785e9.0 for ; Thu, 18 Jun 2026 00:41:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1781768490; x=1782373290; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Y7/6GMFySLjEAnNbADHN8HTqTCVaGwns6zVzwQSvgaU=; b=nLoV/r2a9XDkJ4Ybm8G5QlIBNj7FmQYeXkXuS7DSFMGjpkx8qayczALTshSpSjErkL odsthEezIRO+PgwDHdms6Xa1nmsuBJ2Nj4XqQWeu73ExzUiZ4eMcv0uqQ1BSQw3RcyE7 nnw2oQ3TU+s9ktUuoA71GeETr6ircUlmkt0WdhivDJI+eQefZteO4kdF88eDHCHLIHE8 Z6SrkcCetihUd5palHNcpU79Io/xvfQoZqJRthZUs7eh8MgjjpD7yT9PUGZxt2YlpMl4 A4FzBdztD/XS9Zn3jeCvARkA3lrMkHmRLWnL57VM2hkne3wRtDtm/RtHjek4wN/W4DFZ +pfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781768490; x=1782373290; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Y7/6GMFySLjEAnNbADHN8HTqTCVaGwns6zVzwQSvgaU=; b=EA8EMcM/Z+FfjA83Ow3Gke2tS4su19syrkN3bKJTsjypiKGcBRdp7hHeEbPpTAmH+u EnvO+mK3ZogftYbOM+EM06fZ9+MuzqBBXRjH0i3lT7atvRzD3TyjzYkduJPoAuQ4chbD 1sSr1xp76J7+aIenPnlVHDkWanUWBBMSJ4RKXo48GWWYhBSqwQ77THY7Xa6rYDUOYomZ 4lYMZoMzyHgycGdCkj6LNBuoPUEqklBWnFAP6OV2ic8+Jh0p/zPm44Dt9LFjJESGS0HZ BJaAjkLvMHwIRu1FaFlNJfeBtuFJng9z/VgfbksC2maBr/4e2BR9iOrajBCoWEeOPDYU 2JzQ== X-Forwarded-Encrypted: i=1; AFNElJ/UsJ4xUDNm1eKvTVsppsSntPHftD/WZhKGLttR9gJ2UcChz/U0ON1X3ipvijeg+Znrnknf+0ad2H+sLrU=@vger.kernel.org X-Gm-Message-State: AOJu0YyApVQPEkzaQr2WHE5QK0f8lQzu4279K168k5hMBokkVUuKqjk0 VJNWX1h18sgO2m1jGGb2V6BLC8qPPQwiq8AxhS1dOQtN05mA1+AY4i6inzjBYEZCYvsRTfRKt6K 0jZVSdblH9tKAcDVv8/XNuBGd+gIYUheQnY+gJypYA5hMQ6IGhvHhUjsus2sDUpbyZw== X-Gm-Gg: AfdE7cmnJTL7Cjeic6Zk4qx+Z96rO0jKb5ItNzES7o6YlmCfDUstVWpaeNL6LYTbId6 2MkaGaiOx008xE4zw72YKr3Lh/Fcnc96kEH8u+EZYJ87f462/N41Q4E7l3NlQB5GIdUrPK+1gQC +kApmlk5T2JmUInYpakzmX1cJhljyIFnHDEnWaHK6q43uJD502uJ/1gr6ypBOqgGVLdvI7DgtDo EXTHTmejwDU22a5i6hntYTVIh3/AqkX81bGSl56JoyvktkqYrHapRWjKkKO7ChLbSbdbo4K5UqV vMlkrtr9mZDndESK3RdxAjp+4XToaLtlC3AyEMK8ivH3YZkIpu5e1RnR4nOGcBgMcGKkNYZo9n9 z02fKZAILBecCAtfEKT/RrZs0e+mM26fdblyKoc3uqK6YCR75zjkca0TgdgYr X-Received: by 2002:a05:600c:19d0:b0:490:44eb:c1e0 with SMTP id 5b1f17b1804b1-4923a9d0827mr13388055e9.21.1781768490316; Thu, 18 Jun 2026 00:41:30 -0700 (PDT) X-Received: by 2002:a05:600c:19d0:b0:490:44eb:c1e0 with SMTP id 5b1f17b1804b1-4923a9d0827mr13387535e9.21.1781768489797; Thu, 18 Jun 2026 00:41:29 -0700 (PDT) Received: from sgarzare-redhat (host-82-53-135-12.retail.telecomitalia.it. [82.53.135.12]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4922fa97a07sm384710215e9.14.2026.06.18.00.41.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Jun 2026 00:41:29 -0700 (PDT) Date: Thu, 18 Jun 2026 09:41:22 +0200 From: Stefano Garzarella To: Michael Bommarito Cc: "Michael S . Tsirkin" , Jason Wang , Stefan Hajnoczi , Dmitry Fomichev , Damien Le Moal , Jens Axboe , Paolo Bonzini , virtualization@lists.linux.dev, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] virtio-blk: use little-endian types for the zoned fields Message-ID: References: <20260617151727.4071754-1-michael.bommarito@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20260617151727.4071754-1-michael.bommarito@gmail.com> On Wed, Jun 17, 2026 at 11:17:27AM -0400, Michael Bommarito wrote: >The zoned block-device fields in the virtio-blk header are typed >__virtio{32,64}, so their endianness follows VIRTIO_F_VERSION_1. The >zoned feature is only defined for VIRTIO 1.x devices, and the virtio >specification defines all of its fields as little-endian. Commit >b16a1756c716 ("virtio_blk: mark all zone fields LE") tagged them >__le* for exactly this reason, but commit f1ba4e674feb ("virtio-blk: >fix to match virtio spec") re-applied the reviewed version of the >original zoned series -- which predated b16a1756 -- and silently >restored the __virtio* typing together with the matching >virtio*_to_cpu() / virtio_cread() accessors in the driver. > >Restore the little-endian typing for the zoned configuration-space >characteristics, the zone descriptor, the zone report header and the >ZONE_APPEND in-header sector, and read them with le*_to_cpu() and >virtio_cread_le() to match. > >There is no functional change on any spec-compliant device: zoned >requires VIRTIO_F_VERSION_1, and for a VERSION_1 device >virtio*_to_cpu() is identical to le*_to_cpu(). The change makes the >uapi types describe the actual wire format and removes a latent >endianness mismatch for a (non-conformant) legacy device on a >big-endian guest. Not for this patch, but at this point should we do the same also for the fields gated by the following features that IIUC are all added in 1.*: - VIRTIO_BLK_F_MQ - VIRTIO_BLK_F_DISCARD - VIRTIO_BLK_F_WRITE_ZEROES - VIRTIO_BLK_F_SECURE_ERASE > >Fixes: f1ba4e674feb ("virtio-blk: fix to match virtio spec") >Suggested-by: Michael S. Tsirkin >Assisted-by: Claude:claude-opus-4-8 >Signed-off-by: Michael Bommarito >--- >Testing: > - Builds with no new warnings; sparse endian-clean (C=2, > __CHECK_ENDIAN__, CONFIG_BLK_DEV_ZONED=y) both before and after. > - Booted under QEMU with a host-managed zoned device exposed through > virtio-blk. Zone revalidation, blkzone report and a sequential > write / write-pointer check return correct values; blktests zbd > device tests 001-006 (sysfs+ioctl, report zone, reset, write split, > write ordering, revalidate) pass, with results identical before and > after this change -- expected, since on a VIRTIO_F_VERSION_1 device > virtio*_to_cpu() == le*_to_cpu(). > > drivers/block/virtio_blk.c | 38 +++++++++++++++------------------ > include/uapi/linux/virtio_blk.h | 18 ++++++++-------- > 2 files changed, 26 insertions(+), 30 deletions(-) > >diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c >index b1c9a27fe00f3..5532cfbde7bfe 100644 >--- a/drivers/block/virtio_blk.c >+++ b/drivers/block/virtio_blk.c >@@ -99,7 +99,7 @@ struct virtblk_req { > * be the last byte. > */ > struct { >- __virtio64 sector; >+ __le64 sector; > u8 status; > } zone_append; > } in_hdr; >@@ -335,14 +335,12 @@ static inline void virtblk_request_done(struct request *req) > { > struct virtblk_req *vbr = blk_mq_rq_to_pdu(req); > blk_status_t status = virtblk_result(virtblk_vbr_status(vbr)); >- struct virtio_blk *vblk = req->mq_hctx->queue->queuedata; > > virtblk_unmap_data(req, vbr); > virtblk_cleanup_cmd(req); > > if (req_op(req) == REQ_OP_ZONE_APPEND) >- req->__sector = virtio64_to_cpu(vblk->vdev, >- vbr->in_hdr.zone_append.sector); >+ req->__sector = le64_to_cpu(vbr->in_hdr.zone_append.sector); > > blk_mq_end_request(req, status); > } >@@ -589,13 +587,13 @@ static int virtblk_parse_zone(struct virtio_blk *vblk, > { > struct blk_zone zone = { }; > >- zone.start = virtio64_to_cpu(vblk->vdev, entry->z_start); >+ zone.start = le64_to_cpu(entry->z_start); > if (zone.start + vblk->zone_sectors <= get_capacity(vblk->disk)) > zone.len = vblk->zone_sectors; > else > zone.len = get_capacity(vblk->disk) - zone.start; >- zone.capacity = virtio64_to_cpu(vblk->vdev, entry->z_cap); >- zone.wp = virtio64_to_cpu(vblk->vdev, entry->z_wp); >+ zone.capacity = le64_to_cpu(entry->z_cap); >+ zone.wp = le64_to_cpu(entry->z_wp); > > switch (entry->z_type) { > case VIRTIO_BLK_ZT_SWR: >@@ -687,8 +685,7 @@ static int virtblk_report_zones(struct gendisk *disk, sector_t sector, > if (ret) > goto fail_report; > >- nz = min_t(u64, virtio64_to_cpu(vblk->vdev, report->nr_zones), >- nr_zones); >+ nz = min_t(u64, le64_to_cpu(report->nr_zones), nr_zones); > if (!nz) > break; > >@@ -698,8 +695,7 @@ static int virtblk_report_zones(struct gendisk *disk, sector_t sector, > if (ret) > goto fail_report; > >- sector = virtio64_to_cpu(vblk->vdev, >- report->zones[i].z_start) + >+ sector = le64_to_cpu(report->zones[i].z_start) + > vblk->zone_sectors; > zone_idx++; > } >@@ -725,18 +721,18 @@ static int virtblk_read_zoned_limits(struct virtio_blk *vblk, > > lim->features |= BLK_FEAT_ZONED; > >- virtio_cread(vdev, struct virtio_blk_config, >- zoned.max_open_zones, &v); >+ virtio_cread_le(vdev, struct virtio_blk_config, >+ zoned.max_open_zones, &v); > lim->max_open_zones = v; > dev_dbg(&vdev->dev, "max open zones = %u\n", v); > >- virtio_cread(vdev, struct virtio_blk_config, >- zoned.max_active_zones, &v); >+ virtio_cread_le(vdev, struct virtio_blk_config, >+ zoned.max_active_zones, &v); > lim->max_active_zones = v; > dev_dbg(&vdev->dev, "max active zones = %u\n", v); > >- virtio_cread(vdev, struct virtio_blk_config, >- zoned.write_granularity, &wg); >+ virtio_cread_le(vdev, struct virtio_blk_config, >+ zoned.write_granularity, &wg); > if (!wg) { > dev_warn(&vdev->dev, "zero write granularity reported\n"); > return -ENODEV; >@@ -750,8 +746,8 @@ static int virtblk_read_zoned_limits(struct virtio_blk *vblk, > * virtio ZBD specification doesn't require zones to be a power of > * two sectors in size, but the code in this driver expects that. > */ >- virtio_cread(vdev, struct virtio_blk_config, zoned.zone_sectors, >- &vblk->zone_sectors); >+ virtio_cread_le(vdev, struct virtio_blk_config, zoned.zone_sectors, >+ &vblk->zone_sectors); > if (vblk->zone_sectors == 0 || !is_power_of_2(vblk->zone_sectors)) { > dev_err(&vdev->dev, > "zoned device with non power of two zone size %u\n", >@@ -767,8 +763,8 @@ static int virtblk_read_zoned_limits(struct virtio_blk *vblk, > lim->max_hw_discard_sectors = 0; > } > >- virtio_cread(vdev, struct virtio_blk_config, >- zoned.max_append_sectors, &v); >+ virtio_cread_le(vdev, struct virtio_blk_config, >+ zoned.max_append_sectors, &v); > if (!v) { > dev_warn(&vdev->dev, "zero max_append_sectors reported\n"); > return -ENODEV; >diff --git a/include/uapi/linux/virtio_blk.h b/include/uapi/linux/virtio_blk.h >index 3744e4da1b2a7..5af2a0300bb9d 100644 >--- a/include/uapi/linux/virtio_blk.h >+++ b/include/uapi/linux/virtio_blk.h >@@ -140,11 +140,11 @@ struct virtio_blk_config { > To avoid making this mistake again, how about adding a note here to clarify that all the fields listed below are defined only for VIRTIO 1.x devices and are therefore always little-endian? Anyway, the patch LGTM: Reviewed-by: Stefano Garzarella > /* Zoned block device characteristics (if VIRTIO_BLK_F_ZONED) */ > struct virtio_blk_zoned_characteristics { >- __virtio32 zone_sectors; >- __virtio32 max_open_zones; >- __virtio32 max_active_zones; >- __virtio32 max_append_sectors; >- __virtio32 write_granularity; >+ __le32 zone_sectors; >+ __le32 max_open_zones; >+ __le32 max_active_zones; >+ __le32 max_append_sectors; >+ __le32 write_granularity; > __u8 model; > __u8 unused2[3]; > } zoned; >@@ -241,11 +241,11 @@ struct virtio_blk_outhdr { > */ > struct virtio_blk_zone_descriptor { > /* Zone capacity */ >- __virtio64 z_cap; >+ __le64 z_cap; > /* The starting sector of the zone */ >- __virtio64 z_start; >+ __le64 z_start; > /* Zone write pointer position in sectors */ >- __virtio64 z_wp; >+ __le64 z_wp; > /* Zone type */ > __u8 z_type; > /* Zone state */ >@@ -254,7 +254,7 @@ struct virtio_blk_zone_descriptor { > }; > > struct virtio_blk_zone_report { >- __virtio64 nr_zones; >+ __le64 nr_zones; > __u8 reserved[56]; > struct virtio_blk_zone_descriptor zones[]; > }; >-- >2.53.0 >