qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paul Durrant
Subject: Re: [Qemu-devel] [Xen-devel] [PATCH] Add Xen platform PCI device version 2.
Date: Wed, 19 Jun 2013 10:13:17 +0000

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

> 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]