Re: [Xen-devel] [PATCH] Citrix PV Bus device

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Ian Campbell
> Sent: 02 July 2013 13:44
> To: Paul Durrant
> Cc: Tim (Xen.org); qemu-devel@xxxxxxxxxx; xen-devel@xxxxxxxxxxxxx
> Subject: Re: [Xen-devel] [PATCH] Citrix PV Bus device
> 
> On Tue, 2013-07-02 at 13:35 +0100, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Ian Campbell
> > > Sent: 02 July 2013 11:57
> > > To: Tim (Xen.org)
> > > Cc: Paul Durrant; qemu-devel@xxxxxxxxxx; xen-devel@xxxxxxxxxxxxx
> > > Subject: Re: [Xen-devel] [PATCH] Citrix PV Bus device
> > >
> > > On Tue, 2013-07-02 at 11:49 +0100, Tim Deegan wrote:
> > > > At 10:31 +0000 on 02 Jul (1372761105), Paul Durrant wrote:
> > > > > > > Well, the WU drivers could refuse to install except as upgrade to
> > > > > > > themselves (i.e. fail if there's any unknown driver bound to the
> xen
> > > > > > > platform device, and also fail if there's _no_ driver bound).  
> > > > > > > Then
> the
> > > > > > > guest admin can choose to install the drivers by hand and get
> > > automatic
> > > > > > > updates after that.
> > > > > >
> > > > > > That sounds reasonable. However I thought part of the point of
> getting
> > > > > > things into WU was then that they could be "inbox" (either
> figuratively
> > > > > > or literally) such that they would be installed by the Windows
> > > > > > installer. Perhaps that's a separate thing though.
> > > > > >
> > > > >
> > > > > No, that is the eventual aim so I don't think the 'upgrade only'
> > > > > options is really future-proof.
> > > >
> > > > Well, you can have them install by default on platforms that want it, or
> > > > on new enough Xen versions.  Or, even better, on new enough
> _windows_
> > > > versions.
> > > >
> > > > > > > XS, XC and anyone else who chooses could carry a separate patch
> that
> > > > > > > changes the default to 'install if there are no drivers', 
> > > > > > > signalling
> > > > > > > over xenstore, or ACPI, or a Windows domain policy, or whatever.
> > > > > >
> > > > > > Right.
> > > > > >
> > > > >
> > > > > Surely having a new device for the purposes of hosting Citrix PV
> > > > > drivers is a cleaner option for opting in?
> > > >
> > > > Only if it's OK that the _host_ admin has to be involved (which was the
> > > > original objection).  Upgrade-only but hooked to the existing ID lets a
> > > > guest admin install the drivers manually without plumbing it through
> > > > $CLOUDPROVIDER's toolstack, and without having it appear suddenly
> on
> > > > existing VMs in the dead of night.
> > >
> > > I think part of the problem here is that it is unclear who the target
> > > audience for these drivers are.
> > >
> > > Paul, are you intending that these drivers be only for XenServer users
> > > or are you intending for them to be used by the broader community on a
> > > variety of different Xen platforms?
> > >
> >
> > My intention is that the drivers are widely available to all who want
> > them, but the key word there is 'want'. No-one should get a surprise
> > when we publish to Windows Update so having the drivers bind to a new
> > device which can then be added to the VM config seems like the
> > cleanest solution.
> 
> Actually, it occurs to me now (and I have a feeling Tim was trying to
> say this and I didn't get it): It's not really appropriate for any
> individual vendor to upload a driver to Windows Update which binds to
> the default platform device ID anyway.
> 
> There are several other sets of Xen PV drivers out there (including the
> GPL PV drivers and various companies commercial/proprietary drivers) and
> having one particular set of drivers in WU puts all of them at a
> disadvantage. Before doing that we would need consensus behind the
> particular set of drivers, which I don't think any of them currently
> have.
> 
> All of which means that you do need your own device ID, for which you
> can upload support to WU. However I don't think it therefore follows
> that you need that device ID to be supported by upstream.
> 
> Does this work:
> 
> We assign a device ID to your drivers (and we would do the same for any
> vendor). You can then upload drivers supporting that ID to WU and
> arrange within your product to create the appropriate device.
> 
> At the same time you produce a setup.exe installer which will install
> those same drivers but also sets up (or includes) the binding to the
> existing device IDs.
> 
> So anyone running on XenServer gets the driver direct from WU and you
> can define your own policies around what that means and what the upgrade
> path and ties to the platform mean etc. People who want to use your
> drivers on non-XenServer platforms can choose to do so by manually
> installing from within the guest, with no need to modify their guest
> configuration.
> 
> Does that make sense?
> 

Yes, that makes sense *but* I would still like to avoid carrying a private 
patch to QEMU (and potentially have to keep rebasing it), hence my posting the 
patch the qemu-devel. Having the code in QEMU does no harm, clearly reserves 
the device id, and any VM provider (with a suitable version of QEMU on their 
host) can then enable the device should they wish. Am I missing something?

  Paul
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel