Re: [XENBUS PATCH v3 2/9] Merge all hardware IDs into one Models entry

["Tu Dinh" <ngoc-tu.dinh@xxxxxxxxxx>]

On 06/08/2025 17:11, Owen Smith wrote:
> This was forced activation, as I used unchanged xenvbd builds (I missed
> the patch you'd submitted for this test).
> With a vendor device and xen platform device present, the order in which
> these are installed mattered. Installing xenbus on the xen platform
> device (0002) first means the PDOs are enumerated from the xen platform
> device, and xenvbd will bind to the 0002 DeviceID variants. The 0002
> device will be active until the reboot, where force activation takes
> over and makes the Vendor Device active, enumerating new child nodes
> that have not got xenvbd installed. Force unplug was not an issue (as I
> forgot to set the values), but the standard unplug mechanism triggered
> an unplug, but xenvbd did not load in time to avoid a 0x7B.
>
> With the DeviceID change, both 0002 xenbus and VendorID xenbus enumerate
> the same child nodes, so xenvbd is correctly installed at boot time.
>
> I think the xenbus PDO DeviceID change is needed to allow older drivers
> to load, and the single line INF binding in xenvbd.inf can simplify this
> going forwards.
>
> Owen

Thanks, I've tested the DeviceID fix, which works well. I'll add it to v4.

>
>
> On Wed, Aug 6, 2025 at 3:24 PM Tu Dinh <ngoc-tu.dinh@xxxxxxxxxx> wrote:
>
>     On 06/08/2025 15:29, Owen Smith wrote:
>      >
>      >
>      > On Wed, Aug 6, 2025 at 1:27 PM Tu Dinh <ngoc-tu.dinh@xxxxxxxxxx>
>     wrote:
>      >
>      >     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?
>      >
>      >
>      > Using old xenvbd, no force unplug value was set, but the standard
>     unplug
>      > key was set. When the VM was shut down, device_id changed, and
>     restarted,
>      > the unplug still occurred, but the xenvbd driver was not installed on
>      > the new xenbus device_id and could not be installed from the
>     driver store
>      > during boot.
>      > Using this scheme in xenvif would also be advantageous, as it
>     would mean
>      > xennet devices are not reinstalled when reparenting xenbus. If
>     xennet doesnt
>      > reinstall, then Windows does not create a new network connection,
>     which
>      > defaults to DHCP, improving user experience when a static IP or
>     similar
>      > settings have been applied.
>
>     So it sounds like it's rather forced activation that ended up breaking
>     old xenvbd. I can integrate the DeviceID change, but I don't see how it
>     would fix old xenvbd as they'll be stuck with the old binding list of
>     XENBUS\VEN_XXyyyy&DEV_VBD anyway, and any xenvbd released afterwards
>     (forced unplug or not) may as well use the single-line INF binding.
>     Perhaps forced-activation xenbus could cut off PDO revisions below
>     0900000C via #ifdef, then any xenvbd which can't cope with the change
>     simply won't be loaded?
>
>      >
>      >      >
>      >      >     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.
>      >
>      >
>      > That makes sense.
>      >
>      > Owen
>
>
>
>     Ngoc Tu Dinh | Vates XCP-ng Developer
>
>     XCP-ng & Xen Orchestra - Vates solutions
>
>     web: https://vates.tech <https://vates.tech>
>
>



Ngoc Tu Dinh | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech