From: Klaus Jensen <its@irrelevant.dk>
To: qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
Pankaj Raghav <p.raghav@samsung.com>,
Klaus Jensen <k.jensen@samsung.com>,
Keith Busch <kbusch@kernel.org>, Klaus Jensen <its@irrelevant.dk>,
Jesper Devantier <foss@defmacro.it>,
qemu-block@nongnu.org
Subject: [PULL 1/2] hw/nvme: re-enable wzds bit in namespace dlfeat
Date: Thu, 26 Mar 2026 09:23:48 +0100 [thread overview]
Message-ID: <20260326082350.17374-2-its@irrelevant.dk> (raw)
In-Reply-To: <20260326082350.17374-1-its@irrelevant.dk>
From: Pankaj Raghav <p.raghav@samsung.com>
dlfeat was changed from 0x9 to 0x1 when PI support was added.
It was removed because we can't rely on unmap and have to physically
clear it to get the checksums right but that doesnt mean that we do not
support the bit.
The spec says that if wzds is enabled, then the controller supports
deallocate (DEAC) on write zeroes. But DEAC bit in write zeroes command
is only a hint, the controller might choose to physically write zeroes in
those areas.
As we are sending write zeroes command with BDRV_REQ_MAY_UNMAP to the
underlying block device anyway (if the unmap operation is supported),
change the dlfeat value back to 0x9.
A new flag FALLOC_FL_WRITE_ZEROES has been introduced in linux for
fallocate which will use the wzds bit in dlfeat to quickly zeroout extents
using unmap operation whenever possible[1].
[1] https://lore.kernel.org/linux-fsdevel/20250619111806.3546162-1-yi.zhang@huaweicloud.com/
Fixes: 146f720c55 ("hw/block/nvme: end-to-end data protection")
Suggested-by: Klaus Jensen <k.jensen@samsung.com>
Signed-off-by: Pankaj Raghav <p.raghav@samsung.com>
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
---
hw/nvme/ns.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/nvme/ns.c b/hw/nvme/ns.c
index 38f86a17268f..b0106eaa5c8f 100644
--- a/hw/nvme/ns.c
+++ b/hw/nvme/ns.c
@@ -75,7 +75,7 @@ static int nvme_ns_init(NvmeNamespace *ns, Error **errp)
ns->csi = NVME_CSI_NVM;
ns->status = 0x0;
- ns->id_ns.dlfeat = 0x1;
+ ns->id_ns.dlfeat = 0x9;
/* support DULBE and I/O optimization fields */
id_ns->nsfeat |= (NVME_ID_NS_NSFEAT_DAE | NVME_ID_NS_NSFEAT_OPTPERF_ALL);
--
2.53.0
next prev parent reply other threads:[~2026-03-26 8:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-26 8:23 [PULL 0/2] hw/nvme fixes Klaus Jensen
2026-03-26 8:23 ` Klaus Jensen [this message]
2026-03-26 8:23 ` [PULL 2/2] hw/nvme: fix heap-buffer-overflow in nvme_abort Klaus Jensen
2026-03-26 14:58 ` [PULL 0/2] hw/nvme fixes Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260326082350.17374-2-its@irrelevant.dk \
--to=its@irrelevant.dk \
--cc=foss@defmacro.it \
--cc=k.jensen@samsung.com \
--cc=kbusch@kernel.org \
--cc=p.raghav@samsung.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox