Re: [PATCH RFC v5 12/12] hw/block/nvme: add persistence for zone info

[Stefan Hajnoczi]

On Fri, Nov 27, 2020 at 12:46:01AM +0100, Klaus Jensen wrote:
> From: Klaus Jensen <k.jensen@samsung.com>
> 
> Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
> ---
>  docs/specs/nvme.txt   |  15 +++
>  hw/block/nvme-ns.h    |  16 ++++
>  hw/block/nvme-ns.c    | 212 +++++++++++++++++++++++++++++++++++++++++-
>  hw/block/nvme.c       |  87 +++++++++++++++++
>  hw/block/trace-events |   2 +
>  5 files changed, 331 insertions(+), 1 deletion(-)
> 
> diff --git a/docs/specs/nvme.txt b/docs/specs/nvme.txt
> index 03bb4d9516b4..05d81c88ad4e 100644
> --- a/docs/specs/nvme.txt
> +++ b/docs/specs/nvme.txt
> @@ -20,6 +20,21 @@ The nvme device (-device nvme) emulates an NVM Express 
> Controller.
>    `zns.mor`; Specifies the number of open resources available. This is a 0s
>       based value.
>  
> +  `zns.pstate`; This parameter specifies another blockdev to be used for
> +     storing zone state persistently.
> +
> +       -drive id=zns-pstate,file=zns-pstate.img,format=raw
> +       -device nvme-ns,zns.pstate=zns-pstate,...
> +
> +     To reset (or initialize) state, the blockdev image should be of zero 
> size:
> +
> +       qemu-img create -f raw zns-pstate.img 0
> +
> +     The image will be intialized with a file format header and truncated to
> +     the required size. If the pstate given is of non-zero size, it will be
> +     assumed to already contain zone state information and the header will be
> +     checked.

In principle this makes sense but at first glance it looks like the code
is synchronous - it blocks the vCPU if zone metadata I/O is necessary.
That works for test/bring-up code but can't be used in production due to
the performance impact.

Is the expectation that the QEMU NVMe device emulation will only be used
for test/bring-up now and in the future?

Stefan

signature.asc
Description: PGP signature