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

[Paul Durrant]

> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden On
> Behalf Of Tim Deegan
> Sent: 19 June 2013 11:36
> To: Ian Campbell
> Cc: Paul Durrant; address@hidden; address@hidden
> Subject: Re: [Qemu-devel] [Xen-devel] [PATCH] Add Xen platform PCI device
> version 2.
> 
> At 11:07 +0100 on 19 Jun (1371640052), Ian Campbell wrote:
> > On Wed, 2013-06-19 at 10:43 +0100, Paul Durrant wrote:
> > > > -----Original Message-----
> > > > From: Ian Campbell
> > > > Sent: 19 June 2013 10:42
> > > > To: Paul Durrant
> > > > Cc: address@hidden; address@hidden
> > > > Subject: Re: [Xen-devel] [PATCH] Add Xen platform PCI device version
> 2.
> > > >
> > > > On Wed, 2013-06-19 at 10:32 +0100, Paul Durrant wrote:
> > > > > The XenServer 6.1+ Citrix Windows PV bus driver binds to a new
> version
> > > > > of the Xen platform device (since the newer driver set cannot co-exist
> > > > > with previous drivers which bind to the existing "xen-platform" type
> of
> > > > > device). This patch introduces a new "xen-platform-2" device type
> with
> > > > > the appropriate device_id and revision.
> >
> > We obviously can't say to users "Are you running Windows and are you
> > running PV drivers >= X.Y, if so set lever A to position B, otherwise if
> > you are running some other OS or an earlier version of the Windows PV
> > driver set it to position A".
> 
> Agreed - that's a horrible interface, and an egregious layer violation.
> The VM's admin should be able to install/upgrade software without
> involving the host admin.
> 
> Can you explain a bit more about why this is needed?  Presumably 'real'
> device manufacturers can ship new versions of their drivers through
> Windows Update without needing to rev their hardware or get the user to
> change BIOS settings.
> 

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.
This is model we have followed in XenServer: the platform device represents 
'the set of PV drivers' 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 :-(

  Paul