Xen project Mailing List

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

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

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