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

[Klaus Jensen <its@irrelevant.dk>]

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

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]