|
[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 |