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

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

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