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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.08.13 at 21:20, Suravee Suthikulanit <suravee.suthikulpanit@xxxxxxx> 
>>> wrote:
> On 8/7/2013 10:42 AM, Jan Beulich wrote:
>>>>> On 07.08.13 at 17:31, Suravee Suthikulanit 
>>>>> <suravee.suthikulpanit@xxxxxxx> 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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel