[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-block] [RFC, v1] Namespace Management Support

From: Matt Fitzpatrick
Subject: Re: [Qemu-devel] [Qemu-block] [RFC, v1] Namespace Management Support
Date: Mon, 8 Jul 2019 15:52:29 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

Hey Klaus,

Sorry for the late reply!  I finally found this message amid the pile of emails Qemu dumped on me.

I don't know what the right answer is here... NVMe is designed in a way where you *do* "carve up" the flash into logical groupings and the nvme firmware decides on how that's done. Those logical groupings can be attached to different controllers(which we don't have here yet?) after init, but that's a problem for future us I guess?But that's all stuff you already know.

The "nvme-nvm" solution might be the right approach, but I'm a bit hesitant on the idea of growing tnvmcap...

I can't think of any way to create namespaces on the fly and not have it use some single existing block backend, unless we defined a range of block images on qemu start and namespace create/attach only uses one image up to and including it's max size per namespace? That might work, and I think that's what you suggested (or at least is similar to), though it could be pretty wasteful. It wouldn't offer a "true" namespace management support, but could be close enough.

I'm in the middle of going through the patch you posted. Nice job!  I'm glad to see more people adding enhancements. It was pretty stale for years.

On 7/5/19 12:50 AM, Klaus Birkelund wrote:
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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]