[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 0/7] Implement forced unplug and forced activation
It may be possible to change the PDO's DeviceID to not include the full XenBus DeviceID, only the VENDOR_PREFIX_STR (to avoid compatibility issues between different vendor driver sets) and the device type.
e.g. DeviceID = "XENBUS\VEN_XP&DEV_VBD"
Keep the CompatibleIDs including the XenBus DeviceID would allow vendors to limit Windows Update distribution to their VENDOR_PREFIX_STR + VENDOR_DEVICE_ID. The INF files would require an exact match against a CompatibleID, which would also include the REV part, preventing child devices installing on parent devices that dont expose the correct interface versions.
Then this change and a combination of ForceActivate and ForceUnplug should cover most edge cases.
Owen
On Thu, Jul 31, 2025 at 4:03 PM Tu Dinh <ngoc-tu.dinh@xxxxxxxxxx> wrote:
On 31/07/2025 16:26, Owen Smith wrote:
> Having played with this a bit, there seems to be several edge cases that
> are fatal.
> 1) installing on 1 device (e.g. 0002) without any others seems to work.
> Shutting down, and changing the device (e.g. to 0001) and booting, will
> trigger an 0x7B bugcheck (emulated disk is unplugged, but the PV disk
> has not bound to the 0001 device nodes)
> 2) installing on 1 device (e.g. 0002), shutting down and adding the
> vendor device will trigger a 0x7B bugcheck on boot (as the emulated disk
> is unplugged, but the driver stack has not reinstalled on the vendor device)
> There may well be more problem cases, but I've not investigated further.
>
> Owen
>
It's something I've been looking at as well.
Basically, when the driver is installed online, it will only populate
the registry keys
HKLM\SYSTEM\DriverDatabase\DriverPackages\xenbus.inf_*\Descriptors\PCI\*
corresponding to the active device.
Once another device is installed, Windows is unable to pick up and
install the driver. So forced unplug/activation and vendor device
binding are incompatible at the moment.
Interestingly, the problem will not exist when the driver is installed
offline via Dism, as it will populate the registry with all the
supported device IDs.
One way to fix this is to (only when forced unplug/activation is set):
- make xenbus.inf bind to PCI\VEN_5853 or something equivalent instead
of a list of branded device IDs;
- for each child PDO, add a compatible ID without the vendor device ID
(e.g. XENBUS\VEN_@VENDOR_PREFIX@&DEV_VBD&REV_0900000B);
- make xenvbd.inf bind to that compatible ID
This should make sure that the full driver chain is available during
boot time, at the cost of potentially breaking Windows Update delivery.
I've tested this on Server 2022 and it seems to work.
Related:
https://community.osr.com/t/hklm-system-driverdatabase-driverpackages-bus-driver-inf-not-properly-configured/52214
Ngoc Tu Dinh | Vates XCP-ng Developer
XCP-ng & Xen Orchestra - Vates solutions
web: https://vates.tech
|
