qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paul Durrant
Subject: Re: [Qemu-devel] [Xen-devel] [PATCH] Add Xen platform PCI device version 2.
Date: Wed, 19 Jun 2013 11:23:37 +0000

> -----Original Message-----
> From: James Harper [mailto:address@hidden
> Sent: 19 June 2013 11:55
> To: Paul Durrant; Ian Campbell
> Cc: address@hidden; address@hidden
> Subject: RE: [Xen-devel] [PATCH] Add Xen platform PCI device version 2.
> 
> >
> > > -----Original Message-----
> > > From: Ian Campbell
> > > Sent: 19 June 2013 10:42
> > > To: Paul Durrant
> > > Cc: address@hidden; address@hidden
> > > Subject: Re: [Xen-devel] [PATCH] Add Xen platform PCI device version 2.
> > >
> > > On Wed, 2013-06-19 at 10:32 +0100, Paul Durrant wrote:
> > > > The XenServer 6.1+ Citrix Windows PV bus driver binds to a new version
> > > > of the Xen platform device (since the newer driver set cannot co-exist
> > > > with previous drivers which bind to the existing "xen-platform" type of
> > > > device). This patch introduces a new "xen-platform-2" device type with
> > > > the appropriate device_id and revision.
> > >
> > > What is the difference between these two devices?
> > >
> >
> > As the comment implies, the device_id (2 rather than 1) and the revision (2
> > rather than 1).
> >
> 
> Are the new drivers not backwards compatible?
> 
> Do any of the new driver names conflict with the old names? If not and if the
> bus driver in turn enumerates devices with different names than the old
> then the two should be able to exist side-by-side with only one being active
> depending on what the vm is configured with.
> 

The problem is that the old Citrix PV drivers bind their version of xenvbd 
directly to the platform device (id=1). The new PV drivers bind their xenbus 
driver to their platform device, because to go onto Windows Update you cannot 
have an installer and therefore cannot bind to a root enumerated node. Now, if 
I post  a version of xenbus onto Windows Update that binds to id=1 then I 
cannot prevent VMs installed with the old PV drivers from downloading the new 
version of xenbus and using that (since it is newer) in preference to their 
version of xenvbd. The result would then be a BSOD 0x7B after reboot because 
the system disk has vanished.

The issue going forward is that the only way of controlling driver download 
from Windows Update is by OS version and device binding. A PCI device binding 
only consists of vendor id, device id, subsystem vendor id, subsystem device id 
and revision. So if we want to control which version of the PV bus driver is 
applied to a VM, for a given OS, then we must vary one of those things.

  Paul



reply via email to

[Prev in Thread] Current Thread [Next in Thread]