[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |