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

[Klaus Jensen]

On Dec  5 12:01, Dmitry Tihov wrote:
> 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?
> 

Yes, basically the block/ stuff.

Given the RFC status of this series, I see no problem in keeping it
as-is. Having it showing how it is potentially used in a device is good.

I CC'ed the block maintainers to let them comment on it when they have
time. We are right up on a release, so expect some feedback as we start
the next development cycle post-release :)

signature.asc
Description: PGP signature