Re: [PATCH 2/3] hw/nvme: fix fdp reclaim unit accounting

[Jesper Wendel Devantier <foss@defmacro.it>]

On Thu, 12 Nov 2026 10:53:29 +0100, Klaus Jensen <its@irrelevant.dk> wrote:
> From: Klaus Jensen <k.jensen@samsung.com>
>
> nvme_do_write_fdp falls back to placement handle zero for a write that
> has no Data Placement directive or where the placement identifier is
> invalid. However, it then passes the invalid placement identifier to
> nvme_update_ruh which results in no update to RUAMW for placement handle
> zero.
>
> Reset the placement identifier along with the handle in the fallback.
>
> Link: https://gitlab.com/qemu-project/qemu/-/work_items/4520
> Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
> ---
>  hw/nvme/ctrl.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/hw/nvme/ctrl.c b/hw/nvme/ctrl.c
> index 685cbc2f340c..a0d22dacedfa 100644
> --- a/hw/nvme/ctrl.c
> +++ b/hw/nvme/ctrl.c
> @@ -3754,6 +3754,7 @@ static void nvme_do_write_fdp(NvmeCtrl *n, NvmeRequest *req, uint64_t slba,
>          !nvme_parse_pid(ns, pid, &ph, &rg)) {
>          ph = 0;
>          rg = 0;
> +        pid = 0;
>      }
>  
>      ruhid = ns->fdp.phs[ph];
>
> -- 
> 2.53.0
>
>
>

Correct.
Had to re-familiarize myself, but pid (placement identifier) is essentially
a 2-tuple of (rg, ph)  (reclaim group, placement handle).

NVMe Base Specification 2.4, §8.1.12.1 states that if the data placement directive
is unset/invalid that the write must then use the placement handle 0, but that
the reclaim group may be defined by the controller.

Setting `pid=0` is correct, but only so long as we also set rg to 0.
Perhaps a clearer way to specify this would be:

```
pid = 0;
nvme_parse_pid(ns, pid, &ph, &rg);
```

.. it more clearly captures the relationship between PID and RG/PH.
But the change is correct.

Reviewed-by: Jesper Wendel Devantier <foss@defmacro.it>