[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 1/1] x86/AMD: Fix setup ssss:bb:dd:f for d0 failed
>>> On 07.08.13 at 17:31, Suravee Suthikulanit <suravee.suthikulpanit@xxxxxxx> >>> wrote: > On 8/7/2013 2:33 AM, Jan Beulich wrote: >>>>> On 07.08.13 at 04:40, <suravee.suthikulpanit@xxxxxxx> wrote: >>> + /* Filter the bridge devices */ >>> + if ( (pdev->type == DEV_TYPE_PCIe_BRIDGE) >>> + || (pdev->type == DEV_TYPE_PCIe2PCI_BRIDGE) >>> + || (pdev->type == DEV_TYPE_LEGACY_PCI_BRIDGE) >>> + || (pdev->type == DEV_TYPE_PCI_HOST_BRIDGE) ) >>> + { >>> + AMD_IOMMU_DEBUG("Skipping device %04x:%02x:%02x.%u (type >>> %x)\n", >>> + pdev->seg, PCI_BUS(bdf), PCI_SLOT(bdf), >>> PCI_FUNC(bdf), >>> + pdev->type); >> I can see why host bridges can be skipped, but is this really also true >> for other bridge types, most importantly legacy ones? > > I am using the same logic here as in Intel's version in the > driver/passthrough/vtd/iommu/domain_context_map. No, not really: That code establishes a mapping for the upstream bridge of a legacy PCI device when handling that device. Your proposed code doesn't afaics. (This I understand is because bridges aren't expected to get assigned to guests, and hence otherwise the mapping for the bridge would never get established for a device behind it for other than Dom0.) Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |