Xen devel - Jun 2013 - Re: [Qemu-devel] [PATCH] Add Xen platform PCI device version 2.

On Wed, 2013-06-19 at 12:31 +0100, Paul Durrant wrote:
> That''s correct. If a vendor wishes to ship a new driver for an
> existing piece of h/w they just post it. However, at some point the
> vendor will sell a new piece of h/w which requires a driver that will
> not work with older h/w. So, they update their device id or revision
> to something new, leave the old driver on windows update alone, and
> post a new driver that will only bind to the new h/w.
Right, but that is not analogous to this change. This change is more
akin to the driver folks going to the hardware guys and saying
"we''ve
ended up painted into a bit of corner, the easiest way to get out of it
is for you guys to reissue the exact same hardware (ASIC?) with a
different device id". I can imagine the hardware guys would be thrilled
with that prospect!
> This is model we have followed in XenServer: the platform device
> represents ''the set of PV drivers''
You may have followed that model in XenServer but it has never been the
case for upstream. The platform device simply provides an end point for
enabling/triggering baseline Xen detection/support. The "set of PV
drivers" (in so far as such a thing even exists in the mix and match
world of upstream Xen) is represented via the xenbus entries for the
devices and the associated feature flags and the like.
>  and therefore to ship a new and non-backwards-compatible set of PV
> drivers we incremented the platform device id. That fits with the way
> that Windows update works and seems like a totally reasonable way to
> think of the platform device IMO. Clearly my opinion, and the reality
> of Windows Update, are somewhat contentious :-(
What''s contentious IMHO is adding hacks to the Xen (or qemu) code base
to workaround an issue which is entirely internal to the guest Windows
update/driver bindings.

Ian.