ia64/linux-2.6.18-xen.hg

changeset 726:d31b6ccf10e4

xen: Shouldn't remove device in pci_bus_probe_wrapper()

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.

From: Weidong Han <weidong.han@intel.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
author Keir Fraser <keir.fraser@citrix.com>
date Fri Nov 07 17:04:20 2008 +0000 (2008-11-07)
parents 61ab98b5cc0e
children 69694615aebb
files drivers/xen/core/pci.c
line diff
     1.1 --- a/drivers/xen/core/pci.c	Thu Nov 06 10:29:00 2008 +0000
     1.2 +++ b/drivers/xen/core/pci.c	Fri Nov 07 17:04:20 2008 +0000
     1.3 @@ -23,14 +23,6 @@ static int pci_bus_probe_wrapper(struct 
     1.4  		return r;
     1.5  
     1.6  	r = pci_bus_probe(dev);
     1.7 -	if (r) {
     1.8 -		int ret;
     1.9 -
    1.10 -		ret = HYPERVISOR_physdev_op(PHYSDEVOP_manage_pci_remove,
    1.11 -					    &manage_pci);
    1.12 -		WARN_ON(ret && ret != -ENOSYS);
    1.13 -	}
    1.14 -
    1.15  	return r;
    1.16  }
    1.17