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: Thu, 27 Jun 2013 10:58:19 +0000

> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden On
> Behalf Of Paul Durrant
> Sent: 27 June 2013 09:29
> To: Alex Bligh; Tim (Xen.org)
> Cc: address@hidden; Ian Campbell; Matt Wilson; xen-
> address@hidden
> Subject: Re: [Qemu-devel] [Xen-devel] [PATCH] Add Xen platform PCI device
> version 2.
> 
> > -----Original Message-----
> > From: Alex Bligh [mailto:address@hidden
> > Sent: 26 June 2013 21:00
> > To: Paul Durrant; Tim (Xen.org)
> > Cc: Ian Campbell; Matt Wilson; address@hidden; qemu-
> > address@hidden; 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 <address@hidden>
> > 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



reply via email to

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