[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [XENBUS PATCH v3 2/9] Merge all hardware IDs into one Models entry
On 06/08/2025 10:01, Owen Smith wrote: > The XenVbd changes seem fine, but there is a problem if older xenvbd is > loaded on this xenbus, where the devices do not cope with a change in > the device_id or presence of the vendor device. To work around this, I > had to set xenbus's PDOs DeviceID to exclude the PCI vendor ID (e.g. > "XENBUS\VEN_XP&DEV_VBD") Could you elaborate on the problem? Old xenvbd wouldn't have forced unplug so I figured they wouldn't be affected. Maybe it has something to do with the Active registry value, in which case something like this would help? From 90357f56f2dd99b489bfe04f67dbf219de896894 Mon Sep 17 00:00:00 2001 From: Tu Dinh <ngoc-tu.dinh@xxxxxxxxxx> Date: Sun, 3 Aug 2025 07:11:35 +0200 Subject: [PATCH] Early-set active device during Xenfilt PdoCreate There is a (theoretical) edge case where combining new Xenfilt and old Xenbus (e.g. due to different driver versions between platform and vendor devices) causes Xenbus to fall back to the in-registry Active setting. If this active value does not match that of the force-activated old Xenbus, it will deactivate itself during its own check in FdoSetActive. This will lead to an INACCESSIBLE_BOOT_DEVICE BSOD. Fix this by setting the active value directly during the Xenfilt PDO enumeration phase. Signed-off-by: Tu Dinh <ngoc-tu.dinh@xxxxxxxxxx> --- src/xenfilt/pdo.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/xenfilt/pdo.c b/src/xenfilt/pdo.c index 946c1c5..6c30f06 100644 --- a/src/xenfilt/pdo.c +++ b/src/xenfilt/pdo.c @@ -1753,6 +1753,11 @@ PdoCreate( if (!NT_SUCCESS(status)) goto fail5; + if (ForceActivate > 0) + (VOID) ConfigSetActive(__PdoGetDeviceID(Pdo), + __PdoGetInstanceID(Pdo), + __PdoGetLocationInformation(Pdo)); + if (CompatibleIDs) ExFreePool(CompatibleIDs); -- 2.50.1.windows.1 > > Owen > > > On Wed, Aug 6, 2025 at 8:56 AM Owen Smith <owen.smith@xxxxxxxxx > <mailto:owen.smith@xxxxxxxxx>> wrote: > > > > On Mon, Aug 4, 2025 at 4:35 PM Tu Dinh <ngoc-tu.dinh@xxxxxxxxxx> wrote: > > [Inst.NT@INF_ARCH@] > -; DisplayName Section DeviceID > -; ----------- ------- -------- > - > -%XenBusName_VEND% =XenBus_Inst, > > PCI\VEN_5853&DEV_@VENDOR_DEVICE_ID@&SUBSYS_@VENDOR_DEVICE_ID@5853&REV_01 > -%XenBusName_0002% =XenBus_Inst, PCI\VEN_5853&DEV_0002 > -%XenBusName_0001% =XenBus_Inst, PCI\VEN_5853&DEV_0001 > +%XenBusName%=XenBus_Inst,\ > > > Comma should be on the vendor device ID line, so if VENDOR_DEVICE_ID > is not defined, then the INF section is still valid, although it > 'promotes' 0002 to HWID from CompatID From MS documentation, the INF Models section allows for a blank HWID. So I did that to make sure that the platform IDs remain as compatible IDs in the INF, since I'd prefer to avoid having identifier scores change depending on the build configuration. > > > +PCI\VEN_5853&DEV_@VENDOR_DEVICE_ID@&SUBSYS_@VENDOR_DEVICE_ID@5853&REV_01\ > +,PCI\VEN_5853&DEV_0002\ > +,PCI\VEN_5853&DEV_0001 > > [XenBus_Inst] > CopyFiles=XenBus_CopyFiles > CopyFiles=Monitor_CopyFiles > +FeatureScore=0xFE > > > The main potential issue here is determining if Microsoft / Windows > Update will allow an update distribution to the vendor device ID > without distributing for the compatible IDs, so drivers will only > install via Windows Update on the vendor device, not on others - if > this is not possible, then an alternate method is needed. I've so > far not been able to confirm this either way, but it would appear > that driver distributions are enabled for a specific HWID. I hope that the driver distributions are bound to INF model HWID and not compatible IDs. But I can't test that myself ATM. > > Owen > Ngoc Tu Dinh | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |