Paul Durrant
2013-Jun-19 11:31 UTC
Re: [Qemu-devel] [PATCH] Add Xen platform PCI device version 2.
> -----Original Message----- > From: qemu-devel-bounces+paul.durrant=citrix.com@nongnu.org > [mailto:qemu-devel-bounces+paul.durrant=citrix.com@nongnu.org] On > Behalf Of Tim Deegan > Sent: 19 June 2013 11:36 > To: Ian Campbell > Cc: Paul Durrant; qemu-devel@nongnu.org; xen-devel@lists.xen.org > 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: qemu-devel@nongnu.org; xen-devel@lists.xen.org > > > > 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