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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Tim Deegan [mailto:tim@xxxxxxx]
> Sent: 26 June 2013 13:36
> To: Paul Durrant
> Cc: Ian Campbell; Matt Wilson; Alex Bligh; xen-devel@xxxxxxxxxxxxx; qemu-
> devel@xxxxxxxxxx
> Subject: Re: [Xen-devel] [Qemu-devel] [PATCH] Add Xen platform PCI device
> version 2.
> 
> At 12:06 +0000 on 26 Jun (1372248391), Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Tim Deegan [mailto:tim@xxxxxxx]
> > > Sent: 26 June 2013 12:58
> > > To: Paul Durrant
> > > Cc: Ian Campbell; Matt Wilson; Alex Bligh; xen-devel@xxxxxxxxxxxxx;
> qemu-
> > > devel@xxxxxxxxxx
> > > Subject: Re: [Xen-devel] [Qemu-devel] [PATCH] Add Xen platform PCI
> device
> > > version 2.
> > >
> > > At 11:23 +0000 on 26 Jun (1372245783), Paul Durrant wrote:
> > > >  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.
> > >
> > > I don't think you ever got an answer about whether this could be
> > > finagled using version numbers in the drivers.
> >
> > No, we thought about that and I don't believe it would be possible.
> 
> This doc makes it look like it's just a matter of choosing appropriate
> version and dates:
> http://msdn.microsoft.com/en-
> us/library/windows/hardware/gg487453.aspx
> 

The issue, I believe, is that DriverVerDate trumps DriverVerVersion and AFAIK 
we can't fake an old date because the driver signing process will not allow it.

> > > Also: would it not be possible to have a blkfront driver (even a trivial
> > > one) in your new bus driver so it can detect and avoid this problem?
> > >
> > > Or: have your bus driver detect when the blkfront driver is missing and
> > > not unplug the emulated disk?  In fact wouldn't having the emulated disk
> > > driver do the unplug solve it for free?
> >
> > The issue is the old s/w not the new s/w. The old drivers make
> > assumptions about each other's presence as we can't change that
> > because they are already out there.
> 
> The issue you mentioned was that the old drivers bound the block driver
> to the PCI device, and when your new driver is installed you get STOP 7B
> because the system disk is missing (because I guess you'd need the new
> xenbus driver to come up before it will trigger installing the new block
> driver).
> 
> So can the new driver not fix this, either by running a trivial blkfront
> itself or by allowing the emulated IDE controller to live?
> 

Aha, the old drivers have a registry override which will cause them to quiesce 
so I could have the new driver go and set that to make them shut up. That might 
allow us to cleanly take over on the next reboot. 

> > > > 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.
> > >
> > > I'd rather not.  This gets straight back to having host-admin controls
> > > that have to manually be matched to in-guest software.
> >
> > Well not really. This is just the same as a h/w vendor shipping a new
> > device.
> 
> Well, that would be more like having the PCI revision reflect the Xen
> version.  Which might be a reasonable idea, if there is to be a second
> PCI device.
> 
> But metaphors aside, it's still requiring an admin change in order to
> match the software inside the VM, which as we've seen is unpopular with
> admins. :)
> 

Yes, but that's more of a business decision than an architectural one. As you 
say, it may well be unpopular and thus is something I'd prefer we didn't do 
unless we absolutely have to. What we can't do is have drivers being downloaded 
from Windows Update into systems where we know they are going to break things 
so I would like the new device to have enough tunability to avoid a trainwreck, 
and a parameterised revision is just enough :-) Thus, I still prefer to have a 
new device and leave the old one alone.

  Paul

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