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. 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? > > 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. > > > My conclusion is that for some reason, the older system-udevd has > > a dependency on the /sys/bus/acpi/drivers directory being present. > > This isn't a kernel problem per se, but there's an implicit ABI of sorts > > that assumes the existence of the "drivers" directory. > > > > To confirm all this more precisely, I'm trying to find a clever way > > to get an strace of systemd-udevd when it errors out due to the > > missing "drivers" directory, and somehow relate that back to the > > git history of systemd-udevd. > > > > Thoughts? > > Well, the fact of life is that it can't cope with the changes made by > the $subject patch, but maybe we can get away with a simpler one, so > please check the above. > > I'll drop the $subject patch from linux-next at least for now. > > BTW, do you know why vmbus_acpi_add() does this: > > ACPI_COMPANION_SET(&device->dev, device); > > which essentially attempts to make an ACPI device become an ACPI > companion of itself and is useless and broken? Indeed, that looks useless and broken. I need to go study the history. I added that line originally when making sure the ACPI _CCA setting in the VMBus entry of the DSDT was propagated to the synthetic devices on the VMBus. But that was before the VMBus driver was modified to model it as a platform device. Thanks for pointing that out, and I'll follow up. Michael
