From mboxrd@z Thu Jan 1 00:00:00 1970 From: Suravee Suthikulpanit Subject: Re: [PATCH 1/1] x86/AMD: Fix setup ssss:bb:dd:f for d0 failed Date: Thu, 29 Aug 2013 20:25:28 -0500 Message-ID: <521FF488.2030708@amd.com> References: <1375843208-3165-1-git-send-email-suravee.suthikulpanit@amd.com> <5202147D02000078000E9D00@nat28.tlf.novell.com> <5202685F.8090601@amd.com> <5202871902000078000EA01A@nat28.tlf.novell.com> <52029E12.20305@amd.com> <520358F502000078000EA1AA@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VFDT1-0002ca-II for xen-devel@lists.xenproject.org; Fri, 30 Aug 2013 01:25:39 +0000 In-Reply-To: <520358F502000078000EA1AA@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel , xiantao.zhang@intel.com List-Id: xen-devel@lists.xenproject.org On 8/8/2013 1:38 AM, Jan Beulich wrote: >>>> On 07.08.13 at 21:20, Suravee Suthikulanit wrote: >> On 8/7/2013 10:42 AM, Jan Beulich wrote: >>>>>> On 07.08.13 at 17:31, Suravee Suthikulanit 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