Re: making a qdev bus available from a (non-qtree?) device

[Stefan Hajnoczi <stefanha@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3589 bytes --]

On Mon, May 17, 2021 at 08:55:50AM +0200, Klaus Jensen wrote:
> On May 13 15:02, Stefan Hajnoczi wrote:
> > On Wed, May 12, 2021 at 02:02:50PM +0200, Markus Armbruster wrote:
> > > Klaus Jensen <its@irrelevant.dk> writes:
> > > > I can then call `qdev_set_parent_bus()` and set the parent bus to the
> > > > bus creates in the nvme-subsys device. This solves the problem since
> > > > the namespaces are not "garbage collected" when the nvme device is
> > > > removed, but it just feels wrong you know? Also, if possible, I'd of
> > > > course really like to retain the nice entries in `info qtree`.
> > > 
> > > I'm afraid I'm too ignorant on NVME to give useful advice.
> > > 
> > > Can you give us a brief primer on the aspects of physical NVME devices
> > > you'd like to model in QEMU?  What are "controllers", "namespaces", and
> > > "subsystems", and how do they work together?
> > > 
> > > Once we understand the relevant aspects of physical devices, we can
> > > discuss how to best model them in QEMU.
> > 
> > One specific question about the nature of devices vs subsystems vs
> > namespaces:
> > 
> > Does the device expose all the namespaces from one subsystem, or does it
> > need to be able to filter them (e.g. hide certain namespaces or present
> > a mix of namespaces from multiple subsystems)?
> > 
> 
> Subsystems are fully isolated. There are no interaction possible between
> different subsystems. Within a subsystem, all the "resources" (controllers
> and namespaces) are potentially "shared". That is, there may exists
> many-to-many relationships. A controller may have multiple namespaces
> attached and namespaces may be attached to multiple controllers.
> 
> > The status of the namespace as a DeviceState is a bit questionable since
> > the only possible parent it could have is a device, but multiple devices
> > want to use it. I understand why you're considering whether it should be
> > an --object...
> > 
> 
> When you say parent, I think you mean parent in terms of bus-device
> relationship? In that case, then the parent can actually be the subsystem,
> since if the namespace is not attached to any controllers, then it is just
> an entity/object in the subsystem that the controllers (the actual devices)
> may attach to[1].
> 
> Yes, the more I think about this and understand qdev I realize that it was a
> mistake to define nvme-ns to be a TYPE_DEVICE, since it does not act as a
> piece of virtual hardware. It is just an entity (object). The biggest
> mistake right now seems to be the bus_type use. It just worked wonderfully
> in the absence of subsystem support, but I feel that that choice is coming
> back to haunt me now. If we'd used a 'ctrl' link property we could just add
> a 'subsys' link property now and be happy.
> 
> Is there any way that we can "overload" the implicit "bus=" parameter to
> provide backwards compatibility (while basically changing it to function
> like a "link" parameter)?

I would consider adding new --object types and deprecating the devices
so they can be dropped in a future QEMU release. It may be necessary to
choose new names to avoid collisions with the existing ones.

Backwards compatibility might be tricky. One way might be to extract
most of the code from --device nvme-ns and move it into the new
--object, but leave the device to instantiate an object behind the
scenes? Then the device can still have its bus and translate that
relationship to --object somehow. I'm not sure, it depends on the
details of the code.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]