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. 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. > 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? If this is done to work around something, there may be a design issue in that driver. Thanks!
