All of lore.kernel.org
 help / color / mirror / Atom feed
From: Klaus Jensen <its@irrelevant.dk>
To: qemu-devel@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>, Fam Zheng <fam@euphon.net>,
	qemu-block@nongnu.org, Klaus Jensen <k.jensen@samsung.com>,
	Gollu Appalanaidu <anaidu.gollu@samsung.com>,
	Max Reitz <mreitz@redhat.com>, Klaus Jensen <its@irrelevant.dk>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Keith Busch <kbusch@kernel.org>
Subject: [PATCH RFC v2 0/8] hw/block/nvme: metadata and end-to-end data protection support
Date: Sun,  7 Feb 2021 22:49:32 +0100	[thread overview]
Message-ID: <20210207214940.281889-1-its@irrelevant.dk> (raw)

From: Klaus Jensen <k.jensen@samsung.com>

This is RFC v2 of a series that adds support for metadata and end-to-end
data protection.

First, on the subject of metadata, in v1, support was restricted to
extended logical blocks, which was pretty trivial to implement, but
required special initialization and broke DULBE. In v2, metadata is
always stored continuously at the end of the underlying block device.
This has the advantage of not breaking DULBE since the data blocks
remains aligned and allows bdrv_block_status to be used to determinate
allocation status. It comes at the expense of complicating the extended
LBA emulation, but on the other hand it also gains support for metadata
transfered as a separate buffer.

The end-to-end data protection support blew up in terms of required
changes. This is due to the fact that a bunch of new commands has been
added to the device since v1 (zone append, compare, copy), and they all
require various special handling for protection information. If
potential reviewers would like it split up into multiple patches, each
adding pi support to one command, shout out.

The core of the series (metadata and eedp) is preceeded by a set of
patches that refactors mapping (yes, again) and tries to deal with the
qsg/iov duality mess (maybe also again?).

Support fro metadata and end-to-end data protection is all joint work
with Gollu Appalanaidu.

Klaus Jensen (8):
  hw/block/nvme: remove redundant len member in compare context
  hw/block/nvme: remove block accounting for write zeroes
  hw/block/nvme: fix strerror printing
  hw/block/nvme: try to deal with the iov/qsg duality
  hw/block/nvme: remove the req dependency in map functions
  hw/block/nvme: refactor nvme_dma
  hw/block/nvme: add metadata support
  hw/block/nvme: end-to-end data protection

 hw/block/nvme-ns.h    |   41 +-
 hw/block/nvme.h       |   44 +-
 include/block/nvme.h  |   26 +-
 hw/block/nvme-ns.c    |   29 +-
 hw/block/nvme.c       | 1687 +++++++++++++++++++++++++++++++++++------
 hw/block/trace-events |   19 +-
 6 files changed, 1574 insertions(+), 272 deletions(-)

-- 
2.30.0



             reply	other threads:[~2021-02-07 22:01 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-07 21:49 Klaus Jensen [this message]
2021-02-07 21:49 ` [PATCH RFC v2 1/8] hw/block/nvme: remove redundant len member in compare context Klaus Jensen
2021-02-08 15:07   ` Minwoo Im
2021-02-07 21:49 ` [PATCH RFC v2 2/8] hw/block/nvme: remove block accounting for write zeroes Klaus Jensen
2021-02-08 15:07   ` Minwoo Im
2021-02-07 21:49 ` [PATCH RFC v2 3/8] hw/block/nvme: fix strerror printing Klaus Jensen
2021-02-08 15:13   ` Minwoo Im
2021-02-07 21:49 ` [PATCH RFC v2 4/8] hw/block/nvme: try to deal with the iov/qsg duality Klaus Jensen
2021-02-08 15:45   ` Keith Busch
2021-02-08 15:47     ` Klaus Jensen
2021-02-07 21:49 ` [PATCH RFC v2 5/8] hw/block/nvme: remove the req dependency in map functions Klaus Jensen
2021-02-07 21:49 ` [PATCH RFC v2 6/8] hw/block/nvme: refactor nvme_dma Klaus Jensen
2021-02-07 21:49 ` [PATCH RFC v2 7/8] hw/block/nvme: add metadata support Klaus Jensen
2021-02-07 21:49 ` [PATCH RFC v2 8/8] hw/block/nvme: end-to-end data protection Klaus Jensen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210207214940.281889-1-its@irrelevant.dk \
    --to=its@irrelevant.dk \
    --cc=anaidu.gollu@samsung.com \
    --cc=fam@euphon.net \
    --cc=k.jensen@samsung.com \
    --cc=kbusch@kernel.org \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.