Re: [PATCH 1/1] x86/AMD: Fix setup ssss:bb:dd:f for d0 failed

[Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>]

On 8/8/2013 1:38 AM, Jan Beulich wrote:
>>>> On 07.08.13 at 21:20, Suravee Suthikulanit <suravee.suthikulpanit@amd.com> wrote:
>> On 8/7/2013 10:42 AM, Jan Beulich wrote:
>>>>>> On 07.08.13 at 17:31, Suravee Suthikulanit <suravee.suthikulpanit@amd.com> wrote:
>>>> 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.)
>> AFAICT from the domain_context_mapping() below, which get called when
>> the devices are assigned to domains
>>
>> static int domain_context_mapping(
>>       struct domain *domain, u8 devfn, const struct pci_dev *pdev)
>> {
>>       struct acpi_drhd_unit *drhd;
>>       int ret = 0;
>>       u8 seg = pdev->seg, bus = pdev->bus, secbus;
>>
>>       drhd = acpi_find_matched_drhd_unit(pdev);
>>       if ( !drhd )
>>           return -ENODEV;
>>
>>       ASSERT(spin_is_locked(&pcidevs_lock));
>>
>>       switch ( pdev->type )
>>       {
>>       case DEV_TYPE_PCIe_BRIDGE:
>>       case DEV_TYPE_PCIe2PCI_BRIDGE:
>>       case DEV_TYPE_LEGACY_PCI_BRIDGE:
>>           break;
>>
>> These bridges are actually not mapped(i.e. skipped).  That is why I
>> think the logic above is supposed to be doing the same thing.
> Just look a few lines down: There the bridges will get mappings
> established when a device behind them gets mapped.
>
> But since devices can't be behind host bridges, excluding those
> _may_ still be appropriate/desirable. Still waiting for Xiantao to
> voice his opinion...
>
> Jan
Sorry for didn't get a chance to follow up with this sooner.  Ok, I see 
the code you mentioned.
However, if I understand this correctly, it is also mapping the bridge 
to the domU
along with the end-device.  This is not the same as what you mentioned 
that the bridge should
be mapped to only Dom0.

Suravee