From mboxrd@z Thu Jan 1 00:00:00 1970 From: Weidong Han Subject: Re: PCI Passthrough Problems/Questions Date: Thu, 28 Oct 2010 10:31:01 +0800 Message-ID: <4CC8E065.8060509@intel.com> References: <4CC55D5C02000099000BA698@collaborate.seakr.com> <20101025174033.GA5766@dumpdata.com> <4CC5790502000099000BA6DC@collaborate.seakr.com> <20101025184818.GA6259@dumpdata.com> <4CC57D2102000099000BA6E6@collaborate.seakr.com> <20101025190752.GB6452@dumpdata.com> <4CC7C95E.7020500@intel.com> <4CC7EBC802000099000BA923@collaborate.seakr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4CC7EBC802000099000BA923@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 Nick Couchman wrote: >> Nick, >> >> I think the issue is 02:00.0 was mapped twice. Could you try with below >> patch? Then post the xen log. Pls post all output of 'lspci -v' on your >> system. >> >> > > I applied the patch, with one minor change. The line: > > dprintk(XENLOG_ERR VTDPREFIX, "context_present: %x:%x.%x:pdev->domain=%d > domain=%d\n", bus, PCI_SLOT(devfn), PCI_FUNC(devfn), pdev->domain, > domain->domain_id); > > should be: > > dprintk(XENLOG_ERR VTDPREFIX, "context_present: %x:%x.%x:pdev->domain=%d > domain=%d\n", bus, PCI_SLOT(devfn), PCI_FUNC(devfn), > pdev->domain->domain_id, domain->domain_id); > > (notice the pdev->domain->domain_id instead of pdev->domain). > > The domU no longer generates the error about failing to assign device to > IOMMU, but now it just silently crashes. xm dmesg output: > > (XEN) [VT-D]iommu.c:1511: d0:PCI: unmap bdf = 2:0.0 > (XEN) [VT-D]iommu.c:1340: bus: 2, devfn: 0[VT-D]iommu.c:1368: d1:PCI: > map bdf = 2:0.0 > (XEN) [VT-D]iommu.c:1371: domain_conext_mapping_one ret: 0 > (XEN) [VT-D]iommu.c:1378: Upstream bridge for 1:0 is 2. > (XEN) [VT-D]iommu.c:1383: d1:PCI: map PCIe2PCI bdf = 1:0.0 > (XEN) [VT-D]iommu.c:1394: d1:PCI: map secbus (2) with devfn 0 > (XEN) [VT-D]iommu.c:1249: context_present: 2:0.0:pdev->domain=0 domain=1 > (XEN) [VT-D]iommu.c:1415: Return value: 0 > (XEN) [VT-D]io.c:300: d1: bind: m_gsi=16 g_gsi=36 device=5 intx=0 > (XEN) [VT-D]iommu.c:1511: d0:PCI: unmap bdf = 2:0.1 > (XEN) [VT-D]iommu.c:1340: bus: 2, devfn: 1[VT-D]iommu.c:1368: d1:PCI: > map bdf = 2:0.1 > (XEN) [VT-D]iommu.c:1371: domain_conext_mapping_one ret: 0 > (XEN) [VT-D]iommu.c:1378: Upstream bridge for 1:0 is 2. > (XEN) [VT-D]iommu.c:1383: d1:PCI: map PCIe2PCI bdf = 1:0.0 > (XEN) [VT-D]iommu.c:1394: d1:PCI: map secbus (2) with devfn 0 > (XEN) [VT-D]iommu.c:1415: Return value: 0 > (XEN) [VT-D]io.c:300: d1: bind: m_gsi=16 g_gsi=40 device=6 intx=0 > (XEN) [VT-D]iommu.c:1511: d1:PCI: unmap bdf = 2:0.1 > (XEN) [VT-D]iommu.c:1340: bus: 2, devfn: 1[VT-D]iommu.c:1368: d0:PCI: > map bdf = 2:0.1 > (XEN) [VT-D]iommu.c:1371: domain_conext_mapping_one ret: 0 > (XEN) [VT-D]iommu.c:1378: Upstream bridge for 1:0 is 2. > (XEN) [VT-D]iommu.c:1383: d0:PCI: map PCIe2PCI bdf = 1:0.0 > (XEN) [VT-D]iommu.c:1394: d0:PCI: map secbus (2) with devfn 0 > (XEN) [VT-D]iommu.c:1415: Return value: 0 > (XEN) [VT-D]iommu.c:1511: d1:PCI: unmap bdf = 2:0.0 > (XEN) [VT-D]iommu.c:1340: bus: 2, devfn: 0[VT-D]iommu.c:1368: d0:PCI: > map bdf = 2:0.0 > (XEN) [VT-D]iommu.c:1371: domain_conext_mapping_one ret: 0 > (XEN) [VT-D]iommu.c:1378: Upstream bridge for 1:0 is 2. > (XEN) [VT-D]iommu.c:1383: d0:PCI: map PCIe2PCI bdf = 1:0.0 > (XEN) [VT-D]iommu.c:1394: d0:PCI: map secbus (2) with devfn 0 > (XEN) [VT-D]iommu.c:1249: context_present: 2:0.0:pdev->domain=1 domain=0 > (XEN) [VT-D]iommu.c:1415: Return value: 0 > > And from xend.log I've pasted into this pastebin: > > http://pastebin.com/b4bwdBPq > > I have some extra dprintk calls that I threw in there, so there may be a > little more output than with the patch you sent. > > > the log of xm dmesg looks no problem. you'd better post complete log and lspci -v. Regards, Weidong