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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 30.08.13 at 03:25, Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx>
wrote:
> On 8/8/2013 1:38 AM, Jan Beulich wrote:
>>>>> 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...
>>
> 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.

I don't think I ever said this. Whether we're talking about DomU or
Dom0 here is irrelevant. I'm just pointing out that bridges do get
mappings established for them whenever a device behind them gets
mapped.

Jan


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