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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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?

Ian.


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