Han, Weidong
2008-Nov-07 07:59 UTC
[Xen-devel] 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
Espen Skoglund
2008-Nov-07 11:51 UTC
Re: [Xen-devel] Shouldn''t remove device in pci_bus_probe_wrapper()
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