This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: [RFC] Auto rebind PCI devices

On Tue, 2006-04-04 at 17:43 +0100, Mark Williamson wrote:
> Hi Ryan,
> I remember you showing some interest when I suggested rebinding PCI devices 
> automatically.  I've hacked together a quick prototype of "what I meant".
> I put a bundle at: 
> http://www.cambridge.intel-research.net/~mwilli2/pci_auto_rebind.hg
> You can fetch my changes into a repository using:
> hg unbundle <url>
> The behaviour is:
> * If the device specified in a domain config file is already bound to another 
> driver in dom0, fail creation with an error - as before.
> * If the device specified in the config is not currently bound to a driver, 
> add it to the pciback driver and create the domain.
> * If the device specificed in the config is bound *and* pci-force-rebind is 
> set, then unbind it from the existing driver and rebind it to pciback, then 
> start the domain.
> pci-force-rebind allows users who want total automation in the rebinding 
> process to have it, whilst by default preventing the automatic rebinding from 
> stealing devices dom0 is relying on.
> I'd be interested to see what you think about it - in particular, whether 
> there are potential failures in the rebinding code that I ought to be 
> catching (e.g. if drivers won't unbind from a device - can that happen?).  
> Any objections to the general functionality?
> Cheers,
> Mark

Hi Mark,

Sorry for the delay in getting back to you. I finally had an opportunity
to look at your code. FWIW, I think it's a good idea that can only make
things easier for the Xen user. I definitely agree that it's better to
default the rebinding by force feature to off.

A driver can't do anything to stop the unbinding of a device. At least
not with the current code in Linux. The driver can be notified (if it
implements the remove callback), but it can't stop it. A driver can only
prevent binding. That said, it's probably a good idea to check after
binding that the device really did bind to the pciback driver (there
will be a symlink in the pciback driver directory with the name of the
device if binding occurred successfully) just in case the Linux behavior
changes or some strange error occurs.

You may want to also add a test to check if the pciback driver is even
loaded (and possibly try a modprobe if it's not).

On a stylistic note (which is strictly my personal opinion, it doesn't
really matter how it's done), I think self.driver should be equal to
None if there is no driver already bound to a device (instead of the
empty string). However, I think my code (the sysfs and proc parts)
assumed there would always be a driver (which was an incorrect
assumption) so this change would require a couple of other changes in
this file to work.

So, no objections here. :)  It's a great idea to make the binding happen


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>