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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2013-06-26 at 12:23 +0100, Paul Durrant wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 26 June 2013 11:40
> > To: Tim (Xen.org)
> > Cc: Paul Durrant; Matt Wilson; Alex Bligh; xen-devel@xxxxxxxxxxxxx; qemu-
> > devel@xxxxxxxxxx
> > Subject: Re: [Xen-devel] [Qemu-devel] [PATCH] Add Xen platform PCI device
> > version 2.
> > 
> > On Thu, 2013-06-20 at 09:56 +0100, Tim Deegan wrote:
> > > At 07:47 +0000 on 20 Jun (1371714432), Paul Durrant wrote:
> > > > > > I agree. If this is really the only solution, we would need to have
> > > > > > both versions presented to the guest so that old drivers continue to
> > > > > > work without any intervention.
> > > > >
> > > > > I suspect that if we expose both, both sets of drivers try to run the
> > > > > same PV connections, and hilarity ensues.
> > > > >
> > > >
> > > > Actually I think I can make that work, and it is the conclusion I came
> > > > to after Alex's comment.
> > >
> > > Ah, nice!  In that case, I'm a lot less worried -- we can just expose
> > > both versions/devices by default and there's no need for a visible
> > > control knob tied to driver version (except maybe for debugging).
> > >
> > > It means an 'unsupported' device appearing on other/older OSes, which is
> > > unfortunate, but ISTR only Windows really complains visibly about that.
> > 
> > I'm not at all convinced this is a good approach. Are we going to add a
> > third, forth and fifth device whenever Linux, BSD, $other-OS paint
> > themselves into a corner somehow WRT their internal driver model vs
> > their Xen PV drivers?
> > 
> 
> Is there any harm in having a separate device for each OS's PV
> drivers? I agree it's not entirely elegant, but at least it allows for
> revision control when you need it.
> 
> > AFAIK the Citrix PV drivers have never been formally supported on
> > anything other than XenServer and XCP (and I'm not sure about "formally"
> > for XCP), so this is really an issue of supporting upgrades for people
> > running those. I think rather than making hacks upstream, which will
> > effectively need to be supported forever, the hack should be done on the
> > XenServer side and take advantage of whatever the supported upgrade path
> > is (N+1 or N+2 or whatever). This way the hack can eventually go away.
> > For anyone who grabbed the older drivers and used them outside of the
> > context of XenServer or XCP this is a documentation/awareness issue.
> > 
> > Can we use the blacklisting functionality of the PV unplug protocol to
> > blacklist previous versions of the Citrix PV drivers? I wouldn't
> > consider this an unsuitable thing to do in upstream, in fact it would be
> > using it for exactly the purpose for which it was designed. As long as
> > this is sufficient to boot with emulated devices in order to switch to
> > the newer drivers that should be good enough.
> > 
> 
> We could blacklist all existing Citrix PV drivers in upstream QEMU, to
> avoid the clash, but that seems like a very unfriendly approach. Also,
> it's not going to stop someone with an existing VM, who happens to be
> using legacy Citrix PV drivers (an AWS VM for instance) receiving a
> driver from Windows Update that will blue-screen their VM on next
> reboot. Hence the only way forward is to bind the new drivers to
> something new, that we can control, so we know what driver a VM is
> going to get from Windows Update.

Is it not also possible to issue a new version of the old driver via
Windows update, e.g. a stunt one which just disables itself? Or to have
the new one somehow reach out and nobble the old one. Or have the new
one detect the presence of the old one and refuse to install until it
has been removed?

>  And we may indeed need to modify its revision in future so that we
> can retire old sets of PV drivers and replace them with new ones, but
> only for newer XenServer releases. Thus, I also propose to make the
> PCI revision of the new device a command line parameter.

So this ugliness is really just the thin end of the wedge and all users
of these drivers in the future are going to need to be educated on which
magic qemu option they need to go with the version of the driver they
are running? And when they get an update they might need to go into
their configuration and change it or else risk a blue screen on the next
reboot? That sounds like madness to me...

It may be acceptable for XenServer to tie versions of the PV drivers to
specific versions of XenServer but I'm afraid that is not acceptable
upstream, we can't just go around willy nilly breaking compatibility
between front and backends, this is why we have feature flags,
negotiation and fallbacks.

It would be one thing to accept this unfortunate event and take a one
time hack to dig you out of a hole. But in that case it would really
need to be the case that the new version of the drivers are designed
with sufficient future proofing mechanisms that any future changes can
be handled internally. It seems to me like you intend to treat this
mechanism as an ongoing deliberate mechanism rather than a one off fix
for a historical mistake.

Ian.


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