From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mo2.mail-out.ovh.net (8.mo2.mail-out.ovh.net [188.165.52.147]) by dpdk.org (Postfix) with ESMTP id 54130DE4 for ; Sun, 5 Jan 2014 18:29:58 +0100 (CET) Received: from mail437.ha.ovh.net (gw6.ovh.net [213.251.189.206]) by mo2.mail-out.ovh.net (Postfix) with SMTP id 459B7FFA00C for ; Sun, 5 Jan 2014 18:31:06 +0100 (CET) Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 5 Jan 2014 19:31:06 +0200 Received: from lneuilly-152-23-9-75.w193-252.abo.wanadoo.fr (HELO pcdeff) (ff@ozog.com@193.252.40.75) by ns0.ovh.net with SMTP; 5 Jan 2014 19:31:05 +0200 From: =?iso-8859-1?Q?Fran=E7ois-Fr=E9d=E9ric_Ozog?= To: "'Sridhar S'" , References: In-Reply-To: Date: Sun, 5 Jan 2014 18:28:47 +0100 Message-ID: <019901cf0a3b$97b47cd0$c71d7670$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8KEvJtZIxTlb+QS4mTc5j7qkuWZgAJslBw Content-Language: fr X-Ovh-Tracer-Id: 10869719176054888665 X-Ovh-Remote: 193.252.40.75 (lneuilly-152-23-9-75.w193-252.abo.wanadoo.fr) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: 0 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeejtddrvdeiucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu X-Spam-Check: DONE|U 0.5/N X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeejtddrvdeiucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu Subject: Re: [dpdk-dev] Issue when the kernel parameter intel_iommu=on is being used X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jan 2014 17:29:58 -0000 Hi, To understand the issue, you may have a look at: http://www.intel.com/content/www/us/en/intelligent-systems/intel-technolo= gy/ vt-directed-io-spec.html When you have no IOMMU, "physical" address space is accessed directly by hardware, so your core works. When VT-d is active, there is DMA/IRQ remapping hardware layer between = the device and the memory/cpu. If you look at =A73.4.3 of the spec, you that = for each device of each bus there is a context (enumerated at boot time, leveraging BIOS/ACPI). For each device, you may have address translation programmed so that DMA produced by hardware is actually mapped to a = physical address. When you use the Linux kernel API for mapping DMA memory, Linux takes = care of the "details".=20 For DPDK, documentation =A75.6 Using Linux IOMMU Pass-Through to Run = Intel=AE DPDK with Intel=AE VT-d says that you should have iommu=3Dpt kernel = parameter on. Do you have it ? FF > -----Message d'origine----- > De=A0: dev [mailto:dev-bounces@dpdk.org] De la part de Sridhar S > Envoy=E9=A0: dimanche 5 janvier 2014 13:38 > =C0=A0: dev@dpdk.org > Objet=A0: [dpdk-dev] Issue when the kernel parameter intel_iommu=3Don = is being > used >=20 > Hello, >=20 >=20 >=20 > I am using DPDK 1.5 for development of host pmd for device =93Connect = X3=94. >=20 >=20 >=20 > I am observing issue while the ConnectX3 device DMA to a memory which = is > allocated with rte_memzone_reserve_aligned() API . >=20 > The issue(please refer ERROR below) has been observed if the system = runs > with the kernel parameter =93intel_iommu=3Don=94. >=20 >=20 >=20 > ERROR : >=20 > dmar: DRHD: handling fault status reg 302 >=20 > dmar: DMAR:[DMA Write] Request device [01:00.0] fault addr 4f883000 >=20 > DMAR:[fault reason 01] Present bit in root entry is clear >=20 >=20 > The reported "fault Addr" is the physical address which was returned = by the > Above API. >=20 >=20 >=20 > I don=92t see any issue with the same code when the system up with = kernel > parameter intel_iommu=3Doff. >=20 >=20 >=20 >=20 > Can you share your comments on this issue? >=20 >=20 > Thanks in advance >=20 > Sri