qemu-devel
[Top][All Lists]
Advanced

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

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


From: Klaus Jensen
Subject: Re: making a qdev bus available from a (non-qtree?) device
Date: Mon, 17 May 2021 08:55:50 +0200

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)?

Thanks for you help!

Attachment: signature.asc
Description: PGP signature


reply via email to

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