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.b...@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