Xen devel - Nov 2008 - Shouldn''t remove device in pci_bus_probe_wrapper()

Hi,

In pci_bus_probe_wrapper(), it adds (assign) a device to dom0 firstly, but if
pci_bus_probe() for the device fails (don''t have driver), the device
will be removed (deassigned) from dom0. For PCIe-to-PCI bridges, they are
removed from dom0 when they are hooked by pci_bus_probe_wrapper().
That''s to say they are not mapped in VT-d page table. Thus the PCI
devices under these bridges cannot work. This situation happens when install
pciback module, because pciback will probe these bridges and removed them from
dom0. Built-in pciback won''t result in this problem due to these
bridges (for example 00:1e.0) are probed before their devices (for example
02:00.0). (When map a pci device (02:00.0) to VT-d, it will also map its
pcie-to-pci bridge (00:1e.0) to VT-d)

So I think should not remove (deassign) devices from dom0 when pci_bus_probe()
fails. Each device which can DMA should be mapped in VT-d when VT-d is enabled.
But current code make it possible some these devices are not mapped into VT-d.


Following is the patch to don''t remove device from dom0 when
pci_bus_probe() fails.


diff -r 2fb13b8cbe13 drivers/xen/core/pci.c
--- a/drivers/xen/core/pci.c	Thu Oct 30 13:34:43 2008 +0000
+++ b/drivers/xen/core/pci.c	Thu Nov 06 10:15:26 2008 +0800
@@ -23,14 +23,6 @@ static int pci_bus_probe_wrapper(struct 
 		return r;
 
 	r = pci_bus_probe(dev);
-	if (r) {
-		int ret;
-
-		ret = HYPERVISOR_physdev_op(PHYSDEVOP_manage_pci_remove,
-					    &manage_pci);
-		WARN_ON(ret && ret != -ENOSYS);
-	}
-
 	return r;
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Yeah.  Removing the PCIe-to-PCI bridge is definitely not a good idea.
Never tested the patch with pciback not compiled in, so I never ran
into this problem.

Keeping all devices -- even those with no driver attached -- mapped in
the VT-d page tables is not a big deal.  It only matters if you care
about "rogue" devices.  Alternatively one could test whether the
device is a bridge before deciding whether to unmap it.

	eSk



[Weidong Han]
> Hi,
> In pci_bus_probe_wrapper(), it adds (assign) a device to dom0
> firstly, but if pci_bus_probe() for the device fails (don''t have
> driver), the device will be removed (deassigned) from dom0. For
> PCIe-to-PCI bridges, they are removed from dom0 when they are hooked
> by pci_bus_probe_wrapper(). That''s to say they are not mapped in
> VT-d page table. Thus the PCI devices under these bridges cannot
> work. This situation happens when install pciback module, because
> pciback will probe these bridges and removed them from
> dom0. Built-in pciback won''t result in this problem due to these
> bridges (for example 00:1e.0) are probed before their devices (for
> example 02:00.0). (When map a pci device (02:00.0) to VT-d, it will
> also map its pcie-to-pci bridge (00:1e.0) to VT-d)
> So I think should not remove (deassign) devices from dom0 when
> pci_bus_probe() fails. Each device which can DMA should be mapped in
> VT-d when VT-d is enabled. But current code make it possible some
> these devices are not mapped into VT-d.
> Following is the patch to don''t remove device from dom0 when
> pci_bus_probe() fails.
> diff -r 2fb13b8cbe13 drivers/xen/core/pci.c
> --- a/drivers/xen/core/pci.c	Thu Oct 30 13:34:43 2008 +0000
> +++ b/drivers/xen/core/pci.c	Thu Nov 06 10:15:26 2008 +0800
> @@ -23,14 +23,6 @@ static int pci_bus_probe_wrapper(struct 
>  		return r;
 
>  	r = pci_bus_probe(dev);
> -	if (r) {
> -		int ret;
> -
> -		ret = HYPERVISOR_physdev_op(PHYSDEVOP_manage_pci_remove,
> -					    &manage_pci);
> -		WARN_ON(ret && ret != -ENOSYS);
> -	}
> -
>  	return r;
>  }
 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel