On Wed, Nov 25, 2009 at 11:21:45PM +0800, Zhang, Xiantao wrote:

During boot the device can be owned by pciback or by the modele for which a PCI entry exist. Look for pciback.hide entry.

There are two modes of execution: 1). First being what you described wherein the device initially belogs to Dom0. The user unbinds it from the PCI device and binds it to the pciback module. At that point, the device is disabled and ready for PV guests. When a PV
guest starts pciback module makes the pci_enable_device call and sets the IRQ,
etc for the device (for MSI, it obviously gets the IDT value from the
hypervisor call). 2). Dom0 boots where the user specified on the command line
pciback.hide=(0000:01:03.1). The pciback owns the device (is binded to it) and the native module that
would load for this PCI device is not called.

It is correct that the unmapping/mapping and the ownership needs to be dynamic.
As user could bind to the pciback module, give it to guest, kill the guest, then map the
PCI device back to dom0, and after that repeat the whole thing.

Hmm.. I am not sure if this is the appropiate place for it. You see this driver is designed for the machines that don't have SR-IOV, VFs, or VT-d to be able to passthrough a PCI device to the PV guest. You can use this to run PV guests on Pentium 4 style machine.

I think that the SR-IOV devices would go through a different call stack to enable the device? Either way, I recently got my hands on a SR-IOV machine and will see how this works.

Has the 2.6.31.5 been working before with SR-IOV cards or is this your first experiment with this.

That is due to casting (domid is short int, rc is int). You need to check if rc is negative, and if so set the domid to DOMID_SELF. The next line below does this:

if (domid <= 0) domid = DOMID_SELF;

Ohh wait, looks like the fix for this never got pushed upstream. That should have been 'if (rc <= 0)'. Yikes.

rc is -16 (EBUSY). That implies that xenstored has not been initialized on Dom0.