1. Patchew
  2. QEMU
  3. View series

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

Dmitry Tihov posted 5 patches 1 year, 5 months ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20221124155821.1501969-1-d.tihov@yadro.com
Maintainers: Kevin Wolf <kwolf@redhat.com>, Hanna Reitz <hreitz@redhat.com>, Aarushi Mehta <mehta.aaru20@gmail.com>, Julia Suvorova <jusual@redhat.com>, Stefan Hajnoczi <stefanha@redhat.com>, Stefano Garzarella <sgarzare@redhat.com>, Keith Busch <kbusch@kernel.org>, Klaus Jensen <its@irrelevant.dk>
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(-)
[RFC 0/5] Protection information pass-through for block devices
Posted by Dmitry Tihov 1 year, 5 months ago 
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
Re: [RFC 0/5] Protection information pass-through for block devices
Posted by Klaus Jensen 1 year, 5 months ago 
+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.
Re: [RFC 0/5] Protection information pass-through for block devices
Posted by Dmitry Tihov 1 year, 4 months ago 
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?
Re: [RFC 0/5] Protection information pass-through for block devices
Posted by Klaus Jensen 1 year, 4 months ago 
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 :)

Patchew 2.1-devel-0870f84

© 2016 - 2024 Red Hat, Inc.