|
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!
signature.asc
Description: PGP signature
[Prev in Thread] | Current Thread | [Next in Thread] |