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 > > > > > > > > From: Rafael J. Wysocki <[email protected]> Sent: Wednesday, September > > > > 9, 2026 9:41 AM > > > > > > > > > > The ACPI bus type does not allow drivers to be registered, so the > > > > > sysfs > > > > > attributes related to drivers created for it and its devices are > > > > > useless, and its drivers/ directory is always empty. All of that is > > > > > confusing and wasteful. > > > > > > > > > > To allow skipping the creation of those sysfs attributes, introduce a > > > > > "companion" bus type concept and add a special registration function > > > > > for > > > > > registering "companion" bus types, companion_bus_register(). > > > > > > > > > > Signed-off-by: Rafael J. Wysocki <[email protected]> > > > > > > > > As a heads up, this patch breaks Linux guests booting on Hyper-V. > > > > Something goes wrong in the VMBus driver getting loaded and > > > > initialized (drivers/hv/vmbus_drv.c). It may be that the VMBus > > > > driver is doing something wrong or making an invalid assumption. > > > > I'll debug the problem today or tomorrow, but any insight you can > > > > offer would be appreciated. I'm working with linux-next20260921. > > > > > > 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. > > > > Anyway, it looks like older systemd may be thinking that they are ACPI > > devices and may be looking for drivers in /sys/bus/acpi/drivers/. > > > > To kind of check that this is the case, can you replace "use_drivers" > > with "true" in the first check in bus_register_internal() only (with > > the $subject patch applied, of course)? That would leave the > > "drivers" directory in place, but it would skip the creation of the > > probe files. > > The VM boots properly with that change. Just to confirm, under > /sys/bus/acpi, the "devices" and "drivers" directories are there, > along with "uevent". And of course, "drivers" is empty. But > drivers_autoprobe and drivers_probe are not present. Yes, that's as expected, thanks for checking! I'll send a new version of the $subject patch based on this observation.
