From: Klaus Birkelund <klaus@birkelund.eu>
To: Matt Fitzpatrick <matt.fitzpatrick@oakgatetech.com>
Cc: keith.busch@intel.com, kwolf@redhat.com, qemu-devel@nongnu.org,
qemu-block@nongnu.org, mreitz@redhat.com
Subject: Re: [Qemu-devel] [Qemu-block] [RFC, v1] Namespace Management Support
Date: Fri, 5 Jul 2019 09:50:00 +0200 [thread overview]
Message-ID: <20190705075000.GA17345@bogfinke> (raw)
In-Reply-To: <8115eb18-38c0-2bd9-b7d7-2d0c96a106e7@oakgatetech.com>
On Tue, Jul 02, 2019 at 10:39:36AM -0700, Matt Fitzpatrick wrote:
> Adding namespace management support to the nvme device. Namespace creation
> requires contiguous block space for a simple method of allocation.
>
> I wrote this a few years ago based on Keith's fork and nvmeqemu fork and
> have recently re-synced with the latest trunk. Some data structures in
> nvme.h are a bit more filled out that strictly necessary as this is also the
> base for sr-iov and IOD patched to be submitted later.
>
Hi Matt,
Nice! I'm always happy when new features for the nvme device is posted!
I'll be happy to review it, but I won't start going through it in
details because I believe the approach to supporting multiple namespaces
is flawed. We had a recent discussion on this and I also got some
unrelated patches rejected due to implementing it similarly by carving
up the image.
I have posted a long series that includes a patch for multiple
namespaces. It is implemented by introducing a fresh `nvme-ns` device
model that represents a namespace and attaches to a bus created by the
parent `nvme` controller device.
The core issue is that a qemu image /should/ be attachable to other
devices (say ide) and not strictly tied to the one device model. Thus,
we cannot just shove a bunch of namespaces into a single image.
But, in light of your patch, I'm not convinced that my implementation is
the correct solution. Maybe the abstraction should not be an `nvme-ns`
device, but a `nvme-nvm` device that when attached changes TNVMCAP and
UNVMCAP? Maybe you have some input for this? Or we could have both and
dynamically create the nvme-ns devices on top of nvme-nvm devices. I
think it would still require a 1-to-1 mapping, but it could be a way to
support the namespace management capability.
Cheers,
Klaus
next prev parent reply other threads:[~2019-07-05 7:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-02 17:39 [Qemu-devel] [RFC,v1] Namespace Management Support Matt Fitzpatrick
2019-07-05 7:50 ` Klaus Birkelund [this message]
2019-07-08 22:52 ` [Qemu-devel] [Qemu-block] [RFC, v1] " Matt Fitzpatrick
2019-07-09 6:45 ` Klaus Birkelund
2019-07-23 21:04 ` [Qemu-devel] [RFC,v1] " Keith Busch
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=20190705075000.GA17345@bogfinke \
--to=klaus@birkelund.eu \
--cc=keith.busch@intel.com \
--cc=kwolf@redhat.com \
--cc=matt.fitzpatrick@oakgatetech.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/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.