Hi all,
I'm thinking about how to support multiple namespaces in the NVMe
device. My first idea was to add a "namespaces" property array to the
device that references blockdevs, but as Laszlo writes below, this might
not be the best idea. It also makes it troublesome to add per-namespace
parameters (which is something I will be required to do for other
reasons). Some of you might remember my first attempt at this that
included adding a new block driver (derived from raw) that could be
given certain parameters that would then be stored in the image. But I
understand that this is a no-go, and I can see why.
I guess the optimal way would be such that the parameters was something
like:
-blockdev raw,node-name=blk_ns1,file.driver=file,file.filename=blk_ns1.img
-blockdev raw,node-name=blk_ns2,file.driver=file,file.filename=blk_ns2.img
-device nvme-ns,drive=blk_ns1,ns-specific-options (nsfeat,mc,dlfeat)...
-device nvme-ns,drive=blk_ns2,...
-device nvme,...
My question is how to state the parent/child relationship between the
nvme and nvme-ns devices. I've been looking at how ide and virtio does
this, and maybe a "bus" is the right way to go?
Can anyone give any advice as to how to proceed? I have a functioning
patch that adds multiple namespaces, but it uses the "namespaces" array
method and I don't think that is the right approach.
I've copied my initial discussion with Laszlo below.
Cheers,
Klaus
On Wed, Jun 05, 2019 at 07:09:43PM +0200, Laszlo Ersek wrote:
> On 06/05/19 15:44, Klaus Birkelund wrote:
> > On Tue, Jun 04, 2019 at 06:52:38PM +0200, Laszlo Ersek wrote:
> >> Hi Klaus,
> >>
> >> On 06/04/19 14:59, Klaus Birkelund wrote:
> >>> Hi Laszlo,
> >>>
> >>> I'm implementing multiple namespace support for the NVMe device in QEMU
> >>> and I'm not sure how to handle the bootindex property.
> >>>
> >>> Your commit message from a907ec52cc1a provides great insight, but do you
> >>> have any recommendations to how the bootindex property should be
> >>> handled?
> >>>
> >>> Multiple namespaces work by having multiple -blockdevs and then using
> >>> the property array functionality to reference a list of blockdevs from
> >>> the nvme device:
> >>>
> >>> -device nvme,serial=<serial>,len-namespaces=1,namespace[0]=<drive_id>
> >>>
> >>> A bootindex property would be global to the device. Should it just
> >>> always default to the first namespace? I'm really unsure about how the
> >>> firmware handles it.
> >>>
> >>> Hope you can shed some light on this.
> >>
> >> this is getting quite seriously into QOM and QEMU options, so I
> >> definitely suggest to take this to the list, because I'm not an expert
> >> in all that, at all :)
> >>
> >> Based on a re-reading of the commit (which I have *completely* forgotten
> >> about by now!), and based on your description, my opinion is that
> >> introducing the "namespace" property to the "nvme" device as an array is
> >> a bad fit. Because, as you say, a single device may only take a single
> >> bootindex property. If it suffices to designate at most one namespace
> >> for booting purposes, then I *guess* an extra property can be
> >> introduced, to state *which* namespace the bootindex property should
> >> apply to (and the rest of the namespaces will be ignored for that
> >> purpose). However, if it's necessary to add at least two namespaces to
> >> the boot order, then the namespaces will have to be split to distinct
> >> "-device" options.
> >>
> >> My impression is that the "namespace" property isn't upstream yet; i.e.
> >> it is your work in progress. As a "QOM noob" I would suggest introducing
> >> a new device model, called "nvme-namespace". This could have its own
> >> "bootindex" property. On the "nvme" device model's level, the currently
> >> existing "bootindex" property would become mutually exclusive with the
> >> "nvme" device having "nvme-namespace" child devices. The parent-child
> >> relationship could be expressed from either direction, i.e. either the
> >> "nvme" parent device could reference the children with the "namespace"
> >> array property (it wouldn't refer to <drive_id>s but to the IDs of
> >> "nvme-namespace" devices), or the "nvme-namespace" devices could
> >> reference the parent "nvme" device via a "bus" property or similar.
> >>
> >> The idea is that "bootindex" would have to exist at the nvme-namespace
> >> device model's level, and a parent ("bus") device would have to enforce
> >> various properties, such as no namespace ID duplication and so on.
> >>
> >> I suggest that, if/when you respond to this email, keep all context, and
> >> CC the qemu-devel list at once. (I could have done that myself right
> >> now, but didn't want to, without your permission.)
> >>
> >
> > Hi Laszlo,
> >
> > Thank you very much for the feedback!
> >
> > I have a big patch series for the nvme device which the multiple
> > namespace patch builds on. I'll post the big series tomorrow I hope.
> > Then I'll post the multiple namespaces patch as an RFC and include our
> > discussion here.
> >
> > I hadn't thought about introducing a separate device model for the
> > namespace. It's way beyond my QOM knowledge, so yeah, hopefully someone
> > on the list have some opinions on this.
> >
> >
> > Thanks again!
>
> My pleasure! I'll attempt to follow the discussion (from a safe distance
> :) ) because I'm curious about the proper device model hierarchy here.
>
> Regarding OVMF, as long as your QEMU work keeps the *structure* of the
> OpenFirmware device paths intact (and you just compose the NSID and
> EUI-64 values dynamically, in the trailing "unit address" part), OVMF
> should need no change.
>
> Thanks!
> Laszlo
