DPDK patches and discussions
 help / color / mirror / Atom feed
From: Zhe Tao <zhe.tao@intel.com>
To: dev@dpdk.org
Cc: zhe.tao@intel.com
Subject: [dpdk-dev] [PATCH v1] igu_uio: fix IOMMU domain issue
Date: Tue, 10 May 2016 19:21:41 +0800	[thread overview]
Message-ID: <1462879301-13570-1-git-send-email-zhe.tao@intel.com> (raw)

Problem:
The following  operations will cause the igb_uio based DPDK
operation failed.
--Any device assignment through the kvm_assign_device interface,
this can be the pci-assign method in QEMU
--VFIO group attachment operation(attach to the container)
this can happens in  vfio-pci assignment in QEMU

Root cause:
For the two operation above finally will call the intel_iommu_attach_device
(e.g. for vfio/ vfio_group_set_container->
vfio_iommu_type1_attach_group->intel_iommu_attach_device)
If we use iommu=pt in the grub which means intel iommu driver will create a
static identity domain for all the PCI device,
Which will set the translation type into passthrough for all the context
entry for all the PCI devices,
But once we close QEMU process, e.g. the VFIO framework will invoke the
detach group operation and finally will call the intel_iommu_detach_device
which will clean the context entry.
(now the IOMMU entry for this device is not availablei)

For AMD iommu driver it handle this detach action right which will restore the
pt_domain (the same as static identity domain for intel) to the
corresponding entry.

Solution:
Add a work around in igb_uio driver which map one single page.
Because all the DMA related alloc and map
actions will cause the intel IOMMU driver to reload the SI domain to the context
entry, that's why the kernel driver never meets such problem.


Signed-off-by: Zhe Tao <zhe.tao@intel.com>
---
 lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
index 45a5720..3fa88b0 100644
--- a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
+++ b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
@@ -327,6 +327,18 @@ igbuio_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
 	struct rte_uio_pci_dev *udev;
 	struct msix_entry msix_entry;
 	int err;
+	struct page *page;
+	/*
+	 * work around for Intel IOMMU implemation for SI doamin
+	 */
+
+	page = alloc_page(GFP_ATOMIC);
+	if (!page) {
+		dev_err(&dev->dev, "Cannot alloc page\n");
+	} else {
+		dma_map_page(&dev->dev, page, 0, PAGE_SIZE, DMA_FROM_DEVICE);
+		__free_page(page);
+	}
 
 	udev = kzalloc(sizeof(struct rte_uio_pci_dev), GFP_KERNEL);
 	if (!udev)
-- 
2.1.4

             reply	other threads:[~2016-05-10 11:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-10 11:21 Zhe Tao [this message]
2016-05-10 15:59 ` Stephen Hemminger
2016-05-11  7:35   ` Alejandro Lucero
2016-05-11 17:24     ` Ferruh Yigit
2016-07-08 17:27       ` Thomas Monjalon
2016-07-09  7:09         ` Ferruh Yigit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1462879301-13570-1-git-send-email-zhe.tao@intel.com \
    --to=zhe.tao@intel.com \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).