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

[Tim Deegan <tim@xen.org>]

At 12:06 +0000 on 26 Jun (1372248391), Paul Durrant wrote:
> > -----Original Message-----
> > From: Tim Deegan [mailto:tim@xen.org]
> > Sent: 26 June 2013 12:58
> > To: Paul Durrant
> > Cc: Ian Campbell; Matt Wilson; Alex Bligh; xen-devel@lists.xen.org; qemu-
> > devel@nongnu.org
> > 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

> > 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?

> > > 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. :)

Tim.