[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: making a qdev bus available from a (non-qtree?) device
From: |
Stefan Hajnoczi |
Subject: |
Re: making a qdev bus available from a (non-qtree?) device |
Date: |
Thu, 13 May 2021 15:02:18 +0100 |
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)?
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...
Stefan
signature.asc
Description: PGP signature