[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.