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

[Ian Campbell]

On Wed, 2013-06-19 at 11:13 +0100, Paul Durrant wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 19 June 2013 11:08
> > 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: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.
> > > >
> > > > 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.

Pushing this decision onto the users is not the right design IMHO.

> > 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.

Then it'll have to be documentation, "remove these old drivers before
upgrading or enabling Windows update".

Perhaps blacklisting the old drivers via the I/O port protocol might
help, depending on how Windows reacts.

> Is it such a bad idea to be able to support multiple HVM VM
> configurations at the same time?

This isn't a new configuration, it is exactly the same as the old
configuration except it happens to trigger different behaviour in some
particular OSes driver loading code.

Sorry, I don't think this approach is going to fly.

Ian.