[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





 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.