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

[Tim Deegan <tim@xxxxxxx>]

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.

If you could have it bind to either device then I guess a second PCI ID
is another way of signalling that policy, but we should probably use one
of the many other channels we have from the tools to the guest.

Tim.

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