From: Joshua Lant <joshualant@gmail.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: linux-cxl@vger.kernel.org, qemu-devel@nongnu.org,
Jonathan.Cameron@huawei.com, arpit1.kumar@samsung.com
Subject: Re: [RFC QEMU PATCH 02/10] qdev/qbus: Allow hidden devices to be busless on QEMU startup
Date: Thu, 21 May 2026 11:23:27 +0100 [thread overview]
Message-ID: <ag7dHwNXS/qGnEJD@thinkpc> (raw)
In-Reply-To: <ag7XkPS0ylFSeIGO@thinkpc>
> > On Wed, 29 Apr 2026 14:48:36 +0100
> > Joshua Lant <joshualant@gmail.com> wrote:
> >
> > > Extend the capability for hiding devices, introduced for virtio-net
> > > device in:
> > >
> > > commit f3a8505656935cde32e28c1c6317f725084da1e0
> > > Author: Jens Freimann <jfreimann@redhat.com>
> > > Date: Tue Oct 29 12:48:55 2019 +0100
> > > qdev/qbus: add hidden device support
> > >
> > > Currently only endpoint devices can be hidden with a primary device
> > > and failover (known static configuration). However, looking at future
> > > composable systems, we see a need for hidden devices which have no associated
> > > bus upon boot. Move the check for hidden devices to before the bus
> > > search, and if it is hidden ignore the case where the device was
> > > described on the CLI without the "bus=" field.
> > >
> > > This is motivated by a specific use-case: implementing the VCS
> > > command set, part of the CXL specification (CXL r3.2 Section 7.1.3). In
> > > this scenario a switch controlled by a Fabric Manager is able to change the
> > > virtual hierarchy of devices seen by a guest within a fixed physical system
> > > topology. The connecting bus is not known until runtime when
> > > a bind command is issued by the Fabric Manager.
> >
> > So this comes back to the earlier comment on whether they are completely
> > hidden from a guest. They aren't quite - we need to be able to
> > get to them via the MCTP or cxl-switch-cci (in band mailbox) paths.
> >
> > Maybe we can solve that later without any compatibility problems
> > or by cheating and just searching hidden devices. I'm not sure.
>
> Funnily enough I had something like this when I was originally writing
> this series. I scrapped it becasue I ran into issues. I was storing
> as a tree the QDicts of hidden busses and devices below them, but then realised
> I couldnt hotplug into the USP and abandoned it. I was doing this with the
> aim of eventual support for cascaded switches.
>
> There was another issue I cant fully remember... That the searching was easy
> when it was referring to unrealized devices with QDicts from the CLI, but it
> became much more difficult to get proper reference to some structures I needed
> from the devices inside the qdev/qbus code when they were realized...
>
I just remembered... I was having to introduce cxl specific code into the qdev
code... I'm sure it could be separated but would require a fair bit more work.
> > >
> > > Signed-off-by: Joshua Lant <joshualant@gmail.com>
> > > ---
> > > system/qdev-monitor.c | 10 ++++++++--
> > > 1 file changed, 8 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/system/qdev-monitor.c b/system/qdev-monitor.c
> > > index f2aa400a77..b51dfe0645 100644
> > > --- a/system/qdev-monitor.c
> > > +++ b/system/qdev-monitor.c
> > > @@ -650,6 +650,7 @@ DeviceState *qdev_device_add_from_qdict(const QDict *opts,
> > > DeviceState *dev;
> > > BusState *bus = NULL;
> > > QDict *properties;
> > > + bool hide_device;
> > >
> > > driver = qdict_get_try_str(opts, "driver");
> > > if (!driver) {
> > > @@ -663,6 +664,11 @@ DeviceState *qdev_device_add_from_qdict(const QDict *opts,
> > > return NULL;
> > > }
> > >
> > > + /* Is the device hidden from the guest?
> > > + * If yes, no need to find a default bus if none given...
> > > + * Bus could be provided at runtime (i.e. in a switch)*/
> > > + hide_device = qdev_should_hide_device(opts, from_json, errp);
> > > +
> > > /* find bus */
> > > path = qdict_get_try_str(opts, "bus");
> > > if (path != NULL) {
> > > @@ -675,14 +681,14 @@ DeviceState *qdev_device_add_from_qdict(const QDict *opts,
> > > driver, object_get_typename(OBJECT(bus)));
> > > return NULL;
> > > }
> > > - } else if (dc->bus_type != NULL) {
> > > + } else if (dc->bus_type != NULL && !hide_device) {
> > > bus = qdev_find_default_bus(dc, errp);
> > > if (!bus) {
> > > return NULL;
> > > }
> > > }
> > >
> > > - if (qdev_should_hide_device(opts, from_json, errp)) {
> > > + if (hide_device) {
> > > if (bus && !qbus_is_hotpluggable(bus)) {
> > > error_setg(errp, "Bus '%s' does not support hotplugging",
> > > bus->name);
> >
next prev parent reply other threads:[~2026-05-21 10:23 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-29 13:48 [RFC QEMU PATCH 00/10] Initial Support for VCS Switching Joshua Lant
2026-04-29 13:48 ` [RFC QEMU PATCH 01/10] docs: Add documentation for cxl-vcs-switch Joshua Lant
2026-05-19 14:33 ` Jonathan Cameron
2026-05-21 9:42 ` Joshua Lant
2026-04-29 13:48 ` [RFC QEMU PATCH 02/10] qdev/qbus: Allow hidden devices to be busless on QEMU startup Joshua Lant
2026-05-20 10:02 ` Jonathan Cameron
2026-05-21 9:59 ` Joshua Lant
2026-05-21 10:23 ` Joshua Lant [this message]
2026-04-29 13:48 ` [RFC QEMU PATCH 03/10] cxl-type3: Properly unmap the memory-backend on device exit Joshua Lant
2026-05-19 15:01 ` Jonathan Cameron
2026-04-29 13:48 ` [RFC QEMU PATCH 04/10] cxl_downstream: enable power controller present capability Joshua Lant
2026-05-19 15:03 ` Jonathan Cameron
2026-04-29 13:48 ` [RFC QEMU PATCH 05/10] cxl-vcs-switch: Initial support for CXL VCS Joshua Lant
2026-05-19 15:19 ` Jonathan Cameron
2026-04-29 13:48 ` [RFC QEMU PATCH 06/10] cxl-upstream-port: Add support for targeting a VCS switch Joshua Lant
2026-04-29 13:48 ` [RFC QEMU PATCH 07/10] cxl-downstream-port: Add support for VCS switching Joshua Lant
2026-04-29 13:48 ` [RFC QEMU PATCH 08/10] cxl-cci-mailbox: Add support for targeting a VCS switch Joshua Lant
2026-04-29 13:48 ` [RFC QEMU PATCH 09/10] cxl-mailbox-utils: Add support for VCS bind/unbind commands Joshua Lant
2026-04-29 13:48 ` [RFC QEMU PATCH 10/10] cxl-mailbox-utils: Add support for VCS Get Virtual CXL Switch Info command Joshua Lant
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ag7dHwNXS/qGnEJD@thinkpc \
--to=joshualant@gmail.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=arpit1.kumar@samsung.com \
--cc=jic23@kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.