From: Rafael J. Wysocki (Intel) <[email protected]> Sent: Friday, September 25,
2026 2:08 AM
>
> On Thu, Sep 24, 2026 at 11:47 PM Michael Kelley <[email protected]> wrote:
> >
> > From: Rafael J. Wysocki (Intel) <[email protected]> Sent: Thursday,
> > September 24, 2026 11:45 AM
> > >
> > > On Thu, Sep 24, 2026 at 8:23 PM Michael Kelley <[email protected]>
> > > wrote:
> > > >
> > > > From: Michael Kelley <[email protected]> Sent: Wednesday, September
> > > > 23, 2026 10:06 AM
> > > >
> > > > Here's what I've learned so far:
> > > >
> > > > 1) The problem is apparently due to systemd-udevd being unable
> > > > to load modules with the VMBus bus driver or any of the
> > > > individual drivers for VMBus devices.
> > > >
> > > > 2) I'm testing on Ubuntu 20.04 with systemd version 245. The
> > > > problem reproduces on a different 20.04 instance. But everything
> > > > works correctly on Ubuntu 24.04 with systemd version 255.
> > > >
> > > > 3) If the VMBus bus driver and key VMBus device drivers are
> > > > compiled as built-in instead of as modules, the Ubuntu 20.04 system
> > > > will boot.
> > > >
> > > > 4) If I keep your patch, but change companion_bus_register() to
> > > > pass "true" as the second argument instead of "false", then the
> > > > /sys/bus/acpi/drivers directory is created as before, and everything
> > > > works. Also, only adding back the .match function as you suggested
> > > > does not make any difference.
> > > >
> > > > 5) The VMBus bus is enumerated in the ACPI DSDT. The individual
> > > > synthetic devices that are logically on VMBus are not -- they are
> > > > "offered" by Hyper-V to the guest at runtime via a custom protocol.
> > > > The synthetic devices end up with paths like:
> > > >
> > > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0004:00/MSFT1000:00/<some GUID>
> > >
> > > Which is rather unfortunate.
> > >
> > > They should appear under the MSFT1000:00 platform device corresponding
> > > to the ACPI device with the same name.
> >
> > Hmmm. In the path above MSFT1000:00 is the VMBus bus device from
> > the DSDT. Its "path" value is "\_SB_.VMOD.VMBS", which matches the
> > DSDT.
> >
> > Under /sys/devices/platform, there is no entry for MSFT1000:00.
>
> /sys/devices/platform/ contains platform devices that were created
> without parents. MSFT1000:00 has a parent, so it is not there.
>
> > And under /sys/bus/platform/devices, MSFT1000:00 is a symlink to
> >
> > ../../../devices/system/container/ACPI0004:00/MSFT1000:00
> >
> > Can you provide any more detail on how this should be? And am I
> > correct that these paths are governed by the parent relationships
> > of the "struct device"s?
>
> Yes, you are, and this is the platform device I'm talking about. The
> firmware_node symbolic link under it should point to
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0004:00/MSFT1000:00/.
>
> The idea is that the objects under /sys/devices/LNXSYSTM:00/
> correspond to nodes in the ACPI namespace and they may or may not
> correspond to physical pieces of hardware. They are referred to as
> "ACPI devices", but in fact they represent platform firmware
> interfaces that can be associated with devices - that's where the
> firmware_node and physical_node symlinks come into play.
>
> Accordingly, adding children that do not correspond to nodes in the
> ACPI namespace is confusing and generally questionable. Children
> should be added under devices pointed to by their physical_node
> symlinks.
>
To follow up on your observations about the parenting of the
VMBus synthetic devices, it's a relatively easy fix to parent them
to the VMBus platform device. Then they appear as:
/sys/devices/system/container/ACPI0004:00/MSFT1000:00/<some GUID>
/sys/devices/platform still does *not* contain MSFT1000:00. I read
your previous comment to mean that this is correct since
MSFT1000:00 has a parent.
/sys/bus/platform/devices/MSFT1000:00 is a symlink to
../../../devices/system/container/ACPI0004:00/MSFT1000:00, just
as before. And this is also presumably correct.
FWIW, even with these devices correctly parented, removing
/sys/bus/acpi/drivers still causes system-udevd v245 to not load
the driver modules. All along, there has been this error message:
Failed to scan subsystems: No such file or directory
that I can now attribute to system-udevd, based on looking
at its source code. The code is a bit hard to understand in a
quick perusal, but presumably "No such file or directory" is
referring to /sys/bus/acpi/drivers.
Finally, vmbus_acpi_add() doing
ACPI_COMPANION_SET(&device->dev, device);
is intentional and needed in a perverse sort of way when
VMBus's main identity is its ACPI device instead of its
platform device. It's needed to make device_get_dma_attr()
work, as it finds the ACPI companion of its argument.
When the ACPI device itself passed as the argument to
device_get_dma_attr(), the loopback makes it properly
get the DMA coherence attribute specified for VMBus in
the DSDT. But if the VMBus driver instead uses the platform
device as the main identity for VMBus, the loopback
behavior is no longer needed.
I intend to submit a patch to make the parenting change,
and remove the ACPI_COMPANION_SET(). But before doing
so, I need to work out a parenting issue in the Hyper-V virtual
PCI driver.
Question: Do you have knowledge of any user space
utilities that might break if the VMBus synthetic devices
are now at a different path under /sys? I don't know what
utilities might be reading this stuff. There are Hyper-V
specific utilities, but everything they look at is under
/sys/bus/vmbus, and its structure isn't changing (though
the synthetic device symlinks correctly point to the new
location).
I appreciate your help and consultation. I've learned
something. :-)
Michael
