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

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



> -----Original Message-----
> From: qemu-devel-bounces+paul.durrant=citrix.com@xxxxxxxxxx
> [mailto:qemu-devel-bounces+paul.durrant=citrix.com@xxxxxxxxxx] On
> Behalf Of Paul Durrant
> Sent: 27 June 2013 09:29
> To: Alex Bligh; Tim (Xen.org)
> Cc: qemu-devel@xxxxxxxxxx; Ian Campbell; Matt Wilson; xen-
> devel@xxxxxxxxxxxxx
> Subject: Re: [Qemu-devel] [Xen-devel] [PATCH] Add Xen platform PCI device
> version 2.
> 
> > -----Original Message-----
> > From: Alex Bligh [mailto:alex@xxxxxxxxxxx]
> > Sent: 26 June 2013 21:00
> > To: Paul Durrant; Tim (Xen.org)
> > Cc: Ian Campbell; Matt Wilson; xen-devel@xxxxxxxxxxxxx; qemu-
> > devel@xxxxxxxxxx; Alex Bligh
> > Subject: RE: [Xen-devel] [Qemu-devel] [PATCH] Add Xen platform PCI
> device
> > version 2.
> >
> >
> >
> > --On 26 June 2013 12:06:31 +0000 Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> > wrote:
> >
> > > 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.
> >
> > Then (without knowing the details) what's to prevent the new drivers not
> > making such assumptions, and carrying some versioning information, such
> > that we need one new PCI device now, but no more in the future?
> >
> 
> The new drivers are architected very differently such that they are suitable
> for Windows Update. That means each driver is separately installable and
> upgradeable and can make no assumptions about presence or version of any
> other driver. Thus all discovery is done at runtime and each individual
> interface carries a version number.
> I still think we need the option to control some aspect of the PCI device that
> the top level bus driver binds to so that we have the possibility of using
> different PV drivers sets on different VMs. I'm not saying that this is
> necessarily a good idea but the idea of a virtual hardware platform version
> (which is essentially what I believe this top level device represents, since 
> we
> have no other way of indicating that to Windows Update) has precedent;
> VMWare have had such a concept for a very long time
> (http://kb.vmware.com/selfservice/microsites/search.do?language=en_US
> &cmd=displayKC&externalId=1003746) and so it seems quite reasonable for
> a product such as XenServer to have a similar concept. I'll submit code for a
> new Citrix PV Bus device shortly.
> 

I had a chat with Tim and there may be chance we can do something sensible and 
still bind to the usual Xen platform device ID so I'm going to give that a try 
first.

  Paul

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.