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

[Dmitry Tihov]

On Fri, Nov 25, 2022 at 08:44:18, Klaus Jensen wrote:
> +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.

You mean API in QEMU block layer right? Specifically the second patch
of this series. Should I send it in a distinct RFC for review by block
layer maintainers?