[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: |
Mon, 5 Dec 2022 13:47:01 +0100 |
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