qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC 0/5] Protection information pass-through for block devices


From: Klaus Jensen
Subject: Re: [RFC 0/5] Protection information pass-through for block devices
Date: Fri, 25 Nov 2022 08:44:18 +0100

+CC: block layer maintainers (Kevin, Hanna)

On Nov 24 18:58, Dmitry Tihov wrote:
> This patch set allows using End-to-End Data Protection in NVMe subsystem
> with integrity capable host devices as the NVMe namespaces backend.
> The patch series is based on io-uring kernel interface feature not merged
> to kernel upstream yet:
> https://lore.kernel.org/linux-block/20220920144618.1111138-1-a.buev@yadro.com/
> 
> The main advantage of this approach is that it allows using the
> same protection information enabled disks in multiple VMs
> concurrently. This may be useful in cluster setups.
> 
> Please let me know what do you think, are this kind of changes appropriate
> for QEMU upstream, what should be changed, etc.
> 
> Dmitry Tihov (5):
>   docs/nvme: add new feature summary
>   block: add transfer of protection information
>   hw/nvme: add protection information pass parameter
>   hw/nvme: implement pi pass read/write/wrz commands
>   hw/nvme: extend pi pass capable commands
> 
>  block/file-posix.c           | 130 ++++++++++++-
>  block/io_uring.c             | 109 ++++++++++-
>  docs/system/devices/nvme.rst |  15 ++
>  hw/nvme/ctrl.c               | 361 ++++++++++++++++++++++++++++++++---
>  hw/nvme/dif.c                | 303 +++++++++++++++++++++++++++++
>  hw/nvme/dif.h                |  18 ++
>  hw/nvme/ns.c                 |  59 +++++-
>  hw/nvme/nvme.h               |   2 +
>  hw/nvme/trace-events         |   6 +
>  include/block/block-common.h |   2 +
>  include/block/raw-aio.h      |   3 +-
>  include/qemu/iov.h           |   6 +
>  util/iov.c                   |  24 +++
>  13 files changed, 992 insertions(+), 46 deletions(-)
> 
> -- 
> 2.38.1
> 

Hi Dmitry,

Neat.

But this is largely depending on how the API turns out in block/ and I
am not the right one to comment on that. It's great that you have an
example device to utilize the API, but this needs comments from the
block layer maintainers before we consider it in hw/nvme.

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]