> -----Original Message----- > From: Ian Campbell > Sent: 19 June 2013 11:08 > To: Paul Durrant > Cc: qemu-devel@nongnu.org; xen-de...@lists.xen.org > Subject: Re: [Xen-devel] [PATCH] Add Xen platform PCI device version 2. > > 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-de...@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. > > > > > > What is the difference between these two devices? > > > > > > > As the comment implies, the device_id (2 rather than 1) and the revision (2 > rather than 1). > > So what is the point of it? > > Changing these IDs won't work for any other existing PV drivers, it will > break the Linux PVHVM ones and the BSD ones etc. > > 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". >
Why not? The device can be chosen on a per-VM basis. > It sounds to me as if this is a hack to workaround some shortcoming of > the Windows driver model. If this is the case then I'm afraid you are > going to have to find a way to deal with this from within Windows and/or > your drivers. Failing that then I think you'll just have to document an > upgrade path for the users of your older drivers. Pushing the pain onto > the entire world is just not the right way to go about this. > After many months of worrying about this I had to conclude that there really is no way round this. If we bind newer drivers to the old device id and then hope to push them to Windows Update; much chaos, pain and anguish would occur. The only option is a new device. Is it such a bad idea to be able to support multiple HVM VM configurations at the same time? Paul