From mboxrd@z Thu Jan 1 00:00:00 1970 From: Weidong Han Subject: Re: PCI Passthrough Problems/Questions Date: Wed, 03 Nov 2010 09:01:26 +0800 Message-ID: <4CD0B466.6000606@intel.com> References: <4CC92DE202000099000BAA57@collaborate.seakr.com> <4CCA377C.6020605@intel.com> <4CCAC39702000099000BABCA@collaborate.seakr.com> <4CCF85BF.9070501@intel.com> <4CD00CF802000099000BAF8E@collaborate.seakr.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------030200050507050407080005" Return-path: In-Reply-To: <4CD00CF802000099000BAF8E@collaborate.seakr.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Nick Couchman Cc: "xen-devel@lists.xensource.com" , "konrad.wilk@Oracle.Com" List-Id: xen-devel@lists.xenproject.org This is a multi-part message in MIME format. --------------030200050507050407080005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Nick Couchman wrote: >>> >>> >> The logs look no problem. I'm wondering if the device implies PCI >> standard. At last, I think you can try: only assign 02:00.0 >> (pci=[02:00.0]), or assign them as multiple devices in guest >> (pci=[02:00.0-1]). >> >> Regards, >> Weidong >> > > Should have tried that on my own. Forwarding just 02:00.0 through > worked just fine! > > So, the patch you had me apply to the Xen 4 source - is that a final > version of the patch, or is there still some work to do to come up with > a final fix for this? > > The patch is just for your testing. I think Jan's patch should fix the issue. Jan sent it out in xen-devel mailing list yesterday, I attached it here, pls try with it. Regards, Weidong --------------030200050507050407080005 Content-Type: text/plain; name="vtd-check-secbus-devfn.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="vtd-check-secbus-devfn.patch" If the device at :00.0 is the device the mapping operation was initiated for, trying to map it a second time will fail, and hence this second mapping attempt must be prevented (as was done prior to said c/s). Once at it, simplify the code a little, too. Signed-off-by: Jan Beulich --- a/xen/drivers/passthrough/vtd/iommu.c +++ b/xen/drivers/passthrough/vtd/iommu.c @@ -1371,23 +1371,16 @@ static int domain_context_mapping(struct if ( find_upstream_bridge(&bus, &devfn, &secbus) < 1 ) break; - /* PCIe to PCI/PCIx bridge */ - if ( pdev_type(bus, devfn) == DEV_TYPE_PCIe2PCI_BRIDGE ) - { - ret = domain_context_mapping_one(domain, drhd->iommu, bus, devfn); - if ( ret ) - return ret; + ret = domain_context_mapping_one(domain, drhd->iommu, bus, devfn); - /* - * Devices behind PCIe-to-PCI/PCIx bridge may generate - * different requester-id. It may originate from devfn=0 - * on the secondary bus behind the bridge. Map that id - * as well. - */ + /* + * Devices behind PCIe-to-PCI/PCIx bridge may generate different + * requester-id. It may originate from devfn=0 on the secondary bus + * behind the bridge. Map that id as well if we didn't already. + */ + if ( !ret && pdev_type(bus, devfn) == DEV_TYPE_PCIe2PCI_BRIDGE && + (secbus != pdev->bus || pdev->devfn != 0) ) ret = domain_context_mapping_one(domain, drhd->iommu, secbus, 0); - } - else /* Legacy PCI bridge */ - ret = domain_context_mapping_one(domain, drhd->iommu, bus, devfn); break; --------------030200050507050407080005 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --------------030200050507050407080005--