[PATCH 0/2] vfio on power

[PATCH 0/2] vfio on power

[Alexey Kardashevskiy]

The series introduces a VFIO support on POWER.
The QEMU support is required, the real mode acceleration patches are coming later.

Alexey Kardashevskiy (2):
  vfio powerpc: enabled on powernv platform
  vfio powerpc: implemented IOMMU driver for VFIO

 arch/powerpc/include/asm/iommu.h            |   15 ++
 arch/powerpc/kernel/iommu.c                 |  343 +++++++++++++++++++++++++++
 arch/powerpc/platforms/powernv/pci-ioda.c   |    1 +
 arch/powerpc/platforms/powernv/pci-p5ioc2.c |    5 +-
 arch/powerpc/platforms/powernv/pci.c        |    3 +
 drivers/iommu/Kconfig                       |    8 +
 drivers/vfio/Kconfig                        |    6 +
 drivers/vfio/Makefile                       |    1 +
 drivers/vfio/vfio_iommu_spapr_tce.c         |  269 +++++++++++++++++++++
 include/uapi/linux/vfio.h                   |   31 +++
 10 files changed, 681 insertions(+), 1 deletion(-)
 create mode 100644 drivers/vfio/vfio_iommu_spapr_tce.c

-- 
1.7.10.4

[PATCH 1/2] vfio powerpc: enabled on powernv platform

[Alexey Kardashevskiy]

This patch initializes IOMMU groups based on the IOMMU
configuration discovered during the PCI scan on POWERNV
(POWER non virtualized) platform. The IOMMU groups are
to be used later by VFIO driver (PCI pass through).

It also implements an API for mapping/unmapping pages for
guest PCI drivers and providing DMA window properties.
This API is going to be used later by QEMU-VFIO to handle
h_put_tce hypercalls from the KVM guest.

The iommu_put_tce_user_mode() does only a single page mapping
as an API for adding many mappings at once is going to be
added later.

Although this driver has been tested only on the POWERNV
platform, it should work on any platform which supports
TCE tables. As h_put_tce hypercall is received by the host
kernel and processed by the QEMU (what involves calling
the host kernel again), performance is not the best -
circa 220MB/s on 10Gb ethernet network.

To enable VFIO on POWER, enable SPAPR_TCE_IOMMU config
option and configure VFIO as required.

Cc: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
 arch/powerpc/include/asm/iommu.h            |   15 ++
 arch/powerpc/kernel/iommu.c                 |  343 +++++++++++++++++++++++++++
 arch/powerpc/platforms/powernv/pci-ioda.c   |    1 +
 arch/powerpc/platforms/powernv/pci-p5ioc2.c |    5 +-
 arch/powerpc/platforms/powernv/pci.c        |    3 +
 drivers/iommu/Kconfig                       |    8 +
 6 files changed, 374 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index cbfe678..900294b 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -76,6 +76,9 @@ struct iommu_table {
 	struct iommu_pool large_pool;
 	struct iommu_pool pools[IOMMU_NR_POOLS];
 	unsigned long *it_map;       /* A simple allocation bitmap for now */
+#ifdef CONFIG_IOMMU_API
+	struct iommu_group *it_group;
+#endif
 };
 
 struct scatterlist;
@@ -98,6 +101,8 @@ extern void iommu_free_table(struct iommu_table *tbl, const char *node_name);
  */
 extern struct iommu_table *iommu_init_table(struct iommu_table * tbl,
 					    int nid);
+extern void iommu_register_group(struct iommu_table * tbl,
+				 int domain_number, unsigned long pe_num);
 
 extern int iommu_map_sg(struct device *dev, struct iommu_table *tbl,
 			struct scatterlist *sglist, int nelems,
@@ -147,5 +152,15 @@ static inline void iommu_restore(void)
 }
 #endif
 
+/* The API to support IOMMU operations for VFIO */
+extern long iommu_clear_tce_user_mode(struct iommu_table *tbl,
+		unsigned long ioba, unsigned long tce_value,
+		unsigned long npages);
+extern long iommu_put_tce_user_mode(struct iommu_table *tbl,
+		unsigned long ioba, unsigned long tce);
+
+extern void iommu_flush_tce(struct iommu_table *tbl);
+extern long iommu_lock_table(struct iommu_table *tbl, bool lock);
+
 #endif /* __KERNEL__ */
 #endif /* _ASM_IOMMU_H */
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 7c309fe..b4fdabc 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -37,6 +37,7 @@
 #include <linux/fault-inject.h>
 #include <linux/pci.h>
 #include <linux/kvm_host.h>
+#include <linux/iommu.h>
 #include <asm/io.h>
 #include <asm/prom.h>
 #include <asm/iommu.h>
@@ -45,6 +46,7 @@
 #include <asm/kdump.h>
 #include <asm/fadump.h>
 #include <asm/vio.h>
+#include <asm/tce.h>
 
 #define DBG(...)
 
@@ -707,11 +709,39 @@ struct iommu_table *iommu_init_table(struct iommu_table *tbl, int nid)
 	return tbl;
 }
 
+static void group_release(void *iommu_data)
+{
+	struct iommu_table *tbl = iommu_data;
+	tbl->it_group = NULL;
+}
+
+void iommu_register_group(struct iommu_table * tbl,
+		int domain_number, unsigned long pe_num)
+{
+	struct iommu_group *grp;
+
+	grp = iommu_group_alloc();
+	if (IS_ERR(grp)) {
+		pr_info("powerpc iommu api: cannot create new group, err=%ld\n",
+				PTR_ERR(grp));
+		return;
+	}
+	tbl->it_group = grp;
+	iommu_group_set_iommudata(grp, tbl, group_release);
+	iommu_group_set_name(grp, kasprintf(GFP_KERNEL, "domain%d-pe%lx",
+			domain_number, pe_num));
+}
+
 void iommu_free_table(struct iommu_table *tbl, const char *node_name)
 {
 	unsigned long bitmap_sz;
 	unsigned int order;
 
+	if (tbl && tbl->it_group) {
+		iommu_group_put(tbl->it_group);
+		BUG_ON(tbl->it_group);
+	}
+
 	if (!tbl || !tbl->it_map) {
 		printk(KERN_ERR "%s: expected TCE map for %s\n", __func__,
 				node_name);
@@ -876,4 +906,317 @@ void kvm_iommu_unmap_pages(struct kvm *kvm, struct kvm_memory_slot *slot)
 {
 }
 
+static enum dma_data_direction tce_direction(unsigned long tce)
+{
+	if ((tce & TCE_PCI_READ) && (tce & TCE_PCI_WRITE))
+		return DMA_BIDIRECTIONAL;
+	else if (tce & TCE_PCI_READ)
+		return DMA_TO_DEVICE;
+	else if (tce & TCE_PCI_WRITE)
+		return DMA_FROM_DEVICE;
+	else
+		return DMA_NONE;
+}
+
+void iommu_flush_tce(struct iommu_table *tbl)
+{
+	/* Flush/invalidate TLB caches if necessary */
+	if (ppc_md.tce_flush)
+		ppc_md.tce_flush(tbl);
+
+	/* Make sure updates are seen by hardware */
+	mb();
+}
+EXPORT_SYMBOL_GPL(iommu_flush_tce);
+
+static long tce_clear_param_check(struct iommu_table *tbl,
+		unsigned long ioba, unsigned long tce_value,
+		unsigned long npages)
+{
+	unsigned long size = npages << IOMMU_PAGE_SHIFT;
+
+	/* ppc_md.tce_free() does not support any value but 0 */
+	if (tce_value)
+		return -EINVAL;
+
+	if (ioba & ~IOMMU_PAGE_MASK)
+		return -EINVAL;
+
+	if ((ioba + size) > ((tbl->it_offset + tbl->it_size)
+			<< IOMMU_PAGE_SHIFT))
+		return -EINVAL;
+
+	if (ioba < (tbl->it_offset << IOMMU_PAGE_SHIFT))
+		return -EINVAL;
+
+	return 0;
+}
+
+static long tce_put_param_check(struct iommu_table *tbl,
+		unsigned long ioba, unsigned long tce)
+{
+	if (!(tce & (TCE_PCI_WRITE | TCE_PCI_READ)))
+		return -EINVAL;
+
+	if (tce & ~(IOMMU_PAGE_MASK | TCE_PCI_WRITE | TCE_PCI_READ))
+		return -EINVAL;
+
+	if (ioba & ~IOMMU_PAGE_MASK)
+		return -EINVAL;
+
+	if ((ioba + IOMMU_PAGE_SIZE) > ((tbl->it_offset + tbl->it_size)
+			<< IOMMU_PAGE_SHIFT))
+		return -EINVAL;
+
+	if (ioba < (tbl->it_offset << IOMMU_PAGE_SHIFT))
+		return -EINVAL;
+
+	return 0;
+}
+
+static long clear_tce(struct iommu_table *tbl,
+		unsigned long entry, unsigned long pages)
+{
+	unsigned long oldtce;
+	struct page *page;
+	struct iommu_pool *pool;
+
+	for ( ; pages; --pages, ++entry) {
+		pool = get_pool(tbl, entry);
+		spin_lock(&(pool->lock));
+
+		oldtce = ppc_md.tce_get(tbl, entry);
+		if (oldtce & (TCE_PCI_WRITE | TCE_PCI_READ)) {
+			ppc_md.tce_free(tbl, entry, 1);
+
+			page = pfn_to_page(oldtce >> PAGE_SHIFT);
+			WARN_ON(!page);
+			if (page) {
+				if (oldtce & TCE_PCI_WRITE)
+					SetPageDirty(page);
+				put_page(page);
+			}
+		}
+		spin_unlock(&(pool->lock));
+	}
+
+	return 0;
+}
+
+long iommu_clear_tce_user_mode(struct iommu_table *tbl, unsigned long ioba,
+		unsigned long tce_value, unsigned long npages)
+{
+	long ret;
+	unsigned long entry = ioba >> IOMMU_PAGE_SHIFT;
+
+	ret = tce_clear_param_check(tbl, ioba, tce_value, npages);
+	if (!ret)
+		ret = clear_tce(tbl, entry, npages);
+
+	if (ret < 0)
+		pr_err("iommu_tce: %s failed ioba=%lx, tce_value=%lx ret=%ld\n",
+				__func__, ioba, tce_value, ret);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(iommu_clear_tce_user_mode);
+
+/* hwaddr is a virtual address here, tce_build converts it to physical */
+static long do_tce_build(struct iommu_table *tbl, unsigned long entry,
+		unsigned long hwaddr, enum dma_data_direction direction)
+{
+	long ret = -EBUSY;
+	unsigned long oldtce;
+	struct iommu_pool *pool = get_pool(tbl, entry);
+
+	spin_lock(&(pool->lock));
+
+	oldtce = ppc_md.tce_get(tbl, entry);
+	/* Add new entry if it is not busy */
+	if (!(oldtce & (TCE_PCI_WRITE | TCE_PCI_READ)))
+		ret = ppc_md.tce_build(tbl, entry, 1, hwaddr, direction, NULL);
+
+	spin_unlock(&(pool->lock));
+
+	if (unlikely(ret))
+		pr_err("iommu_tce: %s failed on hwaddr=%lx ioba=%lx kva=%lx ret=%ld\n",
+				__func__, hwaddr, entry << IOMMU_PAGE_SHIFT,
+				hwaddr, ret);
+
+	return ret;
+}
+
+static int put_tce_user_mode(struct iommu_table *tbl, unsigned long entry,
+		unsigned long tce)
+{
+	int ret;
+	struct page *page = NULL;
+	unsigned long hwaddr, offset = tce & IOMMU_PAGE_MASK & ~PAGE_MASK;
+	enum dma_data_direction direction = tce_direction(tce);
+
+	ret = get_user_pages_fast(tce & PAGE_MASK, 1,
+			direction != DMA_TO_DEVICE, &page);
+	if (unlikely(ret != 1)) {
+		pr_err("iommu_tce: get_user_pages_fast failed tce=%lx ioba=%lx ret=%d\n",
+				tce, entry << IOMMU_PAGE_SHIFT, ret);
+		return -EFAULT;
+	}
+	hwaddr = (unsigned long) page_address(page) + offset;
+
+	ret = do_tce_build(tbl, entry, hwaddr, direction);
+	if (ret)
+		put_page(page);
+
+	return ret;
+}
+
+long iommu_put_tce_user_mode(struct iommu_table *tbl, unsigned long ioba,
+		unsigned long tce)
+{
+	long ret;
+	unsigned long entry = ioba >> IOMMU_PAGE_SHIFT;
+
+	ret = tce_put_param_check(tbl, ioba, tce);
+	if (!ret)
+		ret = put_tce_user_mode(tbl, entry, tce);
+
+	if (ret < 0)
+		pr_err("iommu_tce: %s failed ioba=%lx, tce=%lx, ret=%ld\n",
+				__func__, ioba, tce, ret);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(iommu_put_tce_user_mode);
+
+/*
+ * Helpers to do locked pages accounting.
+ * Called from ioctl so down_write_trylock is not necessary.
+ */
+static void lock_acct(long npage)
+{
+	if (!current->mm)
+		return; /* process exited */
+
+	down_write(&current->mm->mmap_sem);
+	current->mm->locked_vm += npage;
+	up_write(&current->mm->mmap_sem);
+}
+
+/*
+ * iommu_lock_table - Start/stop using the table by VFIO
+ * @tbl: Pointer to the IOMMU table
+ * @lock: true when VFIO starts using the table
+ */
+long iommu_lock_table(struct iommu_table *tbl, bool lock)
+{
+	unsigned long sz = (tbl->it_size + 7) >> 3;
+	unsigned long locked, lock_limit;
+
+	if (lock) {
+		/*
+		 * Account for locked pages
+		 * The worst case is when every IOMMU page
+		 * is mapped to separate system page
+		 */
+		locked = current->mm->locked_vm + tbl->it_size;
+		lock_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
+		if (locked > lock_limit && !capable(CAP_IPC_LOCK)) {
+			pr_warn("RLIMIT_MEMLOCK (%ld) exceeded\n",
+					rlimit(RLIMIT_MEMLOCK));
+			return -ENOMEM;
+		}
+
+		if (tbl->it_offset == 0)
+			clear_bit(0, tbl->it_map);
+
+		if (!bitmap_empty(tbl->it_map, tbl->it_size)) {
+			pr_err("iommu_tce: it_map is not empty");
+			return -EBUSY;
+		}
+
+		lock_acct(tbl->it_size);
+		memset(tbl->it_map, 0xff, sz);
+	}
+
+	/* Clear TCE table */
+	clear_tce(tbl, tbl->it_offset, tbl->it_size);
+
+	if (!lock) {
+		lock_acct(-tbl->it_size);
+		memset(tbl->it_map, 0, sz);
+
+		/* Restore bit#0 set by iommu_init_table() */
+		if (tbl->it_offset == 0)
+			set_bit(0, tbl->it_map);
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(iommu_lock_table);
+
+int iommu_add_device(struct device *dev)
+{
+	struct iommu_table *tbl;
+	int ret = 0;
+
+	if (WARN_ON(dev->iommu_group)) {
+		pr_warn("iommu_tce: device %s is already in iommu group %d, skipping\n",
+				dev_name(dev),
+				iommu_group_id(dev->iommu_group));
+		return -EBUSY;
+	}
+
+	tbl = get_iommu_table_base(dev);
+	if (!tbl) {
+		pr_debug("iommu_tce: skipping device %s with no tbl\n",
+				dev_name(dev));
+		return 0;
+	}
+
+	pr_debug("iommu_tce: adding %s to iommu group %d\n",
+			dev_name(dev), iommu_group_id(tbl->it_group));
+
+	ret = iommu_group_add_device(tbl->it_group, dev);
+	if (ret < 0)
+		pr_err("iommu_tce: %s has not been added, ret=%d\n",
+				dev_name(dev), ret);
+
+	return ret;
+}
+
+void iommu_del_device(struct device *dev)
+{
+	iommu_group_remove_device(dev);
+}
+
+static int iommu_bus_notifier(struct notifier_block *nb,
+			      unsigned long action, void *data)
+{
+	struct device *dev = data;
+
+	switch (action) {
+	case BUS_NOTIFY_ADD_DEVICE:
+		return iommu_add_device(dev);
+	case BUS_NOTIFY_DEL_DEVICE:
+		iommu_del_device(dev);
+		return 0;
+	default:
+		return 0;
+	}
+}
+
+static struct notifier_block tce_iommu_bus_nb = {
+	.notifier_call = iommu_bus_notifier,
+};
+
+static int __init tce_iommu_init(void)
+{
+	BUILD_BUG_ON(PAGE_SIZE < IOMMU_PAGE_SIZE);
+
+	bus_register_notifier(&pci_bus_type, &tce_iommu_bus_nb);
+	return 0;
+}
+
+arch_initcall(tce_iommu_init);
+
 #endif /* CONFIG_IOMMU_API */
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index 8e90e89..04dbc49 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -522,6 +522,7 @@ static void pnv_pci_ioda_setup_dma_pe(struct pnv_phb *phb,
 			| TCE_PCI_SWINV_PAIR;
 	}
 	iommu_init_table(tbl, phb->hose->node);
+	iommu_register_group(tbl, pci_domain_nr(pe->pbus), pe->pe_number);
 
 	if (pe->pdev)
 		set_iommu_table_base(&pe->pdev->dev, tbl);
diff --git a/arch/powerpc/platforms/powernv/pci-p5ioc2.c b/arch/powerpc/platforms/powernv/pci-p5ioc2.c
index abe6780..7ce75b0 100644
--- a/arch/powerpc/platforms/powernv/pci-p5ioc2.c
+++ b/arch/powerpc/platforms/powernv/pci-p5ioc2.c
@@ -87,8 +87,11 @@ static void pnv_pci_init_p5ioc2_msis(struct pnv_phb *phb) { }
 static void pnv_pci_p5ioc2_dma_dev_setup(struct pnv_phb *phb,
 					 struct pci_dev *pdev)
 {
-	if (phb->p5ioc2.iommu_table.it_map == NULL)
+	if (phb->p5ioc2.iommu_table.it_map == NULL) {
 		iommu_init_table(&phb->p5ioc2.iommu_table, phb->hose->node);
+		iommu_register_group(&phb->p5ioc2.iommu_table,
+				pci_domain_nr(phb->hose->bus), phb->opal_id);
+	}
 
 	set_iommu_table_base(&pdev->dev, &phb->p5ioc2.iommu_table);
 }
diff --git a/arch/powerpc/platforms/powernv/pci.c b/arch/powerpc/platforms/powernv/pci.c
index f60a188..d112701 100644
--- a/arch/powerpc/platforms/powernv/pci.c
+++ b/arch/powerpc/platforms/powernv/pci.c
@@ -20,6 +20,7 @@
 #include <linux/irq.h>
 #include <linux/io.h>
 #include <linux/msi.h>
+#include <linux/iommu.h>
 
 #include <asm/sections.h>
 #include <asm/io.h>
@@ -503,6 +504,7 @@ static struct iommu_table *pnv_pci_setup_bml_iommu(struct pci_controller *hose)
 	pnv_pci_setup_iommu_table(tbl, __va(be64_to_cpup(basep)),
 				  be32_to_cpup(sizep), 0);
 	iommu_init_table(tbl, hose->node);
+	iommu_register_group(tbl, pci_domain_nr(hose->bus), 0);
 
 	/* Deal with SW invalidated TCEs when needed (BML way) */
 	swinvp = of_get_property(hose->dn, "linux,tce-sw-invalidate-info",
@@ -631,3 +633,4 @@ void __init pnv_pci_init(void)
 	ppc_md.teardown_msi_irqs = pnv_teardown_msi_irqs;
 #endif
 }
+
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index e39f9db..ce6b186 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -187,4 +187,12 @@ config EXYNOS_IOMMU_DEBUG
 
 	  Say N unless you need kernel log message for IOMMU debugging
 
+config SPAPR_TCE_IOMMU
+	bool "sPAPR TCE IOMMU Support"
+	depends on PPC_POWERNV
+	select IOMMU_API
+	help
+	  Enables bits of IOMMU API required by VFIO. The iommu_ops is
+	  still not implemented.
+
 endif # IOMMU_SUPPORT
-- 
1.7.10.4

[PATCH 2/2] vfio powerpc: implemented IOMMU driver for VFIO

[Alexey Kardashevskiy]

VFIO implements platform independent stuff such as
a PCI driver, BAR access (via read/write on a file descriptor
or direct mapping when possible) and IRQ signaling.

The platform dependent part includes IOMMU initialization
and handling. This patch implements an IOMMU driver for VFIO
which does mapping/unmapping pages for the guest IO and
provides information about DMA window (required by a POWERPC
guest).

The counterpart in QEMU is required to support this functionality.

Cc: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
 drivers/vfio/Kconfig                |    6 +
 drivers/vfio/Makefile               |    1 +
 drivers/vfio/vfio_iommu_spapr_tce.c |  269 +++++++++++++++++++++++++++++++++++
 include/uapi/linux/vfio.h           |   31 ++++
 4 files changed, 307 insertions(+)
 create mode 100644 drivers/vfio/vfio_iommu_spapr_tce.c

diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
index 7cd5dec..b464687 100644
--- a/drivers/vfio/Kconfig
+++ b/drivers/vfio/Kconfig
@@ -3,10 +3,16 @@ config VFIO_IOMMU_TYPE1
 	depends on VFIO
 	default n
 
+config VFIO_IOMMU_SPAPR_TCE
+	tristate
+	depends on VFIO && SPAPR_TCE_IOMMU
+	default n
+
 menuconfig VFIO
 	tristate "VFIO Non-Privileged userspace driver framework"
 	depends on IOMMU_API
 	select VFIO_IOMMU_TYPE1 if X86
+	select VFIO_IOMMU_SPAPR_TCE if PPC_POWERNV
 	help
 	  VFIO provides a framework for secure userspace device drivers.
 	  See Documentation/vfio.txt for more details.
diff --git a/drivers/vfio/Makefile b/drivers/vfio/Makefile
index 2398d4a..72bfabc 100644
--- a/drivers/vfio/Makefile
+++ b/drivers/vfio/Makefile
@@ -1,3 +1,4 @@
 obj-$(CONFIG_VFIO) += vfio.o
 obj-$(CONFIG_VFIO_IOMMU_TYPE1) += vfio_iommu_type1.o
+obj-$(CONFIG_VFIO_IOMMU_SPAPR_TCE) += vfio_iommu_spapr_tce.o
 obj-$(CONFIG_VFIO_PCI) += pci/
diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c b/drivers/vfio/vfio_iommu_spapr_tce.c
new file mode 100644
index 0000000..9b3fa88
--- /dev/null
+++ b/drivers/vfio/vfio_iommu_spapr_tce.c
@@ -0,0 +1,269 @@
+/*
+ * VFIO: IOMMU DMA mapping support for TCE on POWER
+ *
+ * Copyright (C) 2012 IBM Corp.  All rights reserved.
+ *     Author: Alexey Kardashevskiy <aik@ozlabs.ru>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Derived from original vfio_iommu_type1.c:
+ * Copyright (C) 2012 Red Hat, Inc.  All rights reserved.
+ *     Author: Alex Williamson <alex.williamson@redhat.com>
+ */
+
+#include <linux/module.h>
+#include <linux/pci.h>
+#include <linux/slab.h>
+#include <linux/uaccess.h>
+#include <linux/err.h>
+#include <linux/vfio.h>
+#include <asm/iommu.h>
+#include <asm/tce.h>
+
+#define DRIVER_VERSION  "0.1"
+#define DRIVER_AUTHOR   "aik@ozlabs.ru"
+#define DRIVER_DESC     "VFIO IOMMU SPAPR TCE"
+
+static void tce_iommu_detach_group(void *iommu_data,
+		struct iommu_group *iommu_group);
+
+/*
+ * VFIO IOMMU fd for SPAPR_TCE IOMMU implementation
+ *
+ * This code handles mapping and unmapping of user data buffers
+ * into DMA'ble space using the IOMMU
+ */
+
+/*
+ * The container descriptor supports only a single group per container.
+ * Required by the API as the container is not supplied with the IOMMU group
+ * at the moment of initialization.
+ */
+struct tce_container {
+	struct mutex lock;
+	struct iommu_table *tbl;
+};
+
+static void *tce_iommu_open(unsigned long arg)
+{
+	struct tce_container *container;
+
+	if (arg != VFIO_SPAPR_TCE_IOMMU) {
+		pr_err("tce_vfio: Wrong IOMMU type\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	container = kzalloc(sizeof(*container), GFP_KERNEL);
+	if (!container)
+		return ERR_PTR(-ENOMEM);
+
+	mutex_init(&container->lock);
+
+	return container;
+}
+
+static void tce_iommu_release(void *iommu_data)
+{
+	struct tce_container *container = iommu_data;
+
+	WARN_ON(container->tbl && !container->tbl->it_group);
+	if (container->tbl && container->tbl->it_group)
+		tce_iommu_detach_group(iommu_data, container->tbl->it_group);
+
+	mutex_destroy(&container->lock);
+
+	kfree(container);
+}
+
+static long tce_iommu_ioctl(void *iommu_data,
+				 unsigned int cmd, unsigned long arg)
+{
+	struct tce_container *container = iommu_data;
+	unsigned long minsz;
+	long ret;
+
+	switch (cmd) {
+	case VFIO_CHECK_EXTENSION:
+		return (arg == VFIO_SPAPR_TCE_IOMMU) ? 1 : 0;
+
+	case VFIO_IOMMU_SPAPR_TCE_GET_INFO: {
+		struct vfio_iommu_spapr_tce_info info;
+		struct iommu_table *tbl = container->tbl;
+
+		if (WARN_ON(!tbl))
+			return -ENXIO;
+
+		minsz = offsetofend(struct vfio_iommu_spapr_tce_info,
+				dma32_window_size);
+
+		if (copy_from_user(&info, (void __user *)arg, minsz))
+			return -EFAULT;
+
+		if (info.argsz < minsz)
+			return -EINVAL;
+
+		info.dma32_window_start = tbl->it_offset << IOMMU_PAGE_SHIFT;
+		info.dma32_window_size = tbl->it_size << IOMMU_PAGE_SHIFT;
+		info.flags = 0;
+
+		if (copy_to_user((void __user *)arg, &info, minsz))
+			return -EFAULT;
+
+		return 0;
+	}
+	case VFIO_IOMMU_MAP_DMA: {
+		vfio_iommu_spapr_tce_dma_map param;
+		struct iommu_table *tbl = container->tbl;
+		unsigned long tce;
+
+		if (WARN_ON(!tbl))
+			return -ENXIO;
+
+		minsz = offsetofend(vfio_iommu_spapr_tce_dma_map, size);
+
+		if (copy_from_user(&param, (void __user *)arg, minsz))
+			return -EFAULT;
+
+		if (param.argsz < minsz)
+			return -EINVAL;
+
+		if (param.flags & ~(VFIO_DMA_MAP_FLAG_READ |
+				VFIO_DMA_MAP_FLAG_WRITE))
+			return -EINVAL;
+
+		if ((param.size & ~IOMMU_PAGE_MASK) ||
+				(param.vaddr & ~IOMMU_PAGE_MASK))
+			return -EINVAL;
+
+		/* TODO: support multiple TCEs */
+		if (param.size != IOMMU_PAGE_SIZE) {
+			pr_err("VFIO map on POWER supports only %lu page size\n",
+					IOMMU_PAGE_SIZE);
+			return -EINVAL;
+		}
+
+		/* iova is checked by the IOMMU API */
+		tce = param.vaddr;
+		if (param.flags & VFIO_DMA_MAP_FLAG_READ)
+			tce |= TCE_PCI_READ;
+		if (param.flags & VFIO_DMA_MAP_FLAG_WRITE)
+			tce |= TCE_PCI_WRITE;
+
+		ret = iommu_put_tce_user_mode(tbl, param.iova, tce);
+		iommu_flush_tce(tbl);
+
+		return ret;
+	}
+	case VFIO_IOMMU_UNMAP_DMA: {
+		vfio_iommu_spapr_tce_dma_unmap param;
+		struct iommu_table *tbl = container->tbl;
+
+		if (WARN_ON(!tbl))
+			return -ENXIO;
+
+		minsz = offsetofend(vfio_iommu_spapr_tce_dma_unmap, size);
+
+		if (copy_from_user(&param, (void __user *)arg, minsz))
+			return -EFAULT;
+
+		if (param.argsz < minsz)
+			return -EINVAL;
+
+		/* No flag is supported now */
+		if (param.flags)
+			return -EINVAL;
+
+		if (param.size & ~IOMMU_PAGE_MASK)
+			return -EINVAL;
+
+		/* iova is checked by the IOMMU API */
+		ret = iommu_clear_tce_user_mode(tbl, param.iova, 0,
+				param.size >> IOMMU_PAGE_SHIFT);
+		iommu_flush_tce(tbl);
+
+		return ret;
+	}
+	}
+
+	return -ENOTTY;
+}
+
+static int tce_iommu_attach_group(void *iommu_data,
+		struct iommu_group *iommu_group)
+{
+	int ret;
+	struct tce_container *container = iommu_data;
+	struct iommu_table *tbl = iommu_group_get_iommudata(iommu_group);
+
+	BUG_ON(!tbl);
+	mutex_lock(&container->lock);
+	pr_debug("tce_vfio: Attaching group #%u to iommu %p\n",
+			iommu_group_id(iommu_group), iommu_group);
+	if (container->tbl) {
+		pr_warn("tce_vfio: Only one group per IOMMU container is allowed, existing id=%d, attaching id=%d\n",
+				iommu_group_id(container->tbl->it_group),
+				iommu_group_id(iommu_group));
+		mutex_unlock(&container->lock);
+		return -EBUSY;
+	}
+
+	container->tbl = tbl;
+	ret = iommu_lock_table(tbl, true);
+	mutex_unlock(&container->lock);
+
+	return ret;
+}
+
+static void tce_iommu_detach_group(void *iommu_data,
+		struct iommu_group *iommu_group)
+{
+	struct tce_container *container = iommu_data;
+	struct iommu_table *tbl = iommu_group_get_iommudata(iommu_group);
+
+	BUG_ON(!tbl);
+	mutex_lock(&container->lock);
+	if (tbl != container->tbl) {
+		pr_warn("tce_vfio: detaching group #%u, expected group is #%u\n",
+				iommu_group_id(iommu_group),
+				iommu_group_id(tbl->it_group));
+	} else {
+
+		pr_debug("tce_vfio: detaching group #%u from iommu %p\n",
+				iommu_group_id(iommu_group), iommu_group);
+
+		container->tbl = NULL;
+		iommu_lock_table(tbl, false);
+	}
+	mutex_unlock(&container->lock);
+}
+
+const struct vfio_iommu_driver_ops tce_iommu_driver_ops = {
+	.name		= "iommu-vfio-powerpc",
+	.owner		= THIS_MODULE,
+	.open		= tce_iommu_open,
+	.release	= tce_iommu_release,
+	.ioctl		= tce_iommu_ioctl,
+	.attach_group	= tce_iommu_attach_group,
+	.detach_group	= tce_iommu_detach_group,
+};
+
+static int __init tce_iommu_init(void)
+{
+	return vfio_register_iommu_driver(&tce_iommu_driver_ops);
+}
+
+static void __exit tce_iommu_cleanup(void)
+{
+	vfio_unregister_iommu_driver(&tce_iommu_driver_ops);
+}
+
+module_init(tce_iommu_init);
+module_exit(tce_iommu_cleanup);
+
+MODULE_VERSION(DRIVER_VERSION);
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR(DRIVER_AUTHOR);
+MODULE_DESCRIPTION(DRIVER_DESC);
+
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 4758d1b..ea9a9a7 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -22,6 +22,7 @@
 /* Extensions */
 
 #define VFIO_TYPE1_IOMMU		1
+#define VFIO_SPAPR_TCE_IOMMU		2
 
 /*
  * The IOCTL interface is designed for extensibility by embedding the
@@ -365,4 +366,34 @@ struct vfio_iommu_type1_dma_unmap {
 
 #define VFIO_IOMMU_UNMAP_DMA _IO(VFIO_TYPE, VFIO_BASE + 14)
 
+/* -------- Additional API for SPAPR TCE (Server POWERPC) IOMMU -------- */
+
+/*
+ * The SPAPR TCE info struct provides the information about the PCI bus
+ * address ranges available for DMA, these values are programmed into
+ * the hardware so the guest has to know that information.
+ *
+ * The DMA 32 bit window start is an absolute PCI bus address.
+ * The IOVA address passed via map/unmap ioctls are absolute PCI bus
+ * addresses too so the window works as a filter rather than an offset
+ * for IOVA addresses.
+ *
+ * A flag will need to be added if other page sizes are supported,
+ * so as defined here, it is always 4k.
+ */
+struct vfio_iommu_spapr_tce_info {
+	__u32 argsz;
+	__u32 flags;			/* reserved for future use */
+	__u32 dma32_window_start;	/* 32 bit window start (bytes) */
+	__u32 dma32_window_size;	/* 32 bit window size (bytes) */
+};
+
+#define VFIO_IOMMU_SPAPR_TCE_GET_INFO	_IO(VFIO_TYPE, VFIO_BASE + 12)
+
+/* Reuse type1 map/unmap structs as they are the same at the moment */
+typedef struct vfio_iommu_type1_dma_map vfio_iommu_spapr_tce_dma_map;
+typedef struct vfio_iommu_type1_dma_unmap vfio_iommu_spapr_tce_dma_unmap;
+
+/* ***************************************************************** */
+
 #endif /* _UAPIVFIO_H */
-- 
1.7.10.4

Re: [PATCH 1/2] vfio powerpc: enabled on powernv platform

[Alex Williamson]

On Mon, 2013-02-11 at 22:54 +1100, Alexey Kardashevskiy wrote:
> This patch initializes IOMMU groups based on the IOMMU
> configuration discovered during the PCI scan on POWERNV
> (POWER non virtualized) platform. The IOMMU groups are
> to be used later by VFIO driver (PCI pass through).
> 
> It also implements an API for mapping/unmapping pages for
> guest PCI drivers and providing DMA window properties.
> This API is going to be used later by QEMU-VFIO to handle
> h_put_tce hypercalls from the KVM guest.
> 
> The iommu_put_tce_user_mode() does only a single page mapping
> as an API for adding many mappings at once is going to be
> added later.
> 
> Although this driver has been tested only on the POWERNV
> platform, it should work on any platform which supports
> TCE tables. As h_put_tce hypercall is received by the host
> kernel and processed by the QEMU (what involves calling
> the host kernel again), performance is not the best -
> circa 220MB/s on 10Gb ethernet network.
> 
> To enable VFIO on POWER, enable SPAPR_TCE_IOMMU config
> option and configure VFIO as required.
> 
> Cc: David Gibson <david@gibson.dropbear.id.au>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

Yay, it's not dead! ;)

I'd love some kind of changelog to know what to look for in here,
especially given 2mo since the last version.

> ---
>  arch/powerpc/include/asm/iommu.h            |   15 ++
>  arch/powerpc/kernel/iommu.c                 |  343 +++++++++++++++++++++++++++
>  arch/powerpc/platforms/powernv/pci-ioda.c   |    1 +
>  arch/powerpc/platforms/powernv/pci-p5ioc2.c |    5 +-
>  arch/powerpc/platforms/powernv/pci.c        |    3 +
>  drivers/iommu/Kconfig                       |    8 +
>  6 files changed, 374 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
> index cbfe678..900294b 100644
> --- a/arch/powerpc/include/asm/iommu.h
> +++ b/arch/powerpc/include/asm/iommu.h
> @@ -76,6 +76,9 @@ struct iommu_table {
>  	struct iommu_pool large_pool;
>  	struct iommu_pool pools[IOMMU_NR_POOLS];
>  	unsigned long *it_map;       /* A simple allocation bitmap for now */
> +#ifdef CONFIG_IOMMU_API
> +	struct iommu_group *it_group;
> +#endif
>  };
>  
>  struct scatterlist;
> @@ -98,6 +101,8 @@ extern void iommu_free_table(struct iommu_table *tbl, const char *node_name);
>   */
>  extern struct iommu_table *iommu_init_table(struct iommu_table * tbl,
>  					    int nid);
> +extern void iommu_register_group(struct iommu_table * tbl,
> +				 int domain_number, unsigned long pe_num);
>  
>  extern int iommu_map_sg(struct device *dev, struct iommu_table *tbl,
>  			struct scatterlist *sglist, int nelems,
> @@ -147,5 +152,15 @@ static inline void iommu_restore(void)
>  }
>  #endif
>  
> +/* The API to support IOMMU operations for VFIO */
> +extern long iommu_clear_tce_user_mode(struct iommu_table *tbl,
> +		unsigned long ioba, unsigned long tce_value,
> +		unsigned long npages);
> +extern long iommu_put_tce_user_mode(struct iommu_table *tbl,
> +		unsigned long ioba, unsigned long tce);
> +
> +extern void iommu_flush_tce(struct iommu_table *tbl);
> +extern long iommu_lock_table(struct iommu_table *tbl, bool lock);
> +
>  #endif /* __KERNEL__ */
>  #endif /* _ASM_IOMMU_H */
> diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
> index 7c309fe..b4fdabc 100644
> --- a/arch/powerpc/kernel/iommu.c
> +++ b/arch/powerpc/kernel/iommu.c
> @@ -37,6 +37,7 @@
>  #include <linux/fault-inject.h>
>  #include <linux/pci.h>
>  #include <linux/kvm_host.h>
> +#include <linux/iommu.h>
>  #include <asm/io.h>
>  #include <asm/prom.h>
>  #include <asm/iommu.h>
> @@ -45,6 +46,7 @@
>  #include <asm/kdump.h>
>  #include <asm/fadump.h>
>  #include <asm/vio.h>
> +#include <asm/tce.h>
>  
>  #define DBG(...)
>  
> @@ -707,11 +709,39 @@ struct iommu_table *iommu_init_table(struct iommu_table *tbl, int nid)
>  	return tbl;
>  }
>  
> +static void group_release(void *iommu_data)
> +{
> +	struct iommu_table *tbl = iommu_data;
> +	tbl->it_group = NULL;
> +}
> +
> +void iommu_register_group(struct iommu_table * tbl,
> +		int domain_number, unsigned long pe_num)
> +{
> +	struct iommu_group *grp;
> +
> +	grp = iommu_group_alloc();
> +	if (IS_ERR(grp)) {
> +		pr_info("powerpc iommu api: cannot create new group, err=%ld\n",
> +				PTR_ERR(grp));
> +		return;
> +	}
> +	tbl->it_group = grp;
> +	iommu_group_set_iommudata(grp, tbl, group_release);
> +	iommu_group_set_name(grp, kasprintf(GFP_KERNEL, "domain%d-pe%lx",
> +			domain_number, pe_num));
> +}
> +
>  void iommu_free_table(struct iommu_table *tbl, const char *node_name)
>  {
>  	unsigned long bitmap_sz;
>  	unsigned int order;
>  
> +	if (tbl && tbl->it_group) {
> +		iommu_group_put(tbl->it_group);
> +		BUG_ON(tbl->it_group);
> +	}
> +
>  	if (!tbl || !tbl->it_map) {
>  		printk(KERN_ERR "%s: expected TCE map for %s\n", __func__,
>  				node_name);
> @@ -876,4 +906,317 @@ void kvm_iommu_unmap_pages(struct kvm *kvm, struct kvm_memory_slot *slot)
>  {
>  }
>  
> +static enum dma_data_direction tce_direction(unsigned long tce)
> +{
> +	if ((tce & TCE_PCI_READ) && (tce & TCE_PCI_WRITE))
> +		return DMA_BIDIRECTIONAL;
> +	else if (tce & TCE_PCI_READ)
> +		return DMA_TO_DEVICE;
> +	else if (tce & TCE_PCI_WRITE)
> +		return DMA_FROM_DEVICE;
> +	else
> +		return DMA_NONE;
> +}
> +
> +void iommu_flush_tce(struct iommu_table *tbl)
> +{
> +	/* Flush/invalidate TLB caches if necessary */
> +	if (ppc_md.tce_flush)
> +		ppc_md.tce_flush(tbl);
> +
> +	/* Make sure updates are seen by hardware */
> +	mb();
> +}
> +EXPORT_SYMBOL_GPL(iommu_flush_tce);
> +
> +static long tce_clear_param_check(struct iommu_table *tbl,
> +		unsigned long ioba, unsigned long tce_value,
> +		unsigned long npages)
> +{
> +	unsigned long size = npages << IOMMU_PAGE_SHIFT;
> +
> +	/* ppc_md.tce_free() does not support any value but 0 */
> +	if (tce_value)
> +		return -EINVAL;
> +
> +	if (ioba & ~IOMMU_PAGE_MASK)
> +		return -EINVAL;
> +
> +	if ((ioba + size) > ((tbl->it_offset + tbl->it_size)
> +			<< IOMMU_PAGE_SHIFT))
> +		return -EINVAL;
> +
> +	if (ioba < (tbl->it_offset << IOMMU_PAGE_SHIFT))
> +		return -EINVAL;
> +
> +	return 0;

Why do these all return long (vs int)?  Is this a POWER-ism?

> +}
> +
> +static long tce_put_param_check(struct iommu_table *tbl,
> +		unsigned long ioba, unsigned long tce)
> +{
> +	if (!(tce & (TCE_PCI_WRITE | TCE_PCI_READ)))
> +		return -EINVAL;
> +
> +	if (tce & ~(IOMMU_PAGE_MASK | TCE_PCI_WRITE | TCE_PCI_READ))
> +		return -EINVAL;
> +
> +	if (ioba & ~IOMMU_PAGE_MASK)
> +		return -EINVAL;
> +
> +	if ((ioba + IOMMU_PAGE_SIZE) > ((tbl->it_offset + tbl->it_size)
> +			<< IOMMU_PAGE_SHIFT))
> +		return -EINVAL;
> +
> +	if (ioba < (tbl->it_offset << IOMMU_PAGE_SHIFT))
> +		return -EINVAL;
> +
> +	return 0;
> +}
> +
> +static long clear_tce(struct iommu_table *tbl,
> +		unsigned long entry, unsigned long pages)
> +{
> +	unsigned long oldtce;
> +	struct page *page;
> +	struct iommu_pool *pool;
> +
> +	for ( ; pages; --pages, ++entry) {
> +		pool = get_pool(tbl, entry);
> +		spin_lock(&(pool->lock));
> +
> +		oldtce = ppc_md.tce_get(tbl, entry);
> +		if (oldtce & (TCE_PCI_WRITE | TCE_PCI_READ)) {
> +			ppc_md.tce_free(tbl, entry, 1);
> +
> +			page = pfn_to_page(oldtce >> PAGE_SHIFT);
> +			WARN_ON(!page);
> +			if (page) {
> +				if (oldtce & TCE_PCI_WRITE)
> +					SetPageDirty(page);
> +				put_page(page);
> +			}
> +		}
> +		spin_unlock(&(pool->lock));
> +	}
> +
> +	return 0;

No non-zero return, make it void?

> +}
> +
> +long iommu_clear_tce_user_mode(struct iommu_table *tbl, unsigned long ioba,
> +		unsigned long tce_value, unsigned long npages)
> +{
> +	long ret;
> +	unsigned long entry = ioba >> IOMMU_PAGE_SHIFT;
> +
> +	ret = tce_clear_param_check(tbl, ioba, tce_value, npages);
> +	if (!ret)
> +		ret = clear_tce(tbl, entry, npages);
> +
> +	if (ret < 0)
> +		pr_err("iommu_tce: %s failed ioba=%lx, tce_value=%lx ret=%ld\n",
> +				__func__, ioba, tce_value, ret);
> +
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(iommu_clear_tce_user_mode);
> +
> +/* hwaddr is a virtual address here, tce_build converts it to physical */
> +static long do_tce_build(struct iommu_table *tbl, unsigned long entry,
> +		unsigned long hwaddr, enum dma_data_direction direction)
> +{
> +	long ret = -EBUSY;
> +	unsigned long oldtce;
> +	struct iommu_pool *pool = get_pool(tbl, entry);
> +
> +	spin_lock(&(pool->lock));
> +
> +	oldtce = ppc_md.tce_get(tbl, entry);
> +	/* Add new entry if it is not busy */
> +	if (!(oldtce & (TCE_PCI_WRITE | TCE_PCI_READ)))
> +		ret = ppc_md.tce_build(tbl, entry, 1, hwaddr, direction, NULL);
> +
> +	spin_unlock(&(pool->lock));
> +
> +	if (unlikely(ret))
> +		pr_err("iommu_tce: %s failed on hwaddr=%lx ioba=%lx kva=%lx ret=%ld\n",
> +				__func__, hwaddr, entry << IOMMU_PAGE_SHIFT,
> +				hwaddr, ret);
> +
> +	return ret;
> +}
> +
> +static int put_tce_user_mode(struct iommu_table *tbl, unsigned long entry,
> +		unsigned long tce)
> +{
> +	int ret;

Now we're back to returning ints.

> +	struct page *page = NULL;
> +	unsigned long hwaddr, offset = tce & IOMMU_PAGE_MASK & ~PAGE_MASK;
> +	enum dma_data_direction direction = tce_direction(tce);
> +
> +	ret = get_user_pages_fast(tce & PAGE_MASK, 1,
> +			direction != DMA_TO_DEVICE, &page);
> +	if (unlikely(ret != 1)) {
> +		pr_err("iommu_tce: get_user_pages_fast failed tce=%lx ioba=%lx ret=%d\n",
> +				tce, entry << IOMMU_PAGE_SHIFT, ret);
> +		return -EFAULT;
> +	}
> +	hwaddr = (unsigned long) page_address(page) + offset;
> +
> +	ret = do_tce_build(tbl, entry, hwaddr, direction);
> +	if (ret)
> +		put_page(page);
> +
> +	return ret;
> +}
> +
> +long iommu_put_tce_user_mode(struct iommu_table *tbl, unsigned long ioba,
> +		unsigned long tce)
> +{
> +	long ret;

Oops, back to longs.

> +	unsigned long entry = ioba >> IOMMU_PAGE_SHIFT;
> +
> +	ret = tce_put_param_check(tbl, ioba, tce);
> +	if (!ret)
> +		ret = put_tce_user_mode(tbl, entry, tce);
> +
> +	if (ret < 0)
> +		pr_err("iommu_tce: %s failed ioba=%lx, tce=%lx, ret=%ld\n",
> +				__func__, ioba, tce, ret);
> +
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(iommu_put_tce_user_mode);
> +
> +/*
> + * Helpers to do locked pages accounting.
> + * Called from ioctl so down_write_trylock is not necessary.
> + */
> +static void lock_acct(long npage)
> +{
> +	if (!current->mm)
> +		return; /* process exited */
> +
> +	down_write(&current->mm->mmap_sem);
> +	current->mm->locked_vm += npage;
> +	up_write(&current->mm->mmap_sem);
> +}
> +
> +/*
> + * iommu_lock_table - Start/stop using the table by VFIO
> + * @tbl: Pointer to the IOMMU table
> + * @lock: true when VFIO starts using the table
> + */
> +long iommu_lock_table(struct iommu_table *tbl, bool lock)
> +{
> +	unsigned long sz = (tbl->it_size + 7) >> 3;
> +	unsigned long locked, lock_limit;
> +
> +	if (lock) {
> +		/*
> +		 * Account for locked pages
> +		 * The worst case is when every IOMMU page
> +		 * is mapped to separate system page
> +		 */
> +		locked = current->mm->locked_vm + tbl->it_size;
> +		lock_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
> +		if (locked > lock_limit && !capable(CAP_IPC_LOCK)) {
> +			pr_warn("RLIMIT_MEMLOCK (%ld) exceeded\n",
> +					rlimit(RLIMIT_MEMLOCK));
> +			return -ENOMEM;
> +		}
> +
> +		if (tbl->it_offset == 0)
> +			clear_bit(0, tbl->it_map);
> +
> +		if (!bitmap_empty(tbl->it_map, tbl->it_size)) {
> +			pr_err("iommu_tce: it_map is not empty");
> +			return -EBUSY;
> +		}
> +
> +		lock_acct(tbl->it_size);
> +		memset(tbl->it_map, 0xff, sz);
> +	}
> +
> +	/* Clear TCE table */
> +	clear_tce(tbl, tbl->it_offset, tbl->it_size);
> +
> +	if (!lock) {
> +		lock_acct(-tbl->it_size);
> +		memset(tbl->it_map, 0, sz);
> +
> +		/* Restore bit#0 set by iommu_init_table() */
> +		if (tbl->it_offset == 0)
> +			set_bit(0, tbl->it_map);
> +	}
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(iommu_lock_table);
> +
> +int iommu_add_device(struct device *dev)
> +{
> +	struct iommu_table *tbl;
> +	int ret = 0;
> +
> +	if (WARN_ON(dev->iommu_group)) {
> +		pr_warn("iommu_tce: device %s is already in iommu group %d, skipping\n",
> +				dev_name(dev),
> +				iommu_group_id(dev->iommu_group));
> +		return -EBUSY;
> +	}
> +
> +	tbl = get_iommu_table_base(dev);
> +	if (!tbl) {
> +		pr_debug("iommu_tce: skipping device %s with no tbl\n",
> +				dev_name(dev));
> +		return 0;
> +	}
> +
> +	pr_debug("iommu_tce: adding %s to iommu group %d\n",
> +			dev_name(dev), iommu_group_id(tbl->it_group));
> +
> +	ret = iommu_group_add_device(tbl->it_group, dev);
> +	if (ret < 0)
> +		pr_err("iommu_tce: %s has not been added, ret=%d\n",
> +				dev_name(dev), ret);
> +
> +	return ret;
> +}
> +
> +void iommu_del_device(struct device *dev)
> +{
> +	iommu_group_remove_device(dev);
> +}
> +
> +static int iommu_bus_notifier(struct notifier_block *nb,
> +			      unsigned long action, void *data)
> +{
> +	struct device *dev = data;
> +
> +	switch (action) {
> +	case BUS_NOTIFY_ADD_DEVICE:
> +		return iommu_add_device(dev);
> +	case BUS_NOTIFY_DEL_DEVICE:
> +		iommu_del_device(dev);
> +		return 0;
> +	default:
> +		return 0;
> +	}
> +}
> +
> +static struct notifier_block tce_iommu_bus_nb = {
> +	.notifier_call = iommu_bus_notifier,
> +};
> +
> +static int __init tce_iommu_init(void)
> +{
> +	BUILD_BUG_ON(PAGE_SIZE < IOMMU_PAGE_SIZE);
> +
> +	bus_register_notifier(&pci_bus_type, &tce_iommu_bus_nb);
> +	return 0;
> +}
> +
> +arch_initcall(tce_iommu_init);
> +
>  #endif /* CONFIG_IOMMU_API */
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
> index 8e90e89..04dbc49 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -522,6 +522,7 @@ static void pnv_pci_ioda_setup_dma_pe(struct pnv_phb *phb,
>  			| TCE_PCI_SWINV_PAIR;
>  	}
>  	iommu_init_table(tbl, phb->hose->node);
> +	iommu_register_group(tbl, pci_domain_nr(pe->pbus), pe->pe_number);
>  
>  	if (pe->pdev)
>  		set_iommu_table_base(&pe->pdev->dev, tbl);
> diff --git a/arch/powerpc/platforms/powernv/pci-p5ioc2.c b/arch/powerpc/platforms/powernv/pci-p5ioc2.c
> index abe6780..7ce75b0 100644
> --- a/arch/powerpc/platforms/powernv/pci-p5ioc2.c
> +++ b/arch/powerpc/platforms/powernv/pci-p5ioc2.c
> @@ -87,8 +87,11 @@ static void pnv_pci_init_p5ioc2_msis(struct pnv_phb *phb) { }
>  static void pnv_pci_p5ioc2_dma_dev_setup(struct pnv_phb *phb,
>  					 struct pci_dev *pdev)
>  {
> -	if (phb->p5ioc2.iommu_table.it_map == NULL)
> +	if (phb->p5ioc2.iommu_table.it_map == NULL) {
>  		iommu_init_table(&phb->p5ioc2.iommu_table, phb->hose->node);
> +		iommu_register_group(&phb->p5ioc2.iommu_table,
> +				pci_domain_nr(phb->hose->bus), phb->opal_id);
> +	}
>  
>  	set_iommu_table_base(&pdev->dev, &phb->p5ioc2.iommu_table);
>  }
> diff --git a/arch/powerpc/platforms/powernv/pci.c b/arch/powerpc/platforms/powernv/pci.c
> index f60a188..d112701 100644
> --- a/arch/powerpc/platforms/powernv/pci.c
> +++ b/arch/powerpc/platforms/powernv/pci.c
> @@ -20,6 +20,7 @@
>  #include <linux/irq.h>
>  #include <linux/io.h>
>  #include <linux/msi.h>
> +#include <linux/iommu.h>
>  
>  #include <asm/sections.h>
>  #include <asm/io.h>
> @@ -503,6 +504,7 @@ static struct iommu_table *pnv_pci_setup_bml_iommu(struct pci_controller *hose)
>  	pnv_pci_setup_iommu_table(tbl, __va(be64_to_cpup(basep)),
>  				  be32_to_cpup(sizep), 0);
>  	iommu_init_table(tbl, hose->node);
> +	iommu_register_group(tbl, pci_domain_nr(hose->bus), 0);
>  
>  	/* Deal with SW invalidated TCEs when needed (BML way) */
>  	swinvp = of_get_property(hose->dn, "linux,tce-sw-invalidate-info",
> @@ -631,3 +633,4 @@ void __init pnv_pci_init(void)
>  	ppc_md.teardown_msi_irqs = pnv_teardown_msi_irqs;
>  #endif
>  }
> +

stray newline

> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index e39f9db..ce6b186 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -187,4 +187,12 @@ config EXYNOS_IOMMU_DEBUG
>  
>  	  Say N unless you need kernel log message for IOMMU debugging
>  
> +config SPAPR_TCE_IOMMU
> +	bool "sPAPR TCE IOMMU Support"
> +	depends on PPC_POWERNV
> +	select IOMMU_API
> +	help
> +	  Enables bits of IOMMU API required by VFIO. The iommu_ops is
> +	  still not implemented.
> +
>  endif # IOMMU_SUPPORT

Looks mostly ok to me other than the minor notes.  As mentioned
previously, this one needs to go in through power maintainers before I
can include 2/2 .  Thanks,

Alex

Re: [PATCH 2/2] vfio powerpc: implemented IOMMU driver for VFIO

[Alex Williamson]

On Mon, 2013-02-11 at 22:54 +1100, Alexey Kardashevskiy wrote:
> VFIO implements platform independent stuff such as
> a PCI driver, BAR access (via read/write on a file descriptor
> or direct mapping when possible) and IRQ signaling.
> 
> The platform dependent part includes IOMMU initialization
> and handling. This patch implements an IOMMU driver for VFIO
> which does mapping/unmapping pages for the guest IO and
> provides information about DMA window (required by a POWERPC
> guest).
> 
> The counterpart in QEMU is required to support this functionality.

Revision info would be great here too.

> Cc: David Gibson <david@gibson.dropbear.id.au>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
>  drivers/vfio/Kconfig                |    6 +
>  drivers/vfio/Makefile               |    1 +
>  drivers/vfio/vfio_iommu_spapr_tce.c |  269 +++++++++++++++++++++++++++++++++++
>  include/uapi/linux/vfio.h           |   31 ++++
>  4 files changed, 307 insertions(+)
>  create mode 100644 drivers/vfio/vfio_iommu_spapr_tce.c
> 
> diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
> index 7cd5dec..b464687 100644
> --- a/drivers/vfio/Kconfig
> +++ b/drivers/vfio/Kconfig
> @@ -3,10 +3,16 @@ config VFIO_IOMMU_TYPE1
>  	depends on VFIO
>  	default n
>  
> +config VFIO_IOMMU_SPAPR_TCE
> +	tristate
> +	depends on VFIO && SPAPR_TCE_IOMMU
> +	default n
> +
>  menuconfig VFIO
>  	tristate "VFIO Non-Privileged userspace driver framework"
>  	depends on IOMMU_API
>  	select VFIO_IOMMU_TYPE1 if X86
> +	select VFIO_IOMMU_SPAPR_TCE if PPC_POWERNV
>  	help
>  	  VFIO provides a framework for secure userspace device drivers.
>  	  See Documentation/vfio.txt for more details.
> diff --git a/drivers/vfio/Makefile b/drivers/vfio/Makefile
> index 2398d4a..72bfabc 100644
> --- a/drivers/vfio/Makefile
> +++ b/drivers/vfio/Makefile
> @@ -1,3 +1,4 @@
>  obj-$(CONFIG_VFIO) += vfio.o
>  obj-$(CONFIG_VFIO_IOMMU_TYPE1) += vfio_iommu_type1.o
> +obj-$(CONFIG_VFIO_IOMMU_SPAPR_TCE) += vfio_iommu_spapr_tce.o
>  obj-$(CONFIG_VFIO_PCI) += pci/
> diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c b/drivers/vfio/vfio_iommu_spapr_tce.c
> new file mode 100644
> index 0000000..9b3fa88
> --- /dev/null
> +++ b/drivers/vfio/vfio_iommu_spapr_tce.c
> @@ -0,0 +1,269 @@
> +/*
> + * VFIO: IOMMU DMA mapping support for TCE on POWER
> + *
> + * Copyright (C) 2012 IBM Corp.  All rights reserved.

2013 now

> + *     Author: Alexey Kardashevskiy <aik@ozlabs.ru>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * Derived from original vfio_iommu_type1.c:
> + * Copyright (C) 2012 Red Hat, Inc.  All rights reserved.
> + *     Author: Alex Williamson <alex.williamson@redhat.com>
> + */
> +
> +#include <linux/module.h>
> +#include <linux/pci.h>
> +#include <linux/slab.h>
> +#include <linux/uaccess.h>
> +#include <linux/err.h>
> +#include <linux/vfio.h>
> +#include <asm/iommu.h>
> +#include <asm/tce.h>
> +
> +#define DRIVER_VERSION  "0.1"
> +#define DRIVER_AUTHOR   "aik@ozlabs.ru"
> +#define DRIVER_DESC     "VFIO IOMMU SPAPR TCE"
> +
> +static void tce_iommu_detach_group(void *iommu_data,
> +		struct iommu_group *iommu_group);
> +
> +/*
> + * VFIO IOMMU fd for SPAPR_TCE IOMMU implementation
> + *
> + * This code handles mapping and unmapping of user data buffers
> + * into DMA'ble space using the IOMMU
> + */
> +
> +/*
> + * The container descriptor supports only a single group per container.
> + * Required by the API as the container is not supplied with the IOMMU group
> + * at the moment of initialization.
> + */
> +struct tce_container {
> +	struct mutex lock;
> +	struct iommu_table *tbl;
> +};
> +
> +static void *tce_iommu_open(unsigned long arg)
> +{
> +	struct tce_container *container;
> +
> +	if (arg != VFIO_SPAPR_TCE_IOMMU) {
> +		pr_err("tce_vfio: Wrong IOMMU type\n");
> +		return ERR_PTR(-EINVAL);
> +	}
> +
> +	container = kzalloc(sizeof(*container), GFP_KERNEL);
> +	if (!container)
> +		return ERR_PTR(-ENOMEM);
> +
> +	mutex_init(&container->lock);
> +
> +	return container;
> +}
> +
> +static void tce_iommu_release(void *iommu_data)
> +{
> +	struct tce_container *container = iommu_data;
> +
> +	WARN_ON(container->tbl && !container->tbl->it_group);
> +	if (container->tbl && container->tbl->it_group)
> +		tce_iommu_detach_group(iommu_data, container->tbl->it_group);
> +
> +	mutex_destroy(&container->lock);
> +
> +	kfree(container);
> +}
> +
> +static long tce_iommu_ioctl(void *iommu_data,
> +				 unsigned int cmd, unsigned long arg)
> +{
> +	struct tce_container *container = iommu_data;
> +	unsigned long minsz;
> +	long ret;
> +
> +	switch (cmd) {
> +	case VFIO_CHECK_EXTENSION:
> +		return (arg == VFIO_SPAPR_TCE_IOMMU) ? 1 : 0;
> +
> +	case VFIO_IOMMU_SPAPR_TCE_GET_INFO: {
> +		struct vfio_iommu_spapr_tce_info info;
> +		struct iommu_table *tbl = container->tbl;
> +
> +		if (WARN_ON(!tbl))
> +			return -ENXIO;
> +
> +		minsz = offsetofend(struct vfio_iommu_spapr_tce_info,
> +				dma32_window_size);
> +
> +		if (copy_from_user(&info, (void __user *)arg, minsz))
> +			return -EFAULT;
> +
> +		if (info.argsz < minsz)
> +			return -EINVAL;
> +
> +		info.dma32_window_start = tbl->it_offset << IOMMU_PAGE_SHIFT;
> +		info.dma32_window_size = tbl->it_size << IOMMU_PAGE_SHIFT;
> +		info.flags = 0;
> +
> +		if (copy_to_user((void __user *)arg, &info, minsz))
> +			return -EFAULT;
> +
> +		return 0;
> +	}
> +	case VFIO_IOMMU_MAP_DMA: {
> +		vfio_iommu_spapr_tce_dma_map param;
> +		struct iommu_table *tbl = container->tbl;
> +		unsigned long tce;
> +
> +		if (WARN_ON(!tbl))
> +			return -ENXIO;
> +
> +		minsz = offsetofend(vfio_iommu_spapr_tce_dma_map, size);
> +
> +		if (copy_from_user(&param, (void __user *)arg, minsz))
> +			return -EFAULT;
> +
> +		if (param.argsz < minsz)
> +			return -EINVAL;
> +
> +		if (param.flags & ~(VFIO_DMA_MAP_FLAG_READ |
> +				VFIO_DMA_MAP_FLAG_WRITE))
> +			return -EINVAL;
> +
> +		if ((param.size & ~IOMMU_PAGE_MASK) ||
> +				(param.vaddr & ~IOMMU_PAGE_MASK))
> +			return -EINVAL;
> +
> +		/* TODO: support multiple TCEs */
> +		if (param.size != IOMMU_PAGE_SIZE) {

Ouch, ioctl per page...

> +			pr_err("VFIO map on POWER supports only %lu page size\n",
> +					IOMMU_PAGE_SIZE);
> +			return -EINVAL;
> +		}
> +
> +		/* iova is checked by the IOMMU API */
> +		tce = param.vaddr;
> +		if (param.flags & VFIO_DMA_MAP_FLAG_READ)
> +			tce |= TCE_PCI_READ;
> +		if (param.flags & VFIO_DMA_MAP_FLAG_WRITE)
> +			tce |= TCE_PCI_WRITE;
> +
> +		ret = iommu_put_tce_user_mode(tbl, param.iova, tce);
> +		iommu_flush_tce(tbl);
> +
> +		return ret;
> +	}
> +	case VFIO_IOMMU_UNMAP_DMA: {
> +		vfio_iommu_spapr_tce_dma_unmap param;
> +		struct iommu_table *tbl = container->tbl;
> +
> +		if (WARN_ON(!tbl))
> +			return -ENXIO;
> +
> +		minsz = offsetofend(vfio_iommu_spapr_tce_dma_unmap, size);
> +
> +		if (copy_from_user(&param, (void __user *)arg, minsz))
> +			return -EFAULT;
> +
> +		if (param.argsz < minsz)
> +			return -EINVAL;
> +
> +		/* No flag is supported now */
> +		if (param.flags)
> +			return -EINVAL;
> +
> +		if (param.size & ~IOMMU_PAGE_MASK)
> +			return -EINVAL;

But you support multi-page unmaps?

> +
> +		/* iova is checked by the IOMMU API */
> +		ret = iommu_clear_tce_user_mode(tbl, param.iova, 0,
> +				param.size >> IOMMU_PAGE_SHIFT);
> +		iommu_flush_tce(tbl);
> +
> +		return ret;
> +	}
> +	}
> +
> +	return -ENOTTY;
> +}
> +
> +static int tce_iommu_attach_group(void *iommu_data,
> +		struct iommu_group *iommu_group)
> +{
> +	int ret;
> +	struct tce_container *container = iommu_data;
> +	struct iommu_table *tbl = iommu_group_get_iommudata(iommu_group);
> +
> +	BUG_ON(!tbl);
> +	mutex_lock(&container->lock);
> +	pr_debug("tce_vfio: Attaching group #%u to iommu %p\n",
> +			iommu_group_id(iommu_group), iommu_group);
> +	if (container->tbl) {
> +		pr_warn("tce_vfio: Only one group per IOMMU container is allowed, existing id=%d, attaching id=%d\n",
> +				iommu_group_id(container->tbl->it_group),
> +				iommu_group_id(iommu_group));
> +		mutex_unlock(&container->lock);
> +		return -EBUSY;
> +	}
> +
> +	container->tbl = tbl;
> +	ret = iommu_lock_table(tbl, true);

Bug, container->tbl is set regardless of iommu_lock_table.

Ok, so now we're checking rlimits and handling page accounting on
VFIO_GROUP_SET_CONTAINER to avoid any overhead at map/unmap.  How can
the user learn tbl->it_size to set their locked page limit prior to
this?  It's available from GET_INFO, but there's a chicken and egg
problem that to get it there you have to get past this, which means
you're already ok.  Maybe it's in sysfs somewhere already or it could be
exposed in the iommu group like the name attribute.  Otherwise we might
consider doing locking on first mapping.  Thanks,

Alex

> +	mutex_unlock(&container->lock);
> +
> +	return ret;
> +}
> +
> +static void tce_iommu_detach_group(void *iommu_data,
> +		struct iommu_group *iommu_group)
> +{
> +	struct tce_container *container = iommu_data;
> +	struct iommu_table *tbl = iommu_group_get_iommudata(iommu_group);
> +
> +	BUG_ON(!tbl);
> +	mutex_lock(&container->lock);
> +	if (tbl != container->tbl) {
> +		pr_warn("tce_vfio: detaching group #%u, expected group is #%u\n",
> +				iommu_group_id(iommu_group),
> +				iommu_group_id(tbl->it_group));
> +	} else {
> +
> +		pr_debug("tce_vfio: detaching group #%u from iommu %p\n",
> +				iommu_group_id(iommu_group), iommu_group);
> +
> +		container->tbl = NULL;
> +		iommu_lock_table(tbl, false);
> +	}
> +	mutex_unlock(&container->lock);
> +}
> +
> +const struct vfio_iommu_driver_ops tce_iommu_driver_ops = {
> +	.name		= "iommu-vfio-powerpc",
> +	.owner		= THIS_MODULE,
> +	.open		= tce_iommu_open,
> +	.release	= tce_iommu_release,
> +	.ioctl		= tce_iommu_ioctl,
> +	.attach_group	= tce_iommu_attach_group,
> +	.detach_group	= tce_iommu_detach_group,
> +};
> +
> +static int __init tce_iommu_init(void)
> +{
> +	return vfio_register_iommu_driver(&tce_iommu_driver_ops);
> +}
> +
> +static void __exit tce_iommu_cleanup(void)
> +{
> +	vfio_unregister_iommu_driver(&tce_iommu_driver_ops);
> +}
> +
> +module_init(tce_iommu_init);
> +module_exit(tce_iommu_cleanup);
> +
> +MODULE_VERSION(DRIVER_VERSION);
> +MODULE_LICENSE("GPL v2");
> +MODULE_AUTHOR(DRIVER_AUTHOR);
> +MODULE_DESCRIPTION(DRIVER_DESC);
> +
> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> index 4758d1b..ea9a9a7 100644
> --- a/include/uapi/linux/vfio.h
> +++ b/include/uapi/linux/vfio.h
> @@ -22,6 +22,7 @@
>  /* Extensions */
>  
>  #define VFIO_TYPE1_IOMMU		1
> +#define VFIO_SPAPR_TCE_IOMMU		2
>  
>  /*
>   * The IOCTL interface is designed for extensibility by embedding the
> @@ -365,4 +366,34 @@ struct vfio_iommu_type1_dma_unmap {
>  
>  #define VFIO_IOMMU_UNMAP_DMA _IO(VFIO_TYPE, VFIO_BASE + 14)
>  
> +/* -------- Additional API for SPAPR TCE (Server POWERPC) IOMMU -------- */
> +
> +/*
> + * The SPAPR TCE info struct provides the information about the PCI bus
> + * address ranges available for DMA, these values are programmed into
> + * the hardware so the guest has to know that information.
> + *
> + * The DMA 32 bit window start is an absolute PCI bus address.
> + * The IOVA address passed via map/unmap ioctls are absolute PCI bus
> + * addresses too so the window works as a filter rather than an offset
> + * for IOVA addresses.
> + *
> + * A flag will need to be added if other page sizes are supported,
> + * so as defined here, it is always 4k.
> + */
> +struct vfio_iommu_spapr_tce_info {
> +	__u32 argsz;
> +	__u32 flags;			/* reserved for future use */
> +	__u32 dma32_window_start;	/* 32 bit window start (bytes) */
> +	__u32 dma32_window_size;	/* 32 bit window size (bytes) */
> +};
> +
> +#define VFIO_IOMMU_SPAPR_TCE_GET_INFO	_IO(VFIO_TYPE, VFIO_BASE + 12)
> +
> +/* Reuse type1 map/unmap structs as they are the same at the moment */
> +typedef struct vfio_iommu_type1_dma_map vfio_iommu_spapr_tce_dma_map;
> +typedef struct vfio_iommu_type1_dma_unmap vfio_iommu_spapr_tce_dma_unmap;
> +
> +/* ***************************************************************** */
> +
>  #endif /* _UAPIVFIO_H */

Re: [PATCH 1/2] vfio powerpc: enabled on powernv platform

[Alexey Kardashevskiy]

On 12/02/13 09:16, Alex Williamson wrote:
> On Mon, 2013-02-11 at 22:54 +1100, Alexey Kardashevskiy wrote:
>> This patch initializes IOMMU groups based on the IOMMU
>> configuration discovered during the PCI scan on POWERNV
>> (POWER non virtualized) platform. The IOMMU groups are
>> to be used later by VFIO driver (PCI pass through).
>>
>> It also implements an API for mapping/unmapping pages for
>> guest PCI drivers and providing DMA window properties.
>> This API is going to be used later by QEMU-VFIO to handle
>> h_put_tce hypercalls from the KVM guest.
>>
>> The iommu_put_tce_user_mode() does only a single page mapping
>> as an API for adding many mappings at once is going to be
>> added later.
>>
>> Although this driver has been tested only on the POWERNV
>> platform, it should work on any platform which supports
>> TCE tables. As h_put_tce hypercall is received by the host
>> kernel and processed by the QEMU (what involves calling
>> the host kernel again), performance is not the best -
>> circa 220MB/s on 10Gb ethernet network.
>>
>> To enable VFIO on POWER, enable SPAPR_TCE_IOMMU config
>> option and configure VFIO as required.
>>
>> Cc: David Gibson <david@gibson.dropbear.id.au>
>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>
> Yay, it's not dead! ;)

No, still alive :) I have been implementing real mode and multiple pages 
support (for real mode too) so I changed the interface a bit as I did not 
realize some bits from the powerpc arch.


> I'd love some kind of changelog to know what to look for in here,
> especially given 2mo since the last version.

There is no serious change actually.

>> ---
>>   arch/powerpc/include/asm/iommu.h            |   15 ++
>>   arch/powerpc/kernel/iommu.c                 |  343 +++++++++++++++++++++++++++
>>   arch/powerpc/platforms/powernv/pci-ioda.c   |    1 +
>>   arch/powerpc/platforms/powernv/pci-p5ioc2.c |    5 +-
>>   arch/powerpc/platforms/powernv/pci.c        |    3 +
>>   drivers/iommu/Kconfig                       |    8 +
>>   6 files changed, 374 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
>> index cbfe678..900294b 100644
>> --- a/arch/powerpc/include/asm/iommu.h
>> +++ b/arch/powerpc/include/asm/iommu.h
>> @@ -76,6 +76,9 @@ struct iommu_table {
>>   	struct iommu_pool large_pool;
>>   	struct iommu_pool pools[IOMMU_NR_POOLS];
>>   	unsigned long *it_map;       /* A simple allocation bitmap for now */
>> +#ifdef CONFIG_IOMMU_API
>> +	struct iommu_group *it_group;
>> +#endif
>>   };
>>
>>   struct scatterlist;
>> @@ -98,6 +101,8 @@ extern void iommu_free_table(struct iommu_table *tbl, const char *node_name);
>>    */
>>   extern struct iommu_table *iommu_init_table(struct iommu_table * tbl,
>>   					    int nid);
>> +extern void iommu_register_group(struct iommu_table * tbl,
>> +				 int domain_number, unsigned long pe_num);
>>
>>   extern int iommu_map_sg(struct device *dev, struct iommu_table *tbl,
>>   			struct scatterlist *sglist, int nelems,
>> @@ -147,5 +152,15 @@ static inline void iommu_restore(void)
>>   }
>>   #endif
>>
>> +/* The API to support IOMMU operations for VFIO */
>> +extern long iommu_clear_tce_user_mode(struct iommu_table *tbl,
>> +		unsigned long ioba, unsigned long tce_value,
>> +		unsigned long npages);
>> +extern long iommu_put_tce_user_mode(struct iommu_table *tbl,
>> +		unsigned long ioba, unsigned long tce);
>> +
>> +extern void iommu_flush_tce(struct iommu_table *tbl);
>> +extern long iommu_lock_table(struct iommu_table *tbl, bool lock);
>> +
>>   #endif /* __KERNEL__ */
>>   #endif /* _ASM_IOMMU_H */
>> diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
>> index 7c309fe..b4fdabc 100644
>> --- a/arch/powerpc/kernel/iommu.c
>> +++ b/arch/powerpc/kernel/iommu.c
>> @@ -37,6 +37,7 @@
>>   #include <linux/fault-inject.h>
>>   #include <linux/pci.h>
>>   #include <linux/kvm_host.h>
>> +#include <linux/iommu.h>
>>   #include <asm/io.h>
>>   #include <asm/prom.h>
>>   #include <asm/iommu.h>
>> @@ -45,6 +46,7 @@
>>   #include <asm/kdump.h>
>>   #include <asm/fadump.h>
>>   #include <asm/vio.h>
>> +#include <asm/tce.h>
>>
>>   #define DBG(...)
>>
>> @@ -707,11 +709,39 @@ struct iommu_table *iommu_init_table(struct iommu_table *tbl, int nid)
>>   	return tbl;
>>   }
>>
>> +static void group_release(void *iommu_data)
>> +{
>> +	struct iommu_table *tbl = iommu_data;
>> +	tbl->it_group = NULL;
>> +}
>> +
>> +void iommu_register_group(struct iommu_table * tbl,
>> +		int domain_number, unsigned long pe_num)
>> +{
>> +	struct iommu_group *grp;
>> +
>> +	grp = iommu_group_alloc();
>> +	if (IS_ERR(grp)) {
>> +		pr_info("powerpc iommu api: cannot create new group, err=%ld\n",
>> +				PTR_ERR(grp));
>> +		return;
>> +	}
>> +	tbl->it_group = grp;
>> +	iommu_group_set_iommudata(grp, tbl, group_release);
>> +	iommu_group_set_name(grp, kasprintf(GFP_KERNEL, "domain%d-pe%lx",
>> +			domain_number, pe_num));
>> +}
>> +
>>   void iommu_free_table(struct iommu_table *tbl, const char *node_name)
>>   {
>>   	unsigned long bitmap_sz;
>>   	unsigned int order;
>>
>> +	if (tbl && tbl->it_group) {
>> +		iommu_group_put(tbl->it_group);
>> +		BUG_ON(tbl->it_group);
>> +	}
>> +
>>   	if (!tbl || !tbl->it_map) {
>>   		printk(KERN_ERR "%s: expected TCE map for %s\n", __func__,
>>   				node_name);
>> @@ -876,4 +906,317 @@ void kvm_iommu_unmap_pages(struct kvm *kvm, struct kvm_memory_slot *slot)
>>   {
>>   }
>>
>> +static enum dma_data_direction tce_direction(unsigned long tce)
>> +{
>> +	if ((tce & TCE_PCI_READ) && (tce & TCE_PCI_WRITE))
>> +		return DMA_BIDIRECTIONAL;
>> +	else if (tce & TCE_PCI_READ)
>> +		return DMA_TO_DEVICE;
>> +	else if (tce & TCE_PCI_WRITE)
>> +		return DMA_FROM_DEVICE;
>> +	else
>> +		return DMA_NONE;
>> +}
>> +
>> +void iommu_flush_tce(struct iommu_table *tbl)
>> +{
>> +	/* Flush/invalidate TLB caches if necessary */
>> +	if (ppc_md.tce_flush)
>> +		ppc_md.tce_flush(tbl);
>> +
>> +	/* Make sure updates are seen by hardware */
>> +	mb();
>> +}
>> +EXPORT_SYMBOL_GPL(iommu_flush_tce);
>> +
>> +static long tce_clear_param_check(struct iommu_table *tbl,
>> +		unsigned long ioba, unsigned long tce_value,
>> +		unsigned long npages)
>> +{
>> +	unsigned long size = npages << IOMMU_PAGE_SHIFT;
>> +
>> +	/* ppc_md.tce_free() does not support any value but 0 */
>> +	if (tce_value)
>> +		return -EINVAL;
>> +
>> +	if (ioba & ~IOMMU_PAGE_MASK)
>> +		return -EINVAL;
>> +
>> +	if ((ioba + size) > ((tbl->it_offset + tbl->it_size)
>> +			<< IOMMU_PAGE_SHIFT))
>> +		return -EINVAL;
>> +
>> +	if (ioba < (tbl->it_offset << IOMMU_PAGE_SHIFT))
>> +		return -EINVAL;
>> +
>> +	return 0;
>
> Why do these all return long (vs int)?  Is this a POWER-ism?

No, not really but yeah, I picked it in powerpc code :) I tried to keep 
them "long" but I noticed "int" below so what is the rule? Change all to int?


>> +}
>> +
>> +static long tce_put_param_check(struct iommu_table *tbl,
>> +		unsigned long ioba, unsigned long tce)
>> +{
>> +	if (!(tce & (TCE_PCI_WRITE | TCE_PCI_READ)))
>> +		return -EINVAL;
>> +
>> +	if (tce & ~(IOMMU_PAGE_MASK | TCE_PCI_WRITE | TCE_PCI_READ))
>> +		return -EINVAL;
>> +
>> +	if (ioba & ~IOMMU_PAGE_MASK)
>> +		return -EINVAL;
>> +
>> +	if ((ioba + IOMMU_PAGE_SIZE) > ((tbl->it_offset + tbl->it_size)
>> +			<< IOMMU_PAGE_SHIFT))
>> +		return -EINVAL;
>> +
>> +	if (ioba < (tbl->it_offset << IOMMU_PAGE_SHIFT))
>> +		return -EINVAL;
>> +
>> +	return 0;
>> +}
>> +
>> +static long clear_tce(struct iommu_table *tbl,
>> +		unsigned long entry, unsigned long pages)
>> +{
>> +	unsigned long oldtce;
>> +	struct page *page;
>> +	struct iommu_pool *pool;
>> +
>> +	for ( ; pages; --pages, ++entry) {
>> +		pool = get_pool(tbl, entry);
>> +		spin_lock(&(pool->lock));
>> +
>> +		oldtce = ppc_md.tce_get(tbl, entry);
>> +		if (oldtce & (TCE_PCI_WRITE | TCE_PCI_READ)) {
>> +			ppc_md.tce_free(tbl, entry, 1);
>> +
>> +			page = pfn_to_page(oldtce >> PAGE_SHIFT);
>> +			WARN_ON(!page);
>> +			if (page) {
>> +				if (oldtce & TCE_PCI_WRITE)
>> +					SetPageDirty(page);
>> +				put_page(page);
>> +			}
>> +		}
>> +		spin_unlock(&(pool->lock));
>> +	}
>> +
>> +	return 0;
>
> No non-zero return, make it void?

ah, ok. The prototype will change for real mode either way, it will get a 
"realmode" flag and become able to fail (which will switch the virtual mode).

>> +}
>> +
>> +long iommu_clear_tce_user_mode(struct iommu_table *tbl, unsigned long ioba,
>> +		unsigned long tce_value, unsigned long npages)
>> +{
>> +	long ret;
>> +	unsigned long entry = ioba >> IOMMU_PAGE_SHIFT;
>> +
>> +	ret = tce_clear_param_check(tbl, ioba, tce_value, npages);
>> +	if (!ret)
>> +		ret = clear_tce(tbl, entry, npages);
>> +
>> +	if (ret < 0)
>> +		pr_err("iommu_tce: %s failed ioba=%lx, tce_value=%lx ret=%ld\n",
>> +				__func__, ioba, tce_value, ret);
>> +
>> +	return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(iommu_clear_tce_user_mode);
>> +
>> +/* hwaddr is a virtual address here, tce_build converts it to physical */
>> +static long do_tce_build(struct iommu_table *tbl, unsigned long entry,
>> +		unsigned long hwaddr, enum dma_data_direction direction)
>> +{
>> +	long ret = -EBUSY;
>> +	unsigned long oldtce;
>> +	struct iommu_pool *pool = get_pool(tbl, entry);
>> +
>> +	spin_lock(&(pool->lock));
>> +
>> +	oldtce = ppc_md.tce_get(tbl, entry);
>> +	/* Add new entry if it is not busy */
>> +	if (!(oldtce & (TCE_PCI_WRITE | TCE_PCI_READ)))
>> +		ret = ppc_md.tce_build(tbl, entry, 1, hwaddr, direction, NULL);
>> +
>> +	spin_unlock(&(pool->lock));
>> +
>> +	if (unlikely(ret))
>> +		pr_err("iommu_tce: %s failed on hwaddr=%lx ioba=%lx kva=%lx ret=%ld\n",
>> +				__func__, hwaddr, entry << IOMMU_PAGE_SHIFT,
>> +				hwaddr, ret);
>> +
>> +	return ret;
>> +}
>> +
>> +static int put_tce_user_mode(struct iommu_table *tbl, unsigned long entry,
>> +		unsigned long tce)
>> +{
>> +	int ret;
>
> Now we're back to returning ints.
 >
>> +	struct page *page = NULL;
>> +	unsigned long hwaddr, offset = tce & IOMMU_PAGE_MASK & ~PAGE_MASK;
>> +	enum dma_data_direction direction = tce_direction(tce);
>> +
>> +	ret = get_user_pages_fast(tce & PAGE_MASK, 1,
>> +			direction != DMA_TO_DEVICE, &page);
>> +	if (unlikely(ret != 1)) {
>> +		pr_err("iommu_tce: get_user_pages_fast failed tce=%lx ioba=%lx ret=%d\n",
>> +				tce, entry << IOMMU_PAGE_SHIFT, ret);
>> +		return -EFAULT;
>> +	}
>> +	hwaddr = (unsigned long) page_address(page) + offset;
>> +
>> +	ret = do_tce_build(tbl, entry, hwaddr, direction);
>> +	if (ret)
>> +		put_page(page);
>> +
>> +	return ret;
>> +}
>> +
>> +long iommu_put_tce_user_mode(struct iommu_table *tbl, unsigned long ioba,
>> +		unsigned long tce)
>> +{
>> +	long ret;
>
> Oops, back to longs.
>
>> +	unsigned long entry = ioba >> IOMMU_PAGE_SHIFT;
>> +
>> +	ret = tce_put_param_check(tbl, ioba, tce);
>> +	if (!ret)
>> +		ret = put_tce_user_mode(tbl, entry, tce);
>> +
>> +	if (ret < 0)
>> +		pr_err("iommu_tce: %s failed ioba=%lx, tce=%lx, ret=%ld\n",
>> +				__func__, ioba, tce, ret);
>> +
>> +	return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(iommu_put_tce_user_mode);
>> +
>> +/*
>> + * Helpers to do locked pages accounting.
>> + * Called from ioctl so down_write_trylock is not necessary.
>> + */
>> +static void lock_acct(long npage)
>> +{
>> +	if (!current->mm)
>> +		return; /* process exited */
>> +
>> +	down_write(&current->mm->mmap_sem);
>> +	current->mm->locked_vm += npage;
>> +	up_write(&current->mm->mmap_sem);
>> +}
>> +
>> +/*
>> + * iommu_lock_table - Start/stop using the table by VFIO
>> + * @tbl: Pointer to the IOMMU table
>> + * @lock: true when VFIO starts using the table
>> + */
>> +long iommu_lock_table(struct iommu_table *tbl, bool lock)
>> +{
>> +	unsigned long sz = (tbl->it_size + 7) >> 3;
>> +	unsigned long locked, lock_limit;
>> +
>> +	if (lock) {
>> +		/*
>> +		 * Account for locked pages
>> +		 * The worst case is when every IOMMU page
>> +		 * is mapped to separate system page
>> +		 */
>> +		locked = current->mm->locked_vm + tbl->it_size;
>> +		lock_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
>> +		if (locked > lock_limit && !capable(CAP_IPC_LOCK)) {
>> +			pr_warn("RLIMIT_MEMLOCK (%ld) exceeded\n",
>> +					rlimit(RLIMIT_MEMLOCK));
>> +			return -ENOMEM;
>> +		}
>> +
>> +		if (tbl->it_offset == 0)
>> +			clear_bit(0, tbl->it_map);
>> +
>> +		if (!bitmap_empty(tbl->it_map, tbl->it_size)) {
>> +			pr_err("iommu_tce: it_map is not empty");
>> +			return -EBUSY;
>> +		}
>> +
>> +		lock_acct(tbl->it_size);
>> +		memset(tbl->it_map, 0xff, sz);
>> +	}
>> +
>> +	/* Clear TCE table */
>> +	clear_tce(tbl, tbl->it_offset, tbl->it_size);
>> +
>> +	if (!lock) {
>> +		lock_acct(-tbl->it_size);
>> +		memset(tbl->it_map, 0, sz);
>> +
>> +		/* Restore bit#0 set by iommu_init_table() */
>> +		if (tbl->it_offset == 0)
>> +			set_bit(0, tbl->it_map);
>> +	}
>> +
>> +	return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(iommu_lock_table);
>> +
>> +int iommu_add_device(struct device *dev)
>> +{
>> +	struct iommu_table *tbl;
>> +	int ret = 0;
>> +
>> +	if (WARN_ON(dev->iommu_group)) {
>> +		pr_warn("iommu_tce: device %s is already in iommu group %d, skipping\n",
>> +				dev_name(dev),
>> +				iommu_group_id(dev->iommu_group));
>> +		return -EBUSY;
>> +	}
>> +
>> +	tbl = get_iommu_table_base(dev);
>> +	if (!tbl) {
>> +		pr_debug("iommu_tce: skipping device %s with no tbl\n",
>> +				dev_name(dev));
>> +		return 0;
>> +	}
>> +
>> +	pr_debug("iommu_tce: adding %s to iommu group %d\n",
>> +			dev_name(dev), iommu_group_id(tbl->it_group));
>> +
>> +	ret = iommu_group_add_device(tbl->it_group, dev);
>> +	if (ret < 0)
>> +		pr_err("iommu_tce: %s has not been added, ret=%d\n",
>> +				dev_name(dev), ret);
>> +
>> +	return ret;
>> +}
>> +
>> +void iommu_del_device(struct device *dev)
>> +{
>> +	iommu_group_remove_device(dev);
>> +}
>> +
>> +static int iommu_bus_notifier(struct notifier_block *nb,
>> +			      unsigned long action, void *data)
>> +{
>> +	struct device *dev = data;
>> +
>> +	switch (action) {
>> +	case BUS_NOTIFY_ADD_DEVICE:
>> +		return iommu_add_device(dev);
>> +	case BUS_NOTIFY_DEL_DEVICE:
>> +		iommu_del_device(dev);
>> +		return 0;
>> +	default:
>> +		return 0;
>> +	}
>> +}
>> +
>> +static struct notifier_block tce_iommu_bus_nb = {
>> +	.notifier_call = iommu_bus_notifier,
>> +};
>> +
>> +static int __init tce_iommu_init(void)
>> +{
>> +	BUILD_BUG_ON(PAGE_SIZE < IOMMU_PAGE_SIZE);
>> +
>> +	bus_register_notifier(&pci_bus_type, &tce_iommu_bus_nb);
>> +	return 0;
>> +}
>> +
>> +arch_initcall(tce_iommu_init);
>> +
>>   #endif /* CONFIG_IOMMU_API */
>> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
>> index 8e90e89..04dbc49 100644
>> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
>> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
>> @@ -522,6 +522,7 @@ static void pnv_pci_ioda_setup_dma_pe(struct pnv_phb *phb,
>>   			| TCE_PCI_SWINV_PAIR;
>>   	}
>>   	iommu_init_table(tbl, phb->hose->node);
>> +	iommu_register_group(tbl, pci_domain_nr(pe->pbus), pe->pe_number);
>>
>>   	if (pe->pdev)
>>   		set_iommu_table_base(&pe->pdev->dev, tbl);
>> diff --git a/arch/powerpc/platforms/powernv/pci-p5ioc2.c b/arch/powerpc/platforms/powernv/pci-p5ioc2.c
>> index abe6780..7ce75b0 100644
>> --- a/arch/powerpc/platforms/powernv/pci-p5ioc2.c
>> +++ b/arch/powerpc/platforms/powernv/pci-p5ioc2.c
>> @@ -87,8 +87,11 @@ static void pnv_pci_init_p5ioc2_msis(struct pnv_phb *phb) { }
>>   static void pnv_pci_p5ioc2_dma_dev_setup(struct pnv_phb *phb,
>>   					 struct pci_dev *pdev)
>>   {
>> -	if (phb->p5ioc2.iommu_table.it_map == NULL)
>> +	if (phb->p5ioc2.iommu_table.it_map == NULL) {
>>   		iommu_init_table(&phb->p5ioc2.iommu_table, phb->hose->node);
>> +		iommu_register_group(&phb->p5ioc2.iommu_table,
>> +				pci_domain_nr(phb->hose->bus), phb->opal_id);
>> +	}
>>
>>   	set_iommu_table_base(&pdev->dev, &phb->p5ioc2.iommu_table);
>>   }
>> diff --git a/arch/powerpc/platforms/powernv/pci.c b/arch/powerpc/platforms/powernv/pci.c
>> index f60a188..d112701 100644
>> --- a/arch/powerpc/platforms/powernv/pci.c
>> +++ b/arch/powerpc/platforms/powernv/pci.c
>> @@ -20,6 +20,7 @@
>>   #include <linux/irq.h>
>>   #include <linux/io.h>
>>   #include <linux/msi.h>
>> +#include <linux/iommu.h>
>>
>>   #include <asm/sections.h>
>>   #include <asm/io.h>
>> @@ -503,6 +504,7 @@ static struct iommu_table *pnv_pci_setup_bml_iommu(struct pci_controller *hose)
>>   	pnv_pci_setup_iommu_table(tbl, __va(be64_to_cpup(basep)),
>>   				  be32_to_cpup(sizep), 0);
>>   	iommu_init_table(tbl, hose->node);
>> +	iommu_register_group(tbl, pci_domain_nr(hose->bus), 0);
>>
>>   	/* Deal with SW invalidated TCEs when needed (BML way) */
>>   	swinvp = of_get_property(hose->dn, "linux,tce-sw-invalidate-info",
>> @@ -631,3 +633,4 @@ void __init pnv_pci_init(void)
>>   	ppc_md.teardown_msi_irqs = pnv_teardown_msi_irqs;
>>   #endif
>>   }
>> +
>
> stray newline
>
>> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
>> index e39f9db..ce6b186 100644
>> --- a/drivers/iommu/Kconfig
>> +++ b/drivers/iommu/Kconfig
>> @@ -187,4 +187,12 @@ config EXYNOS_IOMMU_DEBUG
>>
>>   	  Say N unless you need kernel log message for IOMMU debugging
>>
>> +config SPAPR_TCE_IOMMU
>> +	bool "sPAPR TCE IOMMU Support"
>> +	depends on PPC_POWERNV
>> +	select IOMMU_API
>> +	help
>> +	  Enables bits of IOMMU API required by VFIO. The iommu_ops is
>> +	  still not implemented.
>> +
>>   endif # IOMMU_SUPPORT
>
> Looks mostly ok to me other than the minor notes.  As mentioned
> previously, this one needs to go in through power maintainers before I
> can include 2/2 .  Thanks,
>
> Alex
>
>
>


-- 
Alexey

Re: [PATCH 2/2] vfio powerpc: implemented IOMMU driver for VFIO

[Alexey Kardashevskiy]

On 12/02/13 09:17, Alex Williamson wrote:
> On Mon, 2013-02-11 at 22:54 +1100, Alexey Kardashevskiy wrote:
>> VFIO implements platform independent stuff such as
>> a PCI driver, BAR access (via read/write on a file descriptor
>> or direct mapping when possible) and IRQ signaling.
>>
>> The platform dependent part includes IOMMU initialization
>> and handling. This patch implements an IOMMU driver for VFIO
>> which does mapping/unmapping pages for the guest IO and
>> provides information about DMA window (required by a POWERPC
>> guest).
>>
>> The counterpart in QEMU is required to support this functionality.
>
> Revision info would be great here too.
 >
>
>> Cc: David Gibson <david@gibson.dropbear.id.au>
>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>> ---
>>   drivers/vfio/Kconfig                |    6 +
>>   drivers/vfio/Makefile               |    1 +
>>   drivers/vfio/vfio_iommu_spapr_tce.c |  269 +++++++++++++++++++++++++++++++++++
>>   include/uapi/linux/vfio.h           |   31 ++++
>>   4 files changed, 307 insertions(+)
>>   create mode 100644 drivers/vfio/vfio_iommu_spapr_tce.c
>>
>> diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
>> index 7cd5dec..b464687 100644
>> --- a/drivers/vfio/Kconfig
>> +++ b/drivers/vfio/Kconfig
>> @@ -3,10 +3,16 @@ config VFIO_IOMMU_TYPE1
>>   	depends on VFIO
>>   	default n
>>
>> +config VFIO_IOMMU_SPAPR_TCE
>> +	tristate
>> +	depends on VFIO && SPAPR_TCE_IOMMU
>> +	default n
>> +
>>   menuconfig VFIO
>>   	tristate "VFIO Non-Privileged userspace driver framework"
>>   	depends on IOMMU_API
>>   	select VFIO_IOMMU_TYPE1 if X86
>> +	select VFIO_IOMMU_SPAPR_TCE if PPC_POWERNV
>>   	help
>>   	  VFIO provides a framework for secure userspace device drivers.
>>   	  See Documentation/vfio.txt for more details.
>> diff --git a/drivers/vfio/Makefile b/drivers/vfio/Makefile
>> index 2398d4a..72bfabc 100644
>> --- a/drivers/vfio/Makefile
>> +++ b/drivers/vfio/Makefile
>> @@ -1,3 +1,4 @@
>>   obj-$(CONFIG_VFIO) += vfio.o
>>   obj-$(CONFIG_VFIO_IOMMU_TYPE1) += vfio_iommu_type1.o
>> +obj-$(CONFIG_VFIO_IOMMU_SPAPR_TCE) += vfio_iommu_spapr_tce.o
>>   obj-$(CONFIG_VFIO_PCI) += pci/
>> diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c b/drivers/vfio/vfio_iommu_spapr_tce.c
>> new file mode 100644
>> index 0000000..9b3fa88
>> --- /dev/null
>> +++ b/drivers/vfio/vfio_iommu_spapr_tce.c
>> @@ -0,0 +1,269 @@
>> +/*
>> + * VFIO: IOMMU DMA mapping support for TCE on POWER
>> + *
>> + * Copyright (C) 2012 IBM Corp.  All rights reserved.
>
> 2013 now
>
>> + *     Author: Alexey Kardashevskiy <aik@ozlabs.ru>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * Derived from original vfio_iommu_type1.c:
>> + * Copyright (C) 2012 Red Hat, Inc.  All rights reserved.
>> + *     Author: Alex Williamson <alex.williamson@redhat.com>
>> + */
>> +
>> +#include <linux/module.h>
>> +#include <linux/pci.h>
>> +#include <linux/slab.h>
>> +#include <linux/uaccess.h>
>> +#include <linux/err.h>
>> +#include <linux/vfio.h>
>> +#include <asm/iommu.h>
>> +#include <asm/tce.h>
>> +
>> +#define DRIVER_VERSION  "0.1"
>> +#define DRIVER_AUTHOR   "aik@ozlabs.ru"
>> +#define DRIVER_DESC     "VFIO IOMMU SPAPR TCE"
>> +
>> +static void tce_iommu_detach_group(void *iommu_data,
>> +		struct iommu_group *iommu_group);
>> +
>> +/*
>> + * VFIO IOMMU fd for SPAPR_TCE IOMMU implementation
>> + *
>> + * This code handles mapping and unmapping of user data buffers
>> + * into DMA'ble space using the IOMMU
>> + */
>> +
>> +/*
>> + * The container descriptor supports only a single group per container.
>> + * Required by the API as the container is not supplied with the IOMMU group
>> + * at the moment of initialization.
>> + */
>> +struct tce_container {
>> +	struct mutex lock;
>> +	struct iommu_table *tbl;
>> +};
>> +
>> +static void *tce_iommu_open(unsigned long arg)
>> +{
>> +	struct tce_container *container;
>> +
>> +	if (arg != VFIO_SPAPR_TCE_IOMMU) {
>> +		pr_err("tce_vfio: Wrong IOMMU type\n");
>> +		return ERR_PTR(-EINVAL);
>> +	}
>> +
>> +	container = kzalloc(sizeof(*container), GFP_KERNEL);
>> +	if (!container)
>> +		return ERR_PTR(-ENOMEM);
>> +
>> +	mutex_init(&container->lock);
>> +
>> +	return container;
>> +}
>> +
>> +static void tce_iommu_release(void *iommu_data)
>> +{
>> +	struct tce_container *container = iommu_data;
>> +
>> +	WARN_ON(container->tbl && !container->tbl->it_group);
>> +	if (container->tbl && container->tbl->it_group)
>> +		tce_iommu_detach_group(iommu_data, container->tbl->it_group);
>> +
>> +	mutex_destroy(&container->lock);
>> +
>> +	kfree(container);
>> +}
>> +
>> +static long tce_iommu_ioctl(void *iommu_data,
>> +				 unsigned int cmd, unsigned long arg)
>> +{
>> +	struct tce_container *container = iommu_data;
>> +	unsigned long minsz;
>> +	long ret;
>> +
>> +	switch (cmd) {
>> +	case VFIO_CHECK_EXTENSION:
>> +		return (arg == VFIO_SPAPR_TCE_IOMMU) ? 1 : 0;
>> +
>> +	case VFIO_IOMMU_SPAPR_TCE_GET_INFO: {
>> +		struct vfio_iommu_spapr_tce_info info;
>> +		struct iommu_table *tbl = container->tbl;
>> +
>> +		if (WARN_ON(!tbl))
>> +			return -ENXIO;
>> +
>> +		minsz = offsetofend(struct vfio_iommu_spapr_tce_info,
>> +				dma32_window_size);
>> +
>> +		if (copy_from_user(&info, (void __user *)arg, minsz))
>> +			return -EFAULT;
>> +
>> +		if (info.argsz < minsz)
>> +			return -EINVAL;
>> +
>> +		info.dma32_window_start = tbl->it_offset << IOMMU_PAGE_SHIFT;
>> +		info.dma32_window_size = tbl->it_size << IOMMU_PAGE_SHIFT;
>> +		info.flags = 0;
>> +
>> +		if (copy_to_user((void __user *)arg, &info, minsz))
>> +			return -EFAULT;
>> +
>> +		return 0;
>> +	}
>> +	case VFIO_IOMMU_MAP_DMA: {
>> +		vfio_iommu_spapr_tce_dma_map param;
>> +		struct iommu_table *tbl = container->tbl;
>> +		unsigned long tce;
>> +
>> +		if (WARN_ON(!tbl))
>> +			return -ENXIO;
>> +
>> +		minsz = offsetofend(vfio_iommu_spapr_tce_dma_map, size);
>> +
>> +		if (copy_from_user(&param, (void __user *)arg, minsz))
>> +			return -EFAULT;
>> +
>> +		if (param.argsz < minsz)
>> +			return -EINVAL;
>> +
>> +		if (param.flags & ~(VFIO_DMA_MAP_FLAG_READ |
>> +				VFIO_DMA_MAP_FLAG_WRITE))
>> +			return -EINVAL;
>> +
>> +		if ((param.size & ~IOMMU_PAGE_MASK) ||
>> +				(param.vaddr & ~IOMMU_PAGE_MASK))
>> +			return -EINVAL;
>> +
>> +		/* TODO: support multiple TCEs */
>> +		if (param.size != IOMMU_PAGE_SIZE) {
>
> Ouch, ioctl per page...

Well, there is something to discuss.

On POWER, there is an interface to add multiple pages at once but the guest 
does not supply the range of guest phys addresses, it puts some addresses 
to a small page (so it is up to 512 pages at once) and passes this address 
to the host as a parameter.

I posted another series yesterday but forgot to cc: you :) You can find 
them here - http://patchwork.ozlabs.org/patch/219592/ (emulated devices) 
and http://patchwork.ozlabs.org/patch/219594/ (vfio). There I convert guest 
phys address (real and virtual mode are handled different ways) and call 
iommu_put_tce_user_mode() (or analog) in a loop.

Either way, I did some tests with 10Gb card and without real mode stuff it 
does 220MB/s, and even if I do multi-tce it won't be faster than ~400MB/s 
which is still not enough as the real mode code makes it 1020MB/s. Slower 
devices work on the same speed no matter what.


>> +			pr_err("VFIO map on POWER supports only %lu page size\n",
>> +					IOMMU_PAGE_SIZE);
>> +			return -EINVAL;
>> +		}
>> +
>> +		/* iova is checked by the IOMMU API */
>> +		tce = param.vaddr;
>> +		if (param.flags & VFIO_DMA_MAP_FLAG_READ)
>> +			tce |= TCE_PCI_READ;
>> +		if (param.flags & VFIO_DMA_MAP_FLAG_WRITE)
>> +			tce |= TCE_PCI_WRITE;
>> +
>> +		ret = iommu_put_tce_user_mode(tbl, param.iova, tce);
>> +		iommu_flush_tce(tbl);
>> +
>> +		return ret;
>> +	}
>> +	case VFIO_IOMMU_UNMAP_DMA: {
>> +		vfio_iommu_spapr_tce_dma_unmap param;
>> +		struct iommu_table *tbl = container->tbl;
>> +
>> +		if (WARN_ON(!tbl))
>> +			return -ENXIO;
>> +
>> +		minsz = offsetofend(vfio_iommu_spapr_tce_dma_unmap, size);
>> +
>> +		if (copy_from_user(&param, (void __user *)arg, minsz))
>> +			return -EFAULT;
>> +
>> +		if (param.argsz < minsz)
>> +			return -EINVAL;
>> +
>> +		/* No flag is supported now */
>> +		if (param.flags)
>> +			return -EINVAL;
>> +
>> +		if (param.size & ~IOMMU_PAGE_MASK)
>> +			return -EINVAL;
>
> But you support multi-page unmaps?

Yes, this is a lot easier :)


>> +		/* iova is checked by the IOMMU API */
>> +		ret = iommu_clear_tce_user_mode(tbl, param.iova, 0,
>> +				param.size >> IOMMU_PAGE_SHIFT);
>> +		iommu_flush_tce(tbl);
>> +
>> +		return ret;
>> +	}
>> +	}
>> +
>> +	return -ENOTTY;
>> +}
>> +
>> +static int tce_iommu_attach_group(void *iommu_data,
>> +		struct iommu_group *iommu_group)
>> +{
>> +	int ret;
>> +	struct tce_container *container = iommu_data;
>> +	struct iommu_table *tbl = iommu_group_get_iommudata(iommu_group);
>> +
>> +	BUG_ON(!tbl);
>> +	mutex_lock(&container->lock);
>> +	pr_debug("tce_vfio: Attaching group #%u to iommu %p\n",
>> +			iommu_group_id(iommu_group), iommu_group);
>> +	if (container->tbl) {
>> +		pr_warn("tce_vfio: Only one group per IOMMU container is allowed, existing id=%d, attaching id=%d\n",
>> +				iommu_group_id(container->tbl->it_group),
>> +				iommu_group_id(iommu_group));
>> +		mutex_unlock(&container->lock);
>> +		return -EBUSY;
>> +	}
>> +
>> +	container->tbl = tbl;
>> +	ret = iommu_lock_table(tbl, true);
>
> Bug, container->tbl is set regardless of iommu_lock_table.

Oops, bug.

> Ok, so now we're checking rlimits and handling page accounting on
> VFIO_GROUP_SET_CONTAINER to avoid any overhead at map/unmap.  How can
> the user learn tbl->it_size to set their locked page limit prior to
> this?  It's available from GET_INFO, but there's a chicken and egg
> problem that to get it there you have to get past this, which means
> you're already ok.  Maybe it's in sysfs somewhere already or it could be
> exposed in the iommu group like the name attribute.  Otherwise we might
> consider doing locking on first mapping.  Thanks,

GET_INFO is called in the beginning so QEMU will exit right there. No real 
work will have been done till that moment so what is the problem?



> Alex
>
>> +	mutex_unlock(&container->lock);
>> +
>> +	return ret;
>> +}
>> +
>> +static void tce_iommu_detach_group(void *iommu_data,
>> +		struct iommu_group *iommu_group)
>> +{
>> +	struct tce_container *container = iommu_data;
>> +	struct iommu_table *tbl = iommu_group_get_iommudata(iommu_group);
>> +
>> +	BUG_ON(!tbl);
>> +	mutex_lock(&container->lock);
>> +	if (tbl != container->tbl) {
>> +		pr_warn("tce_vfio: detaching group #%u, expected group is #%u\n",
>> +				iommu_group_id(iommu_group),
>> +				iommu_group_id(tbl->it_group));
>> +	} else {
>> +
>> +		pr_debug("tce_vfio: detaching group #%u from iommu %p\n",
>> +				iommu_group_id(iommu_group), iommu_group);
>> +
>> +		container->tbl = NULL;
>> +		iommu_lock_table(tbl, false);
>> +	}
>> +	mutex_unlock(&container->lock);
>> +}
>> +
>> +const struct vfio_iommu_driver_ops tce_iommu_driver_ops = {
>> +	.name		= "iommu-vfio-powerpc",
>> +	.owner		= THIS_MODULE,
>> +	.open		= tce_iommu_open,
>> +	.release	= tce_iommu_release,
>> +	.ioctl		= tce_iommu_ioctl,
>> +	.attach_group	= tce_iommu_attach_group,
>> +	.detach_group	= tce_iommu_detach_group,
>> +};
>> +
>> +static int __init tce_iommu_init(void)
>> +{
>> +	return vfio_register_iommu_driver(&tce_iommu_driver_ops);
>> +}
>> +
>> +static void __exit tce_iommu_cleanup(void)
>> +{
>> +	vfio_unregister_iommu_driver(&tce_iommu_driver_ops);
>> +}
>> +
>> +module_init(tce_iommu_init);
>> +module_exit(tce_iommu_cleanup);
>> +
>> +MODULE_VERSION(DRIVER_VERSION);
>> +MODULE_LICENSE("GPL v2");
>> +MODULE_AUTHOR(DRIVER_AUTHOR);
>> +MODULE_DESCRIPTION(DRIVER_DESC);
>> +
>> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
>> index 4758d1b..ea9a9a7 100644
>> --- a/include/uapi/linux/vfio.h
>> +++ b/include/uapi/linux/vfio.h
>> @@ -22,6 +22,7 @@
>>   /* Extensions */
>>
>>   #define VFIO_TYPE1_IOMMU		1
>> +#define VFIO_SPAPR_TCE_IOMMU		2
>>
>>   /*
>>    * The IOCTL interface is designed for extensibility by embedding the
>> @@ -365,4 +366,34 @@ struct vfio_iommu_type1_dma_unmap {
>>
>>   #define VFIO_IOMMU_UNMAP_DMA _IO(VFIO_TYPE, VFIO_BASE + 14)
>>
>> +/* -------- Additional API for SPAPR TCE (Server POWERPC) IOMMU -------- */
>> +
>> +/*
>> + * The SPAPR TCE info struct provides the information about the PCI bus
>> + * address ranges available for DMA, these values are programmed into
>> + * the hardware so the guest has to know that information.
>> + *
>> + * The DMA 32 bit window start is an absolute PCI bus address.
>> + * The IOVA address passed via map/unmap ioctls are absolute PCI bus
>> + * addresses too so the window works as a filter rather than an offset
>> + * for IOVA addresses.
>> + *
>> + * A flag will need to be added if other page sizes are supported,
>> + * so as defined here, it is always 4k.
>> + */
>> +struct vfio_iommu_spapr_tce_info {
>> +	__u32 argsz;
>> +	__u32 flags;			/* reserved for future use */
>> +	__u32 dma32_window_start;	/* 32 bit window start (bytes) */
>> +	__u32 dma32_window_size;	/* 32 bit window size (bytes) */
>> +};
>> +
>> +#define VFIO_IOMMU_SPAPR_TCE_GET_INFO	_IO(VFIO_TYPE, VFIO_BASE + 12)
>> +
>> +/* Reuse type1 map/unmap structs as they are the same at the moment */
>> +typedef struct vfio_iommu_type1_dma_map vfio_iommu_spapr_tce_dma_map;
>> +typedef struct vfio_iommu_type1_dma_unmap vfio_iommu_spapr_tce_dma_unmap;
>> +
>> +/* ***************************************************************** */
>> +
>>   #endif /* _UAPIVFIO_H */
>
>
>


-- 
Alexey

Re: [PATCH 1/2] vfio powerpc: enabled on powernv platform

[Alex Williamson]

On Tue, 2013-02-12 at 10:19 +1100, Alexey Kardashevskiy wrote:
> On 12/02/13 09:16, Alex Williamson wrote:
> > On Mon, 2013-02-11 at 22:54 +1100, Alexey Kardashevskiy wrote:
> >> @@ -707,11 +709,39 @@ struct iommu_table *iommu_init_table(struct iommu_table *tbl, int nid)
> >>   	return tbl;
> >>   }
> >>
> >> +static void group_release(void *iommu_data)
> >> +{
> >> +	struct iommu_table *tbl = iommu_data;
> >> +	tbl->it_group = NULL;
> >> +}
> >> +
> >> +void iommu_register_group(struct iommu_table * tbl,
> >> +		int domain_number, unsigned long pe_num)
> >> +{
> >> +	struct iommu_group *grp;
> >> +
> >> +	grp = iommu_group_alloc();
> >> +	if (IS_ERR(grp)) {
> >> +		pr_info("powerpc iommu api: cannot create new group, err=%ld\n",
> >> +				PTR_ERR(grp));
> >> +		return;
> >> +	}
> >> +	tbl->it_group = grp;
> >> +	iommu_group_set_iommudata(grp, tbl, group_release);
> >> +	iommu_group_set_name(grp, kasprintf(GFP_KERNEL, "domain%d-pe%lx",
> >> +			domain_number, pe_num));
> >> +}
> >> +
> >>   void iommu_free_table(struct iommu_table *tbl, const char *node_name)
> >>   {
> >>   	unsigned long bitmap_sz;
> >>   	unsigned int order;
> >>
> >> +	if (tbl && tbl->it_group) {
> >> +		iommu_group_put(tbl->it_group);
> >> +		BUG_ON(tbl->it_group);
> >> +	}
> >> +
> >>   	if (!tbl || !tbl->it_map) {
> >>   		printk(KERN_ERR "%s: expected TCE map for %s\n", __func__,
> >>   				node_name);
> >> @@ -876,4 +906,317 @@ void kvm_iommu_unmap_pages(struct kvm *kvm, struct kvm_memory_slot *slot)
> >>   {
> >>   }
> >>
> >> +static enum dma_data_direction tce_direction(unsigned long tce)
> >> +{
> >> +	if ((tce & TCE_PCI_READ) && (tce & TCE_PCI_WRITE))
> >> +		return DMA_BIDIRECTIONAL;
> >> +	else if (tce & TCE_PCI_READ)
> >> +		return DMA_TO_DEVICE;
> >> +	else if (tce & TCE_PCI_WRITE)
> >> +		return DMA_FROM_DEVICE;
> >> +	else
> >> +		return DMA_NONE;
> >> +}
> >> +
> >> +void iommu_flush_tce(struct iommu_table *tbl)
> >> +{
> >> +	/* Flush/invalidate TLB caches if necessary */
> >> +	if (ppc_md.tce_flush)
> >> +		ppc_md.tce_flush(tbl);
> >> +
> >> +	/* Make sure updates are seen by hardware */
> >> +	mb();
> >> +}
> >> +EXPORT_SYMBOL_GPL(iommu_flush_tce);
> >> +
> >> +static long tce_clear_param_check(struct iommu_table *tbl,
> >> +		unsigned long ioba, unsigned long tce_value,
> >> +		unsigned long npages)
> >> +{
> >> +	unsigned long size = npages << IOMMU_PAGE_SHIFT;
> >> +
> >> +	/* ppc_md.tce_free() does not support any value but 0 */
> >> +	if (tce_value)
> >> +		return -EINVAL;
> >> +
> >> +	if (ioba & ~IOMMU_PAGE_MASK)
> >> +		return -EINVAL;
> >> +
> >> +	if ((ioba + size) > ((tbl->it_offset + tbl->it_size)
> >> +			<< IOMMU_PAGE_SHIFT))
> >> +		return -EINVAL;
> >> +
> >> +	if (ioba < (tbl->it_offset << IOMMU_PAGE_SHIFT))
> >> +		return -EINVAL;
> >> +
> >> +	return 0;
> >
> > Why do these all return long (vs int)?  Is this a POWER-ism?
> 
> No, not really but yeah, I picked it in powerpc code :) I tried to keep 
> them "long" but I noticed "int" below so what is the rule? Change all to int?

I'd say anything that's returning 0/-errno should probably be an int.

> >> +}
> >> +
> >> +static long tce_put_param_check(struct iommu_table *tbl,
> >> +		unsigned long ioba, unsigned long tce)
> >> +{
> >> +	if (!(tce & (TCE_PCI_WRITE | TCE_PCI_READ)))
> >> +		return -EINVAL;
> >> +
> >> +	if (tce & ~(IOMMU_PAGE_MASK | TCE_PCI_WRITE | TCE_PCI_READ))
> >> +		return -EINVAL;
> >> +
> >> +	if (ioba & ~IOMMU_PAGE_MASK)
> >> +		return -EINVAL;
> >> +
> >> +	if ((ioba + IOMMU_PAGE_SIZE) > ((tbl->it_offset + tbl->it_size)
> >> +			<< IOMMU_PAGE_SHIFT))
> >> +		return -EINVAL;
> >> +
> >> +	if (ioba < (tbl->it_offset << IOMMU_PAGE_SHIFT))
> >> +		return -EINVAL;
> >> +
> >> +	return 0;
> >> +}
> >> +
> >> +static long clear_tce(struct iommu_table *tbl,
> >> +		unsigned long entry, unsigned long pages)
> >> +{
> >> +	unsigned long oldtce;
> >> +	struct page *page;
> >> +	struct iommu_pool *pool;
> >> +
> >> +	for ( ; pages; --pages, ++entry) {
> >> +		pool = get_pool(tbl, entry);
> >> +		spin_lock(&(pool->lock));
> >> +
> >> +		oldtce = ppc_md.tce_get(tbl, entry);
> >> +		if (oldtce & (TCE_PCI_WRITE | TCE_PCI_READ)) {
> >> +			ppc_md.tce_free(tbl, entry, 1);
> >> +
> >> +			page = pfn_to_page(oldtce >> PAGE_SHIFT);
> >> +			WARN_ON(!page);
> >> +			if (page) {
> >> +				if (oldtce & TCE_PCI_WRITE)
> >> +					SetPageDirty(page);
> >> +				put_page(page);
> >> +			}
> >> +		}
> >> +		spin_unlock(&(pool->lock));
> >> +	}
> >> +
> >> +	return 0;
> >
> > No non-zero return, make it void?
> 
> ah, ok. The prototype will change for real mode either way, it will get a 
> "realmode" flag and become able to fail (which will switch the virtual mode).

If you'll use it later on, no need to change it for me.  Thanks,

Alex

Re: [PATCH 2/2] vfio powerpc: implemented IOMMU driver for VFIO

[Alex Williamson]

On Tue, 2013-02-12 at 10:45 +1100, Alexey Kardashevskiy wrote:
> On 12/02/13 09:17, Alex Williamson wrote:
> > On Mon, 2013-02-11 at 22:54 +1100, Alexey Kardashevskiy wrote:
> >> VFIO implements platform independent stuff such as
> >> a PCI driver, BAR access (via read/write on a file descriptor
> >> or direct mapping when possible) and IRQ signaling.
> >>
> >> The platform dependent part includes IOMMU initialization
> >> and handling. This patch implements an IOMMU driver for VFIO
> >> which does mapping/unmapping pages for the guest IO and
> >> provides information about DMA window (required by a POWERPC
> >> guest).
> >>
> >> The counterpart in QEMU is required to support this functionality.
> >
> > Revision info would be great here too.
>  >
> >
> >> Cc: David Gibson <david@gibson.dropbear.id.au>
> >> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> >> ---
> >>   drivers/vfio/Kconfig                |    6 +
> >>   drivers/vfio/Makefile               |    1 +
> >>   drivers/vfio/vfio_iommu_spapr_tce.c |  269 +++++++++++++++++++++++++++++++++++
> >>   include/uapi/linux/vfio.h           |   31 ++++
> >>   4 files changed, 307 insertions(+)
> >>   create mode 100644 drivers/vfio/vfio_iommu_spapr_tce.c
> >>
> >> diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
> >> index 7cd5dec..b464687 100644
> >> --- a/drivers/vfio/Kconfig
> >> +++ b/drivers/vfio/Kconfig
> >> @@ -3,10 +3,16 @@ config VFIO_IOMMU_TYPE1
> >>   	depends on VFIO
> >>   	default n
> >>
> >> +config VFIO_IOMMU_SPAPR_TCE
> >> +	tristate
> >> +	depends on VFIO && SPAPR_TCE_IOMMU
> >> +	default n
> >> +
> >>   menuconfig VFIO
> >>   	tristate "VFIO Non-Privileged userspace driver framework"
> >>   	depends on IOMMU_API
> >>   	select VFIO_IOMMU_TYPE1 if X86
> >> +	select VFIO_IOMMU_SPAPR_TCE if PPC_POWERNV
> >>   	help
> >>   	  VFIO provides a framework for secure userspace device drivers.
> >>   	  See Documentation/vfio.txt for more details.
> >> diff --git a/drivers/vfio/Makefile b/drivers/vfio/Makefile
> >> index 2398d4a..72bfabc 100644
> >> --- a/drivers/vfio/Makefile
> >> +++ b/drivers/vfio/Makefile
> >> @@ -1,3 +1,4 @@
> >>   obj-$(CONFIG_VFIO) += vfio.o
> >>   obj-$(CONFIG_VFIO_IOMMU_TYPE1) += vfio_iommu_type1.o
> >> +obj-$(CONFIG_VFIO_IOMMU_SPAPR_TCE) += vfio_iommu_spapr_tce.o
> >>   obj-$(CONFIG_VFIO_PCI) += pci/
> >> diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c b/drivers/vfio/vfio_iommu_spapr_tce.c
> >> new file mode 100644
> >> index 0000000..9b3fa88
> >> --- /dev/null
> >> +++ b/drivers/vfio/vfio_iommu_spapr_tce.c
> >> @@ -0,0 +1,269 @@
> >> +/*
> >> + * VFIO: IOMMU DMA mapping support for TCE on POWER
> >> + *
> >> + * Copyright (C) 2012 IBM Corp.  All rights reserved.
> >
> > 2013 now
> >
> >> + *     Author: Alexey Kardashevskiy <aik@ozlabs.ru>
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify
> >> + * it under the terms of the GNU General Public License version 2 as
> >> + * published by the Free Software Foundation.
> >> + *
> >> + * Derived from original vfio_iommu_type1.c:
> >> + * Copyright (C) 2012 Red Hat, Inc.  All rights reserved.
> >> + *     Author: Alex Williamson <alex.williamson@redhat.com>
> >> + */
> >> +
> >> +#include <linux/module.h>
> >> +#include <linux/pci.h>
> >> +#include <linux/slab.h>
> >> +#include <linux/uaccess.h>
> >> +#include <linux/err.h>
> >> +#include <linux/vfio.h>
> >> +#include <asm/iommu.h>
> >> +#include <asm/tce.h>
> >> +
> >> +#define DRIVER_VERSION  "0.1"
> >> +#define DRIVER_AUTHOR   "aik@ozlabs.ru"
> >> +#define DRIVER_DESC     "VFIO IOMMU SPAPR TCE"
> >> +
> >> +static void tce_iommu_detach_group(void *iommu_data,
> >> +		struct iommu_group *iommu_group);
> >> +
> >> +/*
> >> + * VFIO IOMMU fd for SPAPR_TCE IOMMU implementation
> >> + *
> >> + * This code handles mapping and unmapping of user data buffers
> >> + * into DMA'ble space using the IOMMU
> >> + */
> >> +
> >> +/*
> >> + * The container descriptor supports only a single group per container.
> >> + * Required by the API as the container is not supplied with the IOMMU group
> >> + * at the moment of initialization.
> >> + */
> >> +struct tce_container {
> >> +	struct mutex lock;
> >> +	struct iommu_table *tbl;
> >> +};
> >> +
> >> +static void *tce_iommu_open(unsigned long arg)
> >> +{
> >> +	struct tce_container *container;
> >> +
> >> +	if (arg != VFIO_SPAPR_TCE_IOMMU) {
> >> +		pr_err("tce_vfio: Wrong IOMMU type\n");
> >> +		return ERR_PTR(-EINVAL);
> >> +	}
> >> +
> >> +	container = kzalloc(sizeof(*container), GFP_KERNEL);
> >> +	if (!container)
> >> +		return ERR_PTR(-ENOMEM);
> >> +
> >> +	mutex_init(&container->lock);
> >> +
> >> +	return container;
> >> +}
> >> +
> >> +static void tce_iommu_release(void *iommu_data)
> >> +{
> >> +	struct tce_container *container = iommu_data;
> >> +
> >> +	WARN_ON(container->tbl && !container->tbl->it_group);
> >> +	if (container->tbl && container->tbl->it_group)
> >> +		tce_iommu_detach_group(iommu_data, container->tbl->it_group);
> >> +
> >> +	mutex_destroy(&container->lock);
> >> +
> >> +	kfree(container);
> >> +}
> >> +
> >> +static long tce_iommu_ioctl(void *iommu_data,
> >> +				 unsigned int cmd, unsigned long arg)
> >> +{
> >> +	struct tce_container *container = iommu_data;
> >> +	unsigned long minsz;
> >> +	long ret;
> >> +
> >> +	switch (cmd) {
> >> +	case VFIO_CHECK_EXTENSION:
> >> +		return (arg == VFIO_SPAPR_TCE_IOMMU) ? 1 : 0;
> >> +
> >> +	case VFIO_IOMMU_SPAPR_TCE_GET_INFO: {
> >> +		struct vfio_iommu_spapr_tce_info info;
> >> +		struct iommu_table *tbl = container->tbl;
> >> +
> >> +		if (WARN_ON(!tbl))
> >> +			return -ENXIO;
> >> +
> >> +		minsz = offsetofend(struct vfio_iommu_spapr_tce_info,
> >> +				dma32_window_size);
> >> +
> >> +		if (copy_from_user(&info, (void __user *)arg, minsz))
> >> +			return -EFAULT;
> >> +
> >> +		if (info.argsz < minsz)
> >> +			return -EINVAL;
> >> +
> >> +		info.dma32_window_start = tbl->it_offset << IOMMU_PAGE_SHIFT;
> >> +		info.dma32_window_size = tbl->it_size << IOMMU_PAGE_SHIFT;
> >> +		info.flags = 0;
> >> +
> >> +		if (copy_to_user((void __user *)arg, &info, minsz))
> >> +			return -EFAULT;
> >> +
> >> +		return 0;
> >> +	}
> >> +	case VFIO_IOMMU_MAP_DMA: {
> >> +		vfio_iommu_spapr_tce_dma_map param;
> >> +		struct iommu_table *tbl = container->tbl;
> >> +		unsigned long tce;
> >> +
> >> +		if (WARN_ON(!tbl))
> >> +			return -ENXIO;
> >> +
> >> +		minsz = offsetofend(vfio_iommu_spapr_tce_dma_map, size);
> >> +
> >> +		if (copy_from_user(&param, (void __user *)arg, minsz))
> >> +			return -EFAULT;
> >> +
> >> +		if (param.argsz < minsz)
> >> +			return -EINVAL;
> >> +
> >> +		if (param.flags & ~(VFIO_DMA_MAP_FLAG_READ |
> >> +				VFIO_DMA_MAP_FLAG_WRITE))
> >> +			return -EINVAL;
> >> +
> >> +		if ((param.size & ~IOMMU_PAGE_MASK) ||
> >> +				(param.vaddr & ~IOMMU_PAGE_MASK))
> >> +			return -EINVAL;
> >> +
> >> +		/* TODO: support multiple TCEs */
> >> +		if (param.size != IOMMU_PAGE_SIZE) {
> >
> > Ouch, ioctl per page...
> 
> Well, there is something to discuss.
> 
> On POWER, there is an interface to add multiple pages at once but the guest 
> does not supply the range of guest phys addresses, it puts some addresses 
> to a small page (so it is up to 512 pages at once) and passes this address 
> to the host as a parameter.
> 
> I posted another series yesterday but forgot to cc: you :) You can find 
> them here - http://patchwork.ozlabs.org/patch/219592/ (emulated devices) 
> and http://patchwork.ozlabs.org/patch/219594/ (vfio). There I convert guest 
> phys address (real and virtual mode are handled different ways) and call 
> iommu_put_tce_user_mode() (or analog) in a loop.
> 
> Either way, I did some tests with 10Gb card and without real mode stuff it 
> does 220MB/s, and even if I do multi-tce it won't be faster than ~400MB/s 
> which is still not enough as the real mode code makes it 1020MB/s. Slower 
> devices work on the same speed no matter what.

Ok, I'll take a look.

> >> +			pr_err("VFIO map on POWER supports only %lu page size\n",
> >> +					IOMMU_PAGE_SIZE);
> >> +			return -EINVAL;
> >> +		}
> >> +
> >> +		/* iova is checked by the IOMMU API */
> >> +		tce = param.vaddr;
> >> +		if (param.flags & VFIO_DMA_MAP_FLAG_READ)
> >> +			tce |= TCE_PCI_READ;
> >> +		if (param.flags & VFIO_DMA_MAP_FLAG_WRITE)
> >> +			tce |= TCE_PCI_WRITE;
> >> +
> >> +		ret = iommu_put_tce_user_mode(tbl, param.iova, tce);
> >> +		iommu_flush_tce(tbl);
> >> +
> >> +		return ret;
> >> +	}
> >> +	case VFIO_IOMMU_UNMAP_DMA: {
> >> +		vfio_iommu_spapr_tce_dma_unmap param;
> >> +		struct iommu_table *tbl = container->tbl;
> >> +
> >> +		if (WARN_ON(!tbl))
> >> +			return -ENXIO;
> >> +
> >> +		minsz = offsetofend(vfio_iommu_spapr_tce_dma_unmap, size);
> >> +
> >> +		if (copy_from_user(&param, (void __user *)arg, minsz))
> >> +			return -EFAULT;
> >> +
> >> +		if (param.argsz < minsz)
> >> +			return -EINVAL;
> >> +
> >> +		/* No flag is supported now */
> >> +		if (param.flags)
> >> +			return -EINVAL;
> >> +
> >> +		if (param.size & ~IOMMU_PAGE_MASK)
> >> +			return -EINVAL;
> >
> > But you support multi-page unmaps?
> 
> Yes, this is a lot easier :)
> 
> 
> >> +		/* iova is checked by the IOMMU API */
> >> +		ret = iommu_clear_tce_user_mode(tbl, param.iova, 0,
> >> +				param.size >> IOMMU_PAGE_SHIFT);
> >> +		iommu_flush_tce(tbl);
> >> +
> >> +		return ret;
> >> +	}
> >> +	}
> >> +
> >> +	return -ENOTTY;
> >> +}
> >> +
> >> +static int tce_iommu_attach_group(void *iommu_data,
> >> +		struct iommu_group *iommu_group)
> >> +{
> >> +	int ret;
> >> +	struct tce_container *container = iommu_data;
> >> +	struct iommu_table *tbl = iommu_group_get_iommudata(iommu_group);
> >> +
> >> +	BUG_ON(!tbl);
> >> +	mutex_lock(&container->lock);
> >> +	pr_debug("tce_vfio: Attaching group #%u to iommu %p\n",
> >> +			iommu_group_id(iommu_group), iommu_group);
> >> +	if (container->tbl) {
> >> +		pr_warn("tce_vfio: Only one group per IOMMU container is allowed, existing id=%d, attaching id=%d\n",
> >> +				iommu_group_id(container->tbl->it_group),
> >> +				iommu_group_id(iommu_group));
> >> +		mutex_unlock(&container->lock);
> >> +		return -EBUSY;
> >> +	}
> >> +
> >> +	container->tbl = tbl;
> >> +	ret = iommu_lock_table(tbl, true);
> >
> > Bug, container->tbl is set regardless of iommu_lock_table.
> 
> Oops, bug.
> 
> > Ok, so now we're checking rlimits and handling page accounting on
> > VFIO_GROUP_SET_CONTAINER to avoid any overhead at map/unmap.  How can
> > the user learn tbl->it_size to set their locked page limit prior to
> > this?  It's available from GET_INFO, but there's a chicken and egg
> > problem that to get it there you have to get past this, which means
> > you're already ok.  Maybe it's in sysfs somewhere already or it could be
> > exposed in the iommu group like the name attribute.  Otherwise we might
> > consider doing locking on first mapping.  Thanks,
> 
> GET_INFO is called in the beginning so QEMU will exit right there. No real 
> work will have been done till that moment so what is the problem?

GET_INFO uses container->tbl, which is set here, so how could it be
called first?  Thanks,

Alex

> >> +	mutex_unlock(&container->lock);
> >> +
> >> +	return ret;
> >> +}
> >> +
> >> +static void tce_iommu_detach_group(void *iommu_data,
> >> +		struct iommu_group *iommu_group)
> >> +{
> >> +	struct tce_container *container = iommu_data;
> >> +	struct iommu_table *tbl = iommu_group_get_iommudata(iommu_group);
> >> +
> >> +	BUG_ON(!tbl);
> >> +	mutex_lock(&container->lock);
> >> +	if (tbl != container->tbl) {
> >> +		pr_warn("tce_vfio: detaching group #%u, expected group is #%u\n",
> >> +				iommu_group_id(iommu_group),
> >> +				iommu_group_id(tbl->it_group));
> >> +	} else {
> >> +
> >> +		pr_debug("tce_vfio: detaching group #%u from iommu %p\n",
> >> +				iommu_group_id(iommu_group), iommu_group);
> >> +
> >> +		container->tbl = NULL;
> >> +		iommu_lock_table(tbl, false);
> >> +	}
> >> +	mutex_unlock(&container->lock);
> >> +}
> >> +
> >> +const struct vfio_iommu_driver_ops tce_iommu_driver_ops = {
> >> +	.name		= "iommu-vfio-powerpc",
> >> +	.owner		= THIS_MODULE,
> >> +	.open		= tce_iommu_open,
> >> +	.release	= tce_iommu_release,
> >> +	.ioctl		= tce_iommu_ioctl,
> >> +	.attach_group	= tce_iommu_attach_group,
> >> +	.detach_group	= tce_iommu_detach_group,
> >> +};
> >> +
> >> +static int __init tce_iommu_init(void)
> >> +{
> >> +	return vfio_register_iommu_driver(&tce_iommu_driver_ops);
> >> +}
> >> +
> >> +static void __exit tce_iommu_cleanup(void)
> >> +{
> >> +	vfio_unregister_iommu_driver(&tce_iommu_driver_ops);
> >> +}
> >> +
> >> +module_init(tce_iommu_init);
> >> +module_exit(tce_iommu_cleanup);
> >> +
> >> +MODULE_VERSION(DRIVER_VERSION);
> >> +MODULE_LICENSE("GPL v2");
> >> +MODULE_AUTHOR(DRIVER_AUTHOR);
> >> +MODULE_DESCRIPTION(DRIVER_DESC);
> >> +
> >> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> >> index 4758d1b..ea9a9a7 100644
> >> --- a/include/uapi/linux/vfio.h
> >> +++ b/include/uapi/linux/vfio.h
> >> @@ -22,6 +22,7 @@
> >>   /* Extensions */
> >>
> >>   #define VFIO_TYPE1_IOMMU		1
> >> +#define VFIO_SPAPR_TCE_IOMMU		2
> >>
> >>   /*
> >>    * The IOCTL interface is designed for extensibility by embedding the
> >> @@ -365,4 +366,34 @@ struct vfio_iommu_type1_dma_unmap {
> >>
> >>   #define VFIO_IOMMU_UNMAP_DMA _IO(VFIO_TYPE, VFIO_BASE + 14)
> >>
> >> +/* -------- Additional API for SPAPR TCE (Server POWERPC) IOMMU -------- */
> >> +
> >> +/*
> >> + * The SPAPR TCE info struct provides the information about the PCI bus
> >> + * address ranges available for DMA, these values are programmed into
> >> + * the hardware so the guest has to know that information.
> >> + *
> >> + * The DMA 32 bit window start is an absolute PCI bus address.
> >> + * The IOVA address passed via map/unmap ioctls are absolute PCI bus
> >> + * addresses too so the window works as a filter rather than an offset
> >> + * for IOVA addresses.
> >> + *
> >> + * A flag will need to be added if other page sizes are supported,
> >> + * so as defined here, it is always 4k.
> >> + */
> >> +struct vfio_iommu_spapr_tce_info {
> >> +	__u32 argsz;
> >> +	__u32 flags;			/* reserved for future use */
> >> +	__u32 dma32_window_start;	/* 32 bit window start (bytes) */
> >> +	__u32 dma32_window_size;	/* 32 bit window size (bytes) */
> >> +};
> >> +
> >> +#define VFIO_IOMMU_SPAPR_TCE_GET_INFO	_IO(VFIO_TYPE, VFIO_BASE + 12)
> >> +
> >> +/* Reuse type1 map/unmap structs as they are the same at the moment */
> >> +typedef struct vfio_iommu_type1_dma_map vfio_iommu_spapr_tce_dma_map;
> >> +typedef struct vfio_iommu_type1_dma_unmap vfio_iommu_spapr_tce_dma_unmap;
> >> +
> >> +/* ***************************************************************** */
> >> +
> >>   #endif /* _UAPIVFIO_H */
> >
> >
> >
> 
> 

[PATCH] iommu: making IOMMU sysfs nodes API public

[Alexey Kardashevskiy]

Having this patch in a tree, adding new nodes in sysfs
for IOMMU groups is going to be easier.

The first candidate for this change is a "dma-window-size"
property which tells a size of a DMA window of the specific
IOMMU group which can be used later for locked pages accounting.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
 drivers/iommu/iommu.c |   19 ++-----------------
 include/linux/iommu.h |   20 ++++++++++++++++++++
 2 files changed, 22 insertions(+), 17 deletions(-)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index b0afd3d..58cc298 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -52,22 +52,6 @@ struct iommu_device {
 	char *name;
 };
 
-struct iommu_group_attribute {
-	struct attribute attr;
-	ssize_t (*show)(struct iommu_group *group, char *buf);
-	ssize_t (*store)(struct iommu_group *group,
-			 const char *buf, size_t count);
-};
-
-#define IOMMU_GROUP_ATTR(_name, _mode, _show, _store)		\
-struct iommu_group_attribute iommu_group_attr_##_name =		\
-	__ATTR(_name, _mode, _show, _store)
-
-#define to_iommu_group_attr(_attr)	\
-	container_of(_attr, struct iommu_group_attribute, attr)
-#define to_iommu_group(_kobj)		\
-	container_of(_kobj, struct iommu_group, kobj)
-
 static ssize_t iommu_group_attr_show(struct kobject *kobj,
 				     struct attribute *__attr, char *buf)
 {
@@ -98,11 +82,12 @@ static const struct sysfs_ops iommu_group_sysfs_ops = {
 	.store = iommu_group_attr_store,
 };
 
-static int iommu_group_create_file(struct iommu_group *group,
+int iommu_group_create_file(struct iommu_group *group,
 				   struct iommu_group_attribute *attr)
 {
 	return sysfs_create_file(&group->kobj, &attr->attr);
 }
+EXPORT_SYMBOL_GPL(iommu_group_create_file);
 
 static void iommu_group_remove_file(struct iommu_group *group,
 				    struct iommu_group_attribute *attr)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index f3b99e1..6d24ba7 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -21,6 +21,7 @@
 
 #include <linux/errno.h>
 #include <linux/types.h>
+#include <linux/stat.h>
 
 #define IOMMU_READ	(1)
 #define IOMMU_WRITE	(2)
@@ -197,6 +198,25 @@ static inline int report_iommu_fault(struct iommu_domain *domain,
 	return ret;
 }
 
+struct iommu_group_attribute {
+	struct attribute attr;
+	ssize_t (*show)(struct iommu_group *group, char *buf);
+	ssize_t (*store)(struct iommu_group *group,
+			 const char *buf, size_t count);
+};
+
+#define IOMMU_GROUP_ATTR(_name, _mode, _show, _store)		\
+struct iommu_group_attribute iommu_group_attr_##_name =		\
+	__ATTR(_name, _mode, _show, _store)
+
+#define to_iommu_group_attr(_attr)	\
+	container_of(_attr, struct iommu_group_attribute, attr)
+#define to_iommu_group(_kobj)		\
+	container_of(_kobj, struct iommu_group, kobj)
+
+extern int iommu_group_create_file(struct iommu_group *group,
+				   struct iommu_group_attribute *attr);
+
 #else /* CONFIG_IOMMU_API */
 
 struct iommu_ops {};
-- 
1.7.10.4

Re: [PATCH] iommu: making IOMMU sysfs nodes API public

[Alex Williamson]

On Tue, 2013-02-12 at 15:06 +1100, Alexey Kardashevskiy wrote:
> Having this patch in a tree, adding new nodes in sysfs
> for IOMMU groups is going to be easier.
> 
> The first candidate for this change is a "dma-window-size"
> property which tells a size of a DMA window of the specific
> IOMMU group which can be used later for locked pages accounting.

I'm still churning on this one; I'm nervous this would basically creat
a /proc free-for-all under /sys/kernel/iommu_group/$GROUP/ where any
iommu driver can add random attributes.  That can get ugly for
userspace.

On the other hand, for the application of userspace knowing how much
memory to lock for vfio use of a group, it's an appealing location to
get that information.  Something like libvirt would already be poking
around here to figure out which devices to bind.  Page limits need to be
setup prior to use through vfio, so sysfs is more convenient than
through vfio ioctls.

But then is dma-window-size just a vfio requirement leaking over into
iommu groups?  Can we allow iommu driver based attributes without giving
up control of the namespace?  Thanks,

Alex

> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
>  drivers/iommu/iommu.c |   19 ++-----------------
>  include/linux/iommu.h |   20 ++++++++++++++++++++
>  2 files changed, 22 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index b0afd3d..58cc298 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -52,22 +52,6 @@ struct iommu_device {
>  	char *name;
>  };
>  
> -struct iommu_group_attribute {
> -	struct attribute attr;
> -	ssize_t (*show)(struct iommu_group *group, char *buf);
> -	ssize_t (*store)(struct iommu_group *group,
> -			 const char *buf, size_t count);
> -};
> -
> -#define IOMMU_GROUP_ATTR(_name, _mode, _show, _store)		\
> -struct iommu_group_attribute iommu_group_attr_##_name =		\
> -	__ATTR(_name, _mode, _show, _store)
> -
> -#define to_iommu_group_attr(_attr)	\
> -	container_of(_attr, struct iommu_group_attribute, attr)
> -#define to_iommu_group(_kobj)		\
> -	container_of(_kobj, struct iommu_group, kobj)
> -
>  static ssize_t iommu_group_attr_show(struct kobject *kobj,
>  				     struct attribute *__attr, char *buf)
>  {
> @@ -98,11 +82,12 @@ static const struct sysfs_ops iommu_group_sysfs_ops = {
>  	.store = iommu_group_attr_store,
>  };
>  
> -static int iommu_group_create_file(struct iommu_group *group,
> +int iommu_group_create_file(struct iommu_group *group,
>  				   struct iommu_group_attribute *attr)
>  {
>  	return sysfs_create_file(&group->kobj, &attr->attr);
>  }
> +EXPORT_SYMBOL_GPL(iommu_group_create_file);
>  
>  static void iommu_group_remove_file(struct iommu_group *group,
>  				    struct iommu_group_attribute *attr)
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index f3b99e1..6d24ba7 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -21,6 +21,7 @@
>  
>  #include <linux/errno.h>
>  #include <linux/types.h>
> +#include <linux/stat.h>
>  
>  #define IOMMU_READ	(1)
>  #define IOMMU_WRITE	(2)
> @@ -197,6 +198,25 @@ static inline int report_iommu_fault(struct iommu_domain *domain,
>  	return ret;
>  }
>  
> +struct iommu_group_attribute {
> +	struct attribute attr;
> +	ssize_t (*show)(struct iommu_group *group, char *buf);
> +	ssize_t (*store)(struct iommu_group *group,
> +			 const char *buf, size_t count);
> +};
> +
> +#define IOMMU_GROUP_ATTR(_name, _mode, _show, _store)		\
> +struct iommu_group_attribute iommu_group_attr_##_name =		\
> +	__ATTR(_name, _mode, _show, _store)
> +
> +#define to_iommu_group_attr(_attr)	\
> +	container_of(_attr, struct iommu_group_attribute, attr)
> +#define to_iommu_group(_kobj)		\
> +	container_of(_kobj, struct iommu_group, kobj)
> +
> +extern int iommu_group_create_file(struct iommu_group *group,
> +				   struct iommu_group_attribute *attr);
> +
>  #else /* CONFIG_IOMMU_API */
>  
>  struct iommu_ops {};

Re: [PATCH] iommu: making IOMMU sysfs nodes API public

[Alexey Kardashevskiy]

On 12/02/13 16:07, Alex Williamson wrote:
> On Tue, 2013-02-12 at 15:06 +1100, Alexey Kardashevskiy wrote:
>> Having this patch in a tree, adding new nodes in sysfs
>> for IOMMU groups is going to be easier.
>>
>> The first candidate for this change is a "dma-window-size"
>> property which tells a size of a DMA window of the specific
>> IOMMU group which can be used later for locked pages accounting.
>
> I'm still churning on this one; I'm nervous this would basically creat
> a /proc free-for-all under /sys/kernel/iommu_group/$GROUP/ where any
> iommu driver can add random attributes.  That can get ugly for
> userspace.

Is not it exactly what sysfs is for (unlike /proc)? :)


> On the other hand, for the application of userspace knowing how much
> memory to lock for vfio use of a group, it's an appealing location to
> get that information.  Something like libvirt would already be poking
> around here to figure out which devices to bind.  Page limits need to be
> setup prior to use through vfio, so sysfs is more convenient than
> through vfio ioctls.

True. DMA window properties do not change since boot so sysfs is the right 
place to expose them.

> But then is dma-window-size just a vfio requirement leaking over into
> iommu groups?  Can we allow iommu driver based attributes without giving
> up control of the namespace?  Thanks,

Who are you asking these questions? :)


> Alex
>
>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>> ---
>>   drivers/iommu/iommu.c |   19 ++-----------------
>>   include/linux/iommu.h |   20 ++++++++++++++++++++
>>   2 files changed, 22 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
>> index b0afd3d..58cc298 100644
>> --- a/drivers/iommu/iommu.c
>> +++ b/drivers/iommu/iommu.c
>> @@ -52,22 +52,6 @@ struct iommu_device {
>>   	char *name;
>>   };
>>
>> -struct iommu_group_attribute {
>> -	struct attribute attr;
>> -	ssize_t (*show)(struct iommu_group *group, char *buf);
>> -	ssize_t (*store)(struct iommu_group *group,
>> -			 const char *buf, size_t count);
>> -};
>> -
>> -#define IOMMU_GROUP_ATTR(_name, _mode, _show, _store)		\
>> -struct iommu_group_attribute iommu_group_attr_##_name =		\
>> -	__ATTR(_name, _mode, _show, _store)
>> -
>> -#define to_iommu_group_attr(_attr)	\
>> -	container_of(_attr, struct iommu_group_attribute, attr)
>> -#define to_iommu_group(_kobj)		\
>> -	container_of(_kobj, struct iommu_group, kobj)
>> -
>>   static ssize_t iommu_group_attr_show(struct kobject *kobj,
>>   				     struct attribute *__attr, char *buf)
>>   {
>> @@ -98,11 +82,12 @@ static const struct sysfs_ops iommu_group_sysfs_ops = {
>>   	.store = iommu_group_attr_store,
>>   };
>>
>> -static int iommu_group_create_file(struct iommu_group *group,
>> +int iommu_group_create_file(struct iommu_group *group,
>>   				   struct iommu_group_attribute *attr)
>>   {
>>   	return sysfs_create_file(&group->kobj, &attr->attr);
>>   }
>> +EXPORT_SYMBOL_GPL(iommu_group_create_file);
>>
>>   static void iommu_group_remove_file(struct iommu_group *group,
>>   				    struct iommu_group_attribute *attr)
>> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
>> index f3b99e1..6d24ba7 100644
>> --- a/include/linux/iommu.h
>> +++ b/include/linux/iommu.h
>> @@ -21,6 +21,7 @@
>>
>>   #include <linux/errno.h>
>>   #include <linux/types.h>
>> +#include <linux/stat.h>
>>
>>   #define IOMMU_READ	(1)
>>   #define IOMMU_WRITE	(2)
>> @@ -197,6 +198,25 @@ static inline int report_iommu_fault(struct iommu_domain *domain,
>>   	return ret;
>>   }
>>
>> +struct iommu_group_attribute {
>> +	struct attribute attr;
>> +	ssize_t (*show)(struct iommu_group *group, char *buf);
>> +	ssize_t (*store)(struct iommu_group *group,
>> +			 const char *buf, size_t count);
>> +};
>> +
>> +#define IOMMU_GROUP_ATTR(_name, _mode, _show, _store)		\
>> +struct iommu_group_attribute iommu_group_attr_##_name =		\
>> +	__ATTR(_name, _mode, _show, _store)
>> +
>> +#define to_iommu_group_attr(_attr)	\
>> +	container_of(_attr, struct iommu_group_attribute, attr)
>> +#define to_iommu_group(_kobj)		\
>> +	container_of(_kobj, struct iommu_group, kobj)
>> +
>> +extern int iommu_group_create_file(struct iommu_group *group,
>> +				   struct iommu_group_attribute *attr);
>> +
>>   #else /* CONFIG_IOMMU_API */
>>
>>   struct iommu_ops {};
>
>
>


-- 
Alexey

Re: [PATCH] iommu: making IOMMU sysfs nodes API public

[Alex Williamson]

On Wed, 2013-02-13 at 01:42 +1100, Alexey Kardashevskiy wrote:
> On 12/02/13 16:07, Alex Williamson wrote:
> > On Tue, 2013-02-12 at 15:06 +1100, Alexey Kardashevskiy wrote:
> >> Having this patch in a tree, adding new nodes in sysfs
> >> for IOMMU groups is going to be easier.
> >>
> >> The first candidate for this change is a "dma-window-size"
> >> property which tells a size of a DMA window of the specific
> >> IOMMU group which can be used later for locked pages accounting.
> >
> > I'm still churning on this one; I'm nervous this would basically creat
> > a /proc free-for-all under /sys/kernel/iommu_group/$GROUP/ where any
> > iommu driver can add random attributes.  That can get ugly for
> > userspace.
> 
> Is not it exactly what sysfs is for (unlike /proc)? :)

Um, I hope it's a little more thought out than /proc.

> > On the other hand, for the application of userspace knowing how much
> > memory to lock for vfio use of a group, it's an appealing location to
> > get that information.  Something like libvirt would already be poking
> > around here to figure out which devices to bind.  Page limits need to be
> > setup prior to use through vfio, so sysfs is more convenient than
> > through vfio ioctls.
> 
> True. DMA window properties do not change since boot so sysfs is the right 
> place to expose them.
>
> > But then is dma-window-size just a vfio requirement leaking over into
> > iommu groups?  Can we allow iommu driver based attributes without giving
> > up control of the namespace?  Thanks,
> 
> Who are you asking these questions? :)

Anyone, including you.  Rather than dropping misc files in sysfs to
describe things about the group, I think the better solution in your
case might be a link from the group to an existing sysfs directory
describing the PE.  I believe your PE is rooted in a PCI bridge, so that
presumably already has a representation in sysfs.  Can the aperture size
be determined from something in sysfs for that bridge already?  I'm just
not ready to create a grab bag of sysfs entries for a group yet.
Thanks,

Alex

> >> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> >> ---
> >>   drivers/iommu/iommu.c |   19 ++-----------------
> >>   include/linux/iommu.h |   20 ++++++++++++++++++++
> >>   2 files changed, 22 insertions(+), 17 deletions(-)
> >>
> >> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> >> index b0afd3d..58cc298 100644
> >> --- a/drivers/iommu/iommu.c
> >> +++ b/drivers/iommu/iommu.c
> >> @@ -52,22 +52,6 @@ struct iommu_device {
> >>   	char *name;
> >>   };
> >>
> >> -struct iommu_group_attribute {
> >> -	struct attribute attr;
> >> -	ssize_t (*show)(struct iommu_group *group, char *buf);
> >> -	ssize_t (*store)(struct iommu_group *group,
> >> -			 const char *buf, size_t count);
> >> -};
> >> -
> >> -#define IOMMU_GROUP_ATTR(_name, _mode, _show, _store)		\
> >> -struct iommu_group_attribute iommu_group_attr_##_name =		\
> >> -	__ATTR(_name, _mode, _show, _store)
> >> -
> >> -#define to_iommu_group_attr(_attr)	\
> >> -	container_of(_attr, struct iommu_group_attribute, attr)
> >> -#define to_iommu_group(_kobj)		\
> >> -	container_of(_kobj, struct iommu_group, kobj)
> >> -
> >>   static ssize_t iommu_group_attr_show(struct kobject *kobj,
> >>   				     struct attribute *__attr, char *buf)
> >>   {
> >> @@ -98,11 +82,12 @@ static const struct sysfs_ops iommu_group_sysfs_ops = {
> >>   	.store = iommu_group_attr_store,
> >>   };
> >>
> >> -static int iommu_group_create_file(struct iommu_group *group,
> >> +int iommu_group_create_file(struct iommu_group *group,
> >>   				   struct iommu_group_attribute *attr)
> >>   {
> >>   	return sysfs_create_file(&group->kobj, &attr->attr);
> >>   }
> >> +EXPORT_SYMBOL_GPL(iommu_group_create_file);
> >>
> >>   static void iommu_group_remove_file(struct iommu_group *group,
> >>   				    struct iommu_group_attribute *attr)
> >> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> >> index f3b99e1..6d24ba7 100644
> >> --- a/include/linux/iommu.h
> >> +++ b/include/linux/iommu.h
> >> @@ -21,6 +21,7 @@
> >>
> >>   #include <linux/errno.h>
> >>   #include <linux/types.h>
> >> +#include <linux/stat.h>
> >>
> >>   #define IOMMU_READ	(1)
> >>   #define IOMMU_WRITE	(2)
> >> @@ -197,6 +198,25 @@ static inline int report_iommu_fault(struct iommu_domain *domain,
> >>   	return ret;
> >>   }
> >>
> >> +struct iommu_group_attribute {
> >> +	struct attribute attr;
> >> +	ssize_t (*show)(struct iommu_group *group, char *buf);
> >> +	ssize_t (*store)(struct iommu_group *group,
> >> +			 const char *buf, size_t count);
> >> +};
> >> +
> >> +#define IOMMU_GROUP_ATTR(_name, _mode, _show, _store)		\
> >> +struct iommu_group_attribute iommu_group_attr_##_name =		\
> >> +	__ATTR(_name, _mode, _show, _store)
> >> +
> >> +#define to_iommu_group_attr(_attr)	\
> >> +	container_of(_attr, struct iommu_group_attribute, attr)
> >> +#define to_iommu_group(_kobj)		\
> >> +	container_of(_kobj, struct iommu_group, kobj)
> >> +
> >> +extern int iommu_group_create_file(struct iommu_group *group,
> >> +				   struct iommu_group_attribute *attr);
> >> +
> >>   #else /* CONFIG_IOMMU_API */
> >>
> >>   struct iommu_ops {};
> >
> >
> >
> 
> 

Re: [PATCH] iommu: making IOMMU sysfs nodes API public

[Alexey Kardashevskiy]

On 13/02/13 04:15, Alex Williamson wrote:
> On Wed, 2013-02-13 at 01:42 +1100, Alexey Kardashevskiy wrote:
>> On 12/02/13 16:07, Alex Williamson wrote:
>>> On Tue, 2013-02-12 at 15:06 +1100, Alexey Kardashevskiy wrote:
>>>> Having this patch in a tree, adding new nodes in sysfs
>>>> for IOMMU groups is going to be easier.
>>>>
>>>> The first candidate for this change is a "dma-window-size"
>>>> property which tells a size of a DMA window of the specific
>>>> IOMMU group which can be used later for locked pages accounting.
>>>
>>> I'm still churning on this one; I'm nervous this would basically creat
>>> a /proc free-for-all under /sys/kernel/iommu_group/$GROUP/ where any
>>> iommu driver can add random attributes.  That can get ugly for
>>> userspace.
>>
>> Is not it exactly what sysfs is for (unlike /proc)? :)
>
> Um, I hope it's a little more thought out than /proc.
>
>>> On the other hand, for the application of userspace knowing how much
>>> memory to lock for vfio use of a group, it's an appealing location to
>>> get that information.  Something like libvirt would already be poking
>>> around here to figure out which devices to bind.  Page limits need to be
>>> setup prior to use through vfio, so sysfs is more convenient than
>>> through vfio ioctls.
>>
>> True. DMA window properties do not change since boot so sysfs is the right
>> place to expose them.
>>
>>> But then is dma-window-size just a vfio requirement leaking over into
>>> iommu groups?  Can we allow iommu driver based attributes without giving
>>> up control of the namespace?  Thanks,
>>
>> Who are you asking these questions? :)
>
> Anyone, including you.  Rather than dropping misc files in sysfs to
> describe things about the group, I think the better solution in your
> case might be a link from the group to an existing sysfs directory
> describing the PE.  I believe your PE is rooted in a PCI bridge, so that
> presumably already has a representation in sysfs.  Can the aperture size
> be determined from something in sysfs for that bridge already?  I'm just
> not ready to create a grab bag of sysfs entries for a group yet.
> Thanks,


At the moment there is no information neither in sysfs nor 
/proc/device-tree about the dma-window. And adding a sysfs entry per PE 
(powerpc partitionable end-point which is often a PHB but not always) just 
for VFIO is quite heavy.

We could add a ppc64 subfolder under /sys/kernel/iommu/xxx/ and put the 
"dma-window" property there. And replace it with a symlink when and if we 
add something for PE later. Would work?



> Alex
>
>>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>>>> ---
>>>>    drivers/iommu/iommu.c |   19 ++-----------------
>>>>    include/linux/iommu.h |   20 ++++++++++++++++++++
>>>>    2 files changed, 22 insertions(+), 17 deletions(-)
>>>>
>>>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
>>>> index b0afd3d..58cc298 100644
>>>> --- a/drivers/iommu/iommu.c
>>>> +++ b/drivers/iommu/iommu.c
>>>> @@ -52,22 +52,6 @@ struct iommu_device {
>>>>    	char *name;
>>>>    };
>>>>
>>>> -struct iommu_group_attribute {
>>>> -	struct attribute attr;
>>>> -	ssize_t (*show)(struct iommu_group *group, char *buf);
>>>> -	ssize_t (*store)(struct iommu_group *group,
>>>> -			 const char *buf, size_t count);
>>>> -};
>>>> -
>>>> -#define IOMMU_GROUP_ATTR(_name, _mode, _show, _store)		\
>>>> -struct iommu_group_attribute iommu_group_attr_##_name =		\
>>>> -	__ATTR(_name, _mode, _show, _store)
>>>> -
>>>> -#define to_iommu_group_attr(_attr)	\
>>>> -	container_of(_attr, struct iommu_group_attribute, attr)
>>>> -#define to_iommu_group(_kobj)		\
>>>> -	container_of(_kobj, struct iommu_group, kobj)
>>>> -
>>>>    static ssize_t iommu_group_attr_show(struct kobject *kobj,
>>>>    				     struct attribute *__attr, char *buf)
>>>>    {
>>>> @@ -98,11 +82,12 @@ static const struct sysfs_ops iommu_group_sysfs_ops = {
>>>>    	.store = iommu_group_attr_store,
>>>>    };
>>>>
>>>> -static int iommu_group_create_file(struct iommu_group *group,
>>>> +int iommu_group_create_file(struct iommu_group *group,
>>>>    				   struct iommu_group_attribute *attr)
>>>>    {
>>>>    	return sysfs_create_file(&group->kobj, &attr->attr);
>>>>    }
>>>> +EXPORT_SYMBOL_GPL(iommu_group_create_file);
>>>>
>>>>    static void iommu_group_remove_file(struct iommu_group *group,
>>>>    				    struct iommu_group_attribute *attr)
>>>> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
>>>> index f3b99e1..6d24ba7 100644
>>>> --- a/include/linux/iommu.h
>>>> +++ b/include/linux/iommu.h
>>>> @@ -21,6 +21,7 @@
>>>>
>>>>    #include <linux/errno.h>
>>>>    #include <linux/types.h>
>>>> +#include <linux/stat.h>
>>>>
>>>>    #define IOMMU_READ	(1)
>>>>    #define IOMMU_WRITE	(2)
>>>> @@ -197,6 +198,25 @@ static inline int report_iommu_fault(struct iommu_domain *domain,
>>>>    	return ret;
>>>>    }
>>>>
>>>> +struct iommu_group_attribute {
>>>> +	struct attribute attr;
>>>> +	ssize_t (*show)(struct iommu_group *group, char *buf);
>>>> +	ssize_t (*store)(struct iommu_group *group,
>>>> +			 const char *buf, size_t count);
>>>> +};
>>>> +
>>>> +#define IOMMU_GROUP_ATTR(_name, _mode, _show, _store)		\
>>>> +struct iommu_group_attribute iommu_group_attr_##_name =		\
>>>> +	__ATTR(_name, _mode, _show, _store)
>>>> +
>>>> +#define to_iommu_group_attr(_attr)	\
>>>> +	container_of(_attr, struct iommu_group_attribute, attr)
>>>> +#define to_iommu_group(_kobj)		\
>>>> +	container_of(_kobj, struct iommu_group, kobj)
>>>> +
>>>> +extern int iommu_group_create_file(struct iommu_group *group,
>>>> +				   struct iommu_group_attribute *attr);
>>>> +
>>>>    #else /* CONFIG_IOMMU_API */
>>>>
>>>>    struct iommu_ops {};


-- 
Alexey

Re: [PATCH] iommu: making IOMMU sysfs nodes API public

[Alex Williamson]

On Mon, 2013-02-18 at 17:15 +1100, Alexey Kardashevskiy wrote:
> On 13/02/13 04:15, Alex Williamson wrote:
> > On Wed, 2013-02-13 at 01:42 +1100, Alexey Kardashevskiy wrote:
> >> On 12/02/13 16:07, Alex Williamson wrote:
> >>> On Tue, 2013-02-12 at 15:06 +1100, Alexey Kardashevskiy wrote:
> >>>> Having this patch in a tree, adding new nodes in sysfs
> >>>> for IOMMU groups is going to be easier.
> >>>>
> >>>> The first candidate for this change is a "dma-window-size"
> >>>> property which tells a size of a DMA window of the specific
> >>>> IOMMU group which can be used later for locked pages accounting.
> >>>
> >>> I'm still churning on this one; I'm nervous this would basically creat
> >>> a /proc free-for-all under /sys/kernel/iommu_group/$GROUP/ where any
> >>> iommu driver can add random attributes.  That can get ugly for
> >>> userspace.
> >>
> >> Is not it exactly what sysfs is for (unlike /proc)? :)
> >
> > Um, I hope it's a little more thought out than /proc.
> >
> >>> On the other hand, for the application of userspace knowing how much
> >>> memory to lock for vfio use of a group, it's an appealing location to
> >>> get that information.  Something like libvirt would already be poking
> >>> around here to figure out which devices to bind.  Page limits need to be
> >>> setup prior to use through vfio, so sysfs is more convenient than
> >>> through vfio ioctls.
> >>
> >> True. DMA window properties do not change since boot so sysfs is the right
> >> place to expose them.
> >>
> >>> But then is dma-window-size just a vfio requirement leaking over into
> >>> iommu groups?  Can we allow iommu driver based attributes without giving
> >>> up control of the namespace?  Thanks,
> >>
> >> Who are you asking these questions? :)
> >
> > Anyone, including you.  Rather than dropping misc files in sysfs to
> > describe things about the group, I think the better solution in your
> > case might be a link from the group to an existing sysfs directory
> > describing the PE.  I believe your PE is rooted in a PCI bridge, so that
> > presumably already has a representation in sysfs.  Can the aperture size
> > be determined from something in sysfs for that bridge already?  I'm just
> > not ready to create a grab bag of sysfs entries for a group yet.
> > Thanks,
> 
> 
> At the moment there is no information neither in sysfs nor 
> /proc/device-tree about the dma-window. And adding a sysfs entry per PE 
> (powerpc partitionable end-point which is often a PHB but not always) just 
> for VFIO is quite heavy.

How do you learn the window size and PE extents in the host kernel?

> We could add a ppc64 subfolder under /sys/kernel/iommu/xxx/ and put the 
> "dma-window" property there. And replace it with a symlink when and if we 
> add something for PE later. Would work?

To be clear, you're suggesting /sys/kernel/iommu_groups/$GROUP/xxx/,
right?  A subfolder really only limits the scope of the mess, so it's
not much improvement.  What does the interface look like to make those
subfolders?

The problem we're trying to solve is this call flow:

containerfd = open("/dev/vfio/vfio");
ioctl(containerfd, VFIO_GET_API_VERSION);
ioctl(containerfd, VFIO_CHECK_EXTENSION, ...);
groupfd = open("/dev/vfio/$GROUP");
ioctl(groupfd, VFIO_GROUP_GET_STATUS);
ioctl(groupfd, VFIO_GROUP_SET_CONTAINER, &containerfd);

You wanted to lock all the memory for the DMA window here, before we can
call VFIO_IOMMU_GET_INFO, but does it need to happen there?  We still
have a MAP_DMA hook.  We could do it all on the first mapping.  It also
has a flags field that could augment the behavior to trigger page
locking.  Adding the window size to sysfs seems more readily convenient,
but is it so hard for userspace to open the files and call a couple
ioctls to get far enough to call IOMMU_GET_INFO?  I'm unconvinced the
clutter in sysfs more than just a quick fix.  Thanks,

Alex

> >>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> >>>> ---
> >>>>    drivers/iommu/iommu.c |   19 ++-----------------
> >>>>    include/linux/iommu.h |   20 ++++++++++++++++++++
> >>>>    2 files changed, 22 insertions(+), 17 deletions(-)
> >>>>
> >>>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> >>>> index b0afd3d..58cc298 100644
> >>>> --- a/drivers/iommu/iommu.c
> >>>> +++ b/drivers/iommu/iommu.c
> >>>> @@ -52,22 +52,6 @@ struct iommu_device {
> >>>>    	char *name;
> >>>>    };
> >>>>
> >>>> -struct iommu_group_attribute {
> >>>> -	struct attribute attr;
> >>>> -	ssize_t (*show)(struct iommu_group *group, char *buf);
> >>>> -	ssize_t (*store)(struct iommu_group *group,
> >>>> -			 const char *buf, size_t count);
> >>>> -};
> >>>> -
> >>>> -#define IOMMU_GROUP_ATTR(_name, _mode, _show, _store)		\
> >>>> -struct iommu_group_attribute iommu_group_attr_##_name =		\
> >>>> -	__ATTR(_name, _mode, _show, _store)
> >>>> -
> >>>> -#define to_iommu_group_attr(_attr)	\
> >>>> -	container_of(_attr, struct iommu_group_attribute, attr)
> >>>> -#define to_iommu_group(_kobj)		\
> >>>> -	container_of(_kobj, struct iommu_group, kobj)
> >>>> -
> >>>>    static ssize_t iommu_group_attr_show(struct kobject *kobj,
> >>>>    				     struct attribute *__attr, char *buf)
> >>>>    {
> >>>> @@ -98,11 +82,12 @@ static const struct sysfs_ops iommu_group_sysfs_ops = {
> >>>>    	.store = iommu_group_attr_store,
> >>>>    };
> >>>>
> >>>> -static int iommu_group_create_file(struct iommu_group *group,
> >>>> +int iommu_group_create_file(struct iommu_group *group,
> >>>>    				   struct iommu_group_attribute *attr)
> >>>>    {
> >>>>    	return sysfs_create_file(&group->kobj, &attr->attr);
> >>>>    }
> >>>> +EXPORT_SYMBOL_GPL(iommu_group_create_file);
> >>>>
> >>>>    static void iommu_group_remove_file(struct iommu_group *group,
> >>>>    				    struct iommu_group_attribute *attr)
> >>>> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> >>>> index f3b99e1..6d24ba7 100644
> >>>> --- a/include/linux/iommu.h
> >>>> +++ b/include/linux/iommu.h
> >>>> @@ -21,6 +21,7 @@
> >>>>
> >>>>    #include <linux/errno.h>
> >>>>    #include <linux/types.h>
> >>>> +#include <linux/stat.h>
> >>>>
> >>>>    #define IOMMU_READ	(1)
> >>>>    #define IOMMU_WRITE	(2)
> >>>> @@ -197,6 +198,25 @@ static inline int report_iommu_fault(struct iommu_domain *domain,
> >>>>    	return ret;
> >>>>    }
> >>>>
> >>>> +struct iommu_group_attribute {
> >>>> +	struct attribute attr;
> >>>> +	ssize_t (*show)(struct iommu_group *group, char *buf);
> >>>> +	ssize_t (*store)(struct iommu_group *group,
> >>>> +			 const char *buf, size_t count);
> >>>> +};
> >>>> +
> >>>> +#define IOMMU_GROUP_ATTR(_name, _mode, _show, _store)		\
> >>>> +struct iommu_group_attribute iommu_group_attr_##_name =		\
> >>>> +	__ATTR(_name, _mode, _show, _store)
> >>>> +
> >>>> +#define to_iommu_group_attr(_attr)	\
> >>>> +	container_of(_attr, struct iommu_group_attribute, attr)
> >>>> +#define to_iommu_group(_kobj)		\
> >>>> +	container_of(_kobj, struct iommu_group, kobj)
> >>>> +
> >>>> +extern int iommu_group_create_file(struct iommu_group *group,
> >>>> +				   struct iommu_group_attribute *attr);
> >>>> +
> >>>>    #else /* CONFIG_IOMMU_API */
> >>>>
> >>>>    struct iommu_ops {};
> 
> 

Re: [PATCH] iommu: making IOMMU sysfs nodes API public

[Alexey Kardashevskiy]

On 19/02/13 16:24, Alex Williamson wrote:
> On Mon, 2013-02-18 at 17:15 +1100, Alexey Kardashevskiy wrote:
>> On 13/02/13 04:15, Alex Williamson wrote:
>>> On Wed, 2013-02-13 at 01:42 +1100, Alexey Kardashevskiy wrote:
>>>> On 12/02/13 16:07, Alex Williamson wrote:
>>>>> On Tue, 2013-02-12 at 15:06 +1100, Alexey Kardashevskiy wrote:
>>>>>> Having this patch in a tree, adding new nodes in sysfs
>>>>>> for IOMMU groups is going to be easier.
>>>>>>
>>>>>> The first candidate for this change is a "dma-window-size"
>>>>>> property which tells a size of a DMA window of the specific
>>>>>> IOMMU group which can be used later for locked pages accounting.
>>>>>
>>>>> I'm still churning on this one; I'm nervous this would basically creat
>>>>> a /proc free-for-all under /sys/kernel/iommu_group/$GROUP/ where any
>>>>> iommu driver can add random attributes.  That can get ugly for
>>>>> userspace.
>>>>
>>>> Is not it exactly what sysfs is for (unlike /proc)? :)
>>>
>>> Um, I hope it's a little more thought out than /proc.
>>>
>>>>> On the other hand, for the application of userspace knowing how much
>>>>> memory to lock for vfio use of a group, it's an appealing location to
>>>>> get that information.  Something like libvirt would already be poking
>>>>> around here to figure out which devices to bind.  Page limits need to be
>>>>> setup prior to use through vfio, so sysfs is more convenient than
>>>>> through vfio ioctls.
>>>>
>>>> True. DMA window properties do not change since boot so sysfs is the right
>>>> place to expose them.
>>>>
>>>>> But then is dma-window-size just a vfio requirement leaking over into
>>>>> iommu groups?  Can we allow iommu driver based attributes without giving
>>>>> up control of the namespace?  Thanks,
>>>>
>>>> Who are you asking these questions? :)
>>>
>>> Anyone, including you.  Rather than dropping misc files in sysfs to
>>> describe things about the group, I think the better solution in your
>>> case might be a link from the group to an existing sysfs directory
>>> describing the PE.  I believe your PE is rooted in a PCI bridge, so that
>>> presumably already has a representation in sysfs.  Can the aperture size
>>> be determined from something in sysfs for that bridge already?  I'm just
>>> not ready to create a grab bag of sysfs entries for a group yet.
>>> Thanks,
>>
>>
>> At the moment there is no information neither in sysfs nor
>> /proc/device-tree about the dma-window. And adding a sysfs entry per PE
>> (powerpc partitionable end-point which is often a PHB but not always) just
>> for VFIO is quite heavy.
>
> How do you learn the window size and PE extents in the host kernel?


When the ppc64 code does PCI scan, it creates iommu_table structs per PE. 
When new PE (i.e. new iommu_table) is discovered I call iommu_group_alloc() 
and iommu_group_set_iommudata() to link iommu_group with iommu_table. These 
iommu_table structs have DMA window properties.


>> We could add a ppc64 subfolder under /sys/kernel/iommu/xxx/ and put the
>> "dma-window" property there. And replace it with a symlink when and if we
>> add something for PE later. Would work?
>
> To be clear, you're suggesting /sys/kernel/iommu_groups/$GROUP/xxx/,
> right?  A subfolder really only limits the scope of the mess, so it's
> not much improvement.

You suggested some symlink to some ppc64 or pci tree in sysfs, it is not 
that different.

> What does the interface look like to make those
> subfolders?

int iommu_group_create_platform_file(struct iommu_group *group,
                      struct iommu_group_attribute *attr)

and that's it.

> The problem we're trying to solve is this call flow:
>
> containerfd = open("/dev/vfio/vfio");
> ioctl(containerfd, VFIO_GET_API_VERSION);
> ioctl(containerfd, VFIO_CHECK_EXTENSION, ...);
> groupfd = open("/dev/vfio/$GROUP");
> ioctl(groupfd, VFIO_GROUP_GET_STATUS);
> ioctl(groupfd, VFIO_GROUP_SET_CONTAINER, &containerfd);
>
> You wanted to lock all the memory for the DMA window here, before we can
> call VFIO_IOMMU_GET_INFO, but does it need to happen there?  We still
> have a MAP_DMA hook.  We could do it all on the first mapping.  It also
> has a flags field that could augment the behavior to trigger page
> locking.  Adding the window size to sysfs seems more readily convenient,
> but is it so hard for userspace to open the files and call a couple
> ioctls to get far enough to call IOMMU_GET_INFO?  I'm unconvinced the
> clutter in sysfs more than just a quick fix.  Thanks,


I thought the problem is that we want to let user set correct rlimit before 
running QEMU, no? We do not change rlimit from QEMU.



>
> Alex
>
>>>>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>>>>>> ---
>>>>>>     drivers/iommu/iommu.c |   19 ++-----------------
>>>>>>     include/linux/iommu.h |   20 ++++++++++++++++++++
>>>>>>     2 files changed, 22 insertions(+), 17 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
>>>>>> index b0afd3d..58cc298 100644
>>>>>> --- a/drivers/iommu/iommu.c
>>>>>> +++ b/drivers/iommu/iommu.c
>>>>>> @@ -52,22 +52,6 @@ struct iommu_device {
>>>>>>     	char *name;
>>>>>>     };
>>>>>>
>>>>>> -struct iommu_group_attribute {
>>>>>> -	struct attribute attr;
>>>>>> -	ssize_t (*show)(struct iommu_group *group, char *buf);
>>>>>> -	ssize_t (*store)(struct iommu_group *group,
>>>>>> -			 const char *buf, size_t count);
>>>>>> -};
>>>>>> -
>>>>>> -#define IOMMU_GROUP_ATTR(_name, _mode, _show, _store)		\
>>>>>> -struct iommu_group_attribute iommu_group_attr_##_name =		\
>>>>>> -	__ATTR(_name, _mode, _show, _store)
>>>>>> -
>>>>>> -#define to_iommu_group_attr(_attr)	\
>>>>>> -	container_of(_attr, struct iommu_group_attribute, attr)
>>>>>> -#define to_iommu_group(_kobj)		\
>>>>>> -	container_of(_kobj, struct iommu_group, kobj)
>>>>>> -
>>>>>>     static ssize_t iommu_group_attr_show(struct kobject *kobj,
>>>>>>     				     struct attribute *__attr, char *buf)
>>>>>>     {
>>>>>> @@ -98,11 +82,12 @@ static const struct sysfs_ops iommu_group_sysfs_ops = {
>>>>>>     	.store = iommu_group_attr_store,
>>>>>>     };
>>>>>>
>>>>>> -static int iommu_group_create_file(struct iommu_group *group,
>>>>>> +int iommu_group_create_file(struct iommu_group *group,
>>>>>>     				   struct iommu_group_attribute *attr)
>>>>>>     {
>>>>>>     	return sysfs_create_file(&group->kobj, &attr->attr);
>>>>>>     }
>>>>>> +EXPORT_SYMBOL_GPL(iommu_group_create_file);
>>>>>>
>>>>>>     static void iommu_group_remove_file(struct iommu_group *group,
>>>>>>     				    struct iommu_group_attribute *attr)
>>>>>> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
>>>>>> index f3b99e1..6d24ba7 100644
>>>>>> --- a/include/linux/iommu.h
>>>>>> +++ b/include/linux/iommu.h
>>>>>> @@ -21,6 +21,7 @@
>>>>>>
>>>>>>     #include <linux/errno.h>
>>>>>>     #include <linux/types.h>
>>>>>> +#include <linux/stat.h>
>>>>>>
>>>>>>     #define IOMMU_READ	(1)
>>>>>>     #define IOMMU_WRITE	(2)
>>>>>> @@ -197,6 +198,25 @@ static inline int report_iommu_fault(struct iommu_domain *domain,
>>>>>>     	return ret;
>>>>>>     }
>>>>>>
>>>>>> +struct iommu_group_attribute {
>>>>>> +	struct attribute attr;
>>>>>> +	ssize_t (*show)(struct iommu_group *group, char *buf);
>>>>>> +	ssize_t (*store)(struct iommu_group *group,
>>>>>> +			 const char *buf, size_t count);
>>>>>> +};
>>>>>> +
>>>>>> +#define IOMMU_GROUP_ATTR(_name, _mode, _show, _store)		\
>>>>>> +struct iommu_group_attribute iommu_group_attr_##_name =		\
>>>>>> +	__ATTR(_name, _mode, _show, _store)
>>>>>> +
>>>>>> +#define to_iommu_group_attr(_attr)	\
>>>>>> +	container_of(_attr, struct iommu_group_attribute, attr)
>>>>>> +#define to_iommu_group(_kobj)		\
>>>>>> +	container_of(_kobj, struct iommu_group, kobj)
>>>>>> +
>>>>>> +extern int iommu_group_create_file(struct iommu_group *group,
>>>>>> +				   struct iommu_group_attribute *attr);
>>>>>> +
>>>>>>     #else /* CONFIG_IOMMU_API */
>>>>>>
>>>>>>     struct iommu_ops {};
>>
>>
>
>
>


-- 
Alexey

Re: [PATCH] iommu: making IOMMU sysfs nodes API public

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 5488 bytes --]

On Mon, Feb 18, 2013 at 10:24:00PM -0700, Alex Williamson wrote:
> On Mon, 2013-02-18 at 17:15 +1100, Alexey Kardashevskiy wrote:
> > On 13/02/13 04:15, Alex Williamson wrote:
> > > On Wed, 2013-02-13 at 01:42 +1100, Alexey Kardashevskiy wrote:
> > >> On 12/02/13 16:07, Alex Williamson wrote:
> > >>> On Tue, 2013-02-12 at 15:06 +1100, Alexey Kardashevskiy wrote:
> > >>>> Having this patch in a tree, adding new nodes in sysfs
> > >>>> for IOMMU groups is going to be easier.
> > >>>>
> > >>>> The first candidate for this change is a "dma-window-size"
> > >>>> property which tells a size of a DMA window of the specific
> > >>>> IOMMU group which can be used later for locked pages accounting.
> > >>>
> > >>> I'm still churning on this one; I'm nervous this would basically creat
> > >>> a /proc free-for-all under /sys/kernel/iommu_group/$GROUP/ where any
> > >>> iommu driver can add random attributes.  That can get ugly for
> > >>> userspace.
> > >>
> > >> Is not it exactly what sysfs is for (unlike /proc)? :)
> > >
> > > Um, I hope it's a little more thought out than /proc.
> > >
> > >>> On the other hand, for the application of userspace knowing how much
> > >>> memory to lock for vfio use of a group, it's an appealing location to
> > >>> get that information.  Something like libvirt would already be poking
> > >>> around here to figure out which devices to bind.  Page limits need to be
> > >>> setup prior to use through vfio, so sysfs is more convenient than
> > >>> through vfio ioctls.
> > >>
> > >> True. DMA window properties do not change since boot so sysfs is the right
> > >> place to expose them.
> > >>
> > >>> But then is dma-window-size just a vfio requirement leaking over into
> > >>> iommu groups?  Can we allow iommu driver based attributes without giving
> > >>> up control of the namespace?  Thanks,
> > >>
> > >> Who are you asking these questions? :)
> > >
> > > Anyone, including you.  Rather than dropping misc files in sysfs to
> > > describe things about the group, I think the better solution in your
> > > case might be a link from the group to an existing sysfs directory
> > > describing the PE.  I believe your PE is rooted in a PCI bridge, so that
> > > presumably already has a representation in sysfs.  Can the aperture size
> > > be determined from something in sysfs for that bridge already?  I'm just
> > > not ready to create a grab bag of sysfs entries for a group yet.
> > > Thanks,
> > 
> > 
> > At the moment there is no information neither in sysfs nor 
> > /proc/device-tree about the dma-window. And adding a sysfs entry per PE 
> > (powerpc partitionable end-point which is often a PHB but not always) just 
> > for VFIO is quite heavy.
> 
> How do you learn the window size and PE extents in the host kernel?
> 
> > We could add a ppc64 subfolder under /sys/kernel/iommu/xxx/ and put the 
> > "dma-window" property there. And replace it with a symlink when and if we 
> > add something for PE later. Would work?

Fwiw, I'd suggest a subfolder named for the type of IOMMU, rather than
"ppc64".

> To be clear, you're suggesting /sys/kernel/iommu_groups/$GROUP/xxx/,
> right?  A subfolder really only limits the scope of the mess, so it's
> not much improvement.  What does the interface look like to make those
> subfolders?
> 
> The problem we're trying to solve is this call flow:
> 
> containerfd = open("/dev/vfio/vfio");
> ioctl(containerfd, VFIO_GET_API_VERSION);
> ioctl(containerfd, VFIO_CHECK_EXTENSION, ...);
> groupfd = open("/dev/vfio/$GROUP");
> ioctl(groupfd, VFIO_GROUP_GET_STATUS);
> ioctl(groupfd, VFIO_GROUP_SET_CONTAINER, &containerfd);
> 
> You wanted to lock all the memory for the DMA window here, before we can
> call VFIO_IOMMU_GET_INFO, but does it need to happen there?  We still
> have a MAP_DMA hook.  We could do it all on the first mapping.

MAP_DMA isn't quite enough, since the guest can also directly cause
mappings using hypercalls directly implemented in KVM.  I think it
would be feasible to lock on the first mapping (either via MAP_DMA, or
H_PUT_TCE) though it would be a bit ugly and require that the first
H_PUT_TCE always bounce out to virtual mode (Alexey, correct me if I'm
wrong here).  IIRC there is also a call to bind the vfio container to
a (qemu assigned) LIOBN, before the guest can use H_PUT_TCE directly,
so that might be another place we could do the lock.

>  It also
> has a flags field that could augment the behavior to trigger page
> locking.

I don't see how the flags help us - we can't have userspace choose to
skip the locked memory accounting.  Or are you suggesting a flag to
open the container in some sort of dummy mode where only GET_INFO is
possible, then re-open with the full locking?

>  Adding the window size to sysfs seems more readily convenient,
> but is it so hard for userspace to open the files and call a couple
> ioctls to get far enough to call IOMMU_GET_INFO?  I'm unconvinced the
> clutter in sysfs more than just a quick fix.  Thanks,

And finally, as Alexey points out, isn't the point here so we know how
much rlimit to give qemu?  Using ioctls we'd need a special tool just
to check the dma window sizes, which seems a bit hideous.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH] iommu: making IOMMU sysfs nodes API public

[Alex Williamson]

On Tue, 2013-02-19 at 16:48 +1100, Alexey Kardashevskiy wrote:
> On 19/02/13 16:24, Alex Williamson wrote:
> > On Mon, 2013-02-18 at 17:15 +1100, Alexey Kardashevskiy wrote:
> >> On 13/02/13 04:15, Alex Williamson wrote:
> >>> On Wed, 2013-02-13 at 01:42 +1100, Alexey Kardashevskiy wrote:
> >>>> On 12/02/13 16:07, Alex Williamson wrote:
> >>>>> On Tue, 2013-02-12 at 15:06 +1100, Alexey Kardashevskiy wrote:
> >>>>>> Having this patch in a tree, adding new nodes in sysfs
> >>>>>> for IOMMU groups is going to be easier.
> >>>>>>
> >>>>>> The first candidate for this change is a "dma-window-size"
> >>>>>> property which tells a size of a DMA window of the specific
> >>>>>> IOMMU group which can be used later for locked pages accounting.
> >>>>>
> >>>>> I'm still churning on this one; I'm nervous this would basically creat
> >>>>> a /proc free-for-all under /sys/kernel/iommu_group/$GROUP/ where any
> >>>>> iommu driver can add random attributes.  That can get ugly for
> >>>>> userspace.
> >>>>
> >>>> Is not it exactly what sysfs is for (unlike /proc)? :)
> >>>
> >>> Um, I hope it's a little more thought out than /proc.
> >>>
> >>>>> On the other hand, for the application of userspace knowing how much
> >>>>> memory to lock for vfio use of a group, it's an appealing location to
> >>>>> get that information.  Something like libvirt would already be poking
> >>>>> around here to figure out which devices to bind.  Page limits need to be
> >>>>> setup prior to use through vfio, so sysfs is more convenient than
> >>>>> through vfio ioctls.
> >>>>
> >>>> True. DMA window properties do not change since boot so sysfs is the right
> >>>> place to expose them.
> >>>>
> >>>>> But then is dma-window-size just a vfio requirement leaking over into
> >>>>> iommu groups?  Can we allow iommu driver based attributes without giving
> >>>>> up control of the namespace?  Thanks,
> >>>>
> >>>> Who are you asking these questions? :)
> >>>
> >>> Anyone, including you.  Rather than dropping misc files in sysfs to
> >>> describe things about the group, I think the better solution in your
> >>> case might be a link from the group to an existing sysfs directory
> >>> describing the PE.  I believe your PE is rooted in a PCI bridge, so that
> >>> presumably already has a representation in sysfs.  Can the aperture size
> >>> be determined from something in sysfs for that bridge already?  I'm just
> >>> not ready to create a grab bag of sysfs entries for a group yet.
> >>> Thanks,
> >>
> >>
> >> At the moment there is no information neither in sysfs nor
> >> /proc/device-tree about the dma-window. And adding a sysfs entry per PE
> >> (powerpc partitionable end-point which is often a PHB but not always) just
> >> for VFIO is quite heavy.
> >
> > How do you learn the window size and PE extents in the host kernel?
> 
> 
> When the ppc64 code does PCI scan, it creates iommu_table structs per PE. 
> When new PE (i.e. new iommu_table) is discovered I call iommu_group_alloc() 
> and iommu_group_set_iommudata() to link iommu_group with iommu_table. These 
> iommu_table structs have DMA window properties.
> 
> 
> >> We could add a ppc64 subfolder under /sys/kernel/iommu/xxx/ and put the
> >> "dma-window" property there. And replace it with a symlink when and if we
> >> add something for PE later. Would work?
> >
> > To be clear, you're suggesting /sys/kernel/iommu_groups/$GROUP/xxx/,
> > right?  A subfolder really only limits the scope of the mess, so it's
> > not much improvement.
> 
> You suggested some symlink to some ppc64 or pci tree in sysfs, it is not 
> that different.
> 
> > What does the interface look like to make those
> > subfolders?
> 
> int iommu_group_create_platform_file(struct iommu_group *group,
>                       struct iommu_group_attribute *attr)
> 
> and that's it.
> 
> > The problem we're trying to solve is this call flow:
> >
> > containerfd = open("/dev/vfio/vfio");
> > ioctl(containerfd, VFIO_GET_API_VERSION);
> > ioctl(containerfd, VFIO_CHECK_EXTENSION, ...);
> > groupfd = open("/dev/vfio/$GROUP");
> > ioctl(groupfd, VFIO_GROUP_GET_STATUS);
> > ioctl(groupfd, VFIO_GROUP_SET_CONTAINER, &containerfd);
> >
> > You wanted to lock all the memory for the DMA window here, before we can
> > call VFIO_IOMMU_GET_INFO, but does it need to happen there?  We still
> > have a MAP_DMA hook.  We could do it all on the first mapping.  It also
> > has a flags field that could augment the behavior to trigger page
> > locking.  Adding the window size to sysfs seems more readily convenient,
> > but is it so hard for userspace to open the files and call a couple
> > ioctls to get far enough to call IOMMU_GET_INFO?  I'm unconvinced the
> > clutter in sysfs more than just a quick fix.  Thanks,
> 
> 
> I thought the problem is that we want to let user set correct rlimit before 
> running QEMU, no? We do not change rlimit from QEMU.

Sure, but nothing stops userspace from doing this same thing.  Userspace
might already want to open the group and call GET_STATUS on it to make
sure it's usable.  If we look at the complexity of parsing an unmanaged
namespace in sysfs vs opening a couple of character devices and a
handful of ioctls to get a table of info about the iommu, what's the
difference?  Sysfs is easier to script but it's also duplicating an
interface that we already have elsewhere.  vfio is the one locking
pages, so it's the one imposing the locked memory requirement, not iommu
groups.  IMHO, sysfs is attractive because it makes scripting easy, but
it's not the right place for it.  Thanks,

Alex

Re: [PATCH] iommu: making IOMMU sysfs nodes API public

[Alex Williamson]

On Tue, 2013-02-19 at 18:38 +1100, David Gibson wrote:
> On Mon, Feb 18, 2013 at 10:24:00PM -0700, Alex Williamson wrote:
> > On Mon, 2013-02-18 at 17:15 +1100, Alexey Kardashevskiy wrote:
> > > On 13/02/13 04:15, Alex Williamson wrote:
> > > > On Wed, 2013-02-13 at 01:42 +1100, Alexey Kardashevskiy wrote:
> > > >> On 12/02/13 16:07, Alex Williamson wrote:
> > > >>> On Tue, 2013-02-12 at 15:06 +1100, Alexey Kardashevskiy wrote:
> > > >>>> Having this patch in a tree, adding new nodes in sysfs
> > > >>>> for IOMMU groups is going to be easier.
> > > >>>>
> > > >>>> The first candidate for this change is a "dma-window-size"
> > > >>>> property which tells a size of a DMA window of the specific
> > > >>>> IOMMU group which can be used later for locked pages accounting.
> > > >>>
> > > >>> I'm still churning on this one; I'm nervous this would basically creat
> > > >>> a /proc free-for-all under /sys/kernel/iommu_group/$GROUP/ where any
> > > >>> iommu driver can add random attributes.  That can get ugly for
> > > >>> userspace.
> > > >>
> > > >> Is not it exactly what sysfs is for (unlike /proc)? :)
> > > >
> > > > Um, I hope it's a little more thought out than /proc.
> > > >
> > > >>> On the other hand, for the application of userspace knowing how much
> > > >>> memory to lock for vfio use of a group, it's an appealing location to
> > > >>> get that information.  Something like libvirt would already be poking
> > > >>> around here to figure out which devices to bind.  Page limits need to be
> > > >>> setup prior to use through vfio, so sysfs is more convenient than
> > > >>> through vfio ioctls.
> > > >>
> > > >> True. DMA window properties do not change since boot so sysfs is the right
> > > >> place to expose them.
> > > >>
> > > >>> But then is dma-window-size just a vfio requirement leaking over into
> > > >>> iommu groups?  Can we allow iommu driver based attributes without giving
> > > >>> up control of the namespace?  Thanks,
> > > >>
> > > >> Who are you asking these questions? :)
> > > >
> > > > Anyone, including you.  Rather than dropping misc files in sysfs to
> > > > describe things about the group, I think the better solution in your
> > > > case might be a link from the group to an existing sysfs directory
> > > > describing the PE.  I believe your PE is rooted in a PCI bridge, so that
> > > > presumably already has a representation in sysfs.  Can the aperture size
> > > > be determined from something in sysfs for that bridge already?  I'm just
> > > > not ready to create a grab bag of sysfs entries for a group yet.
> > > > Thanks,
> > > 
> > > 
> > > At the moment there is no information neither in sysfs nor 
> > > /proc/device-tree about the dma-window. And adding a sysfs entry per PE 
> > > (powerpc partitionable end-point which is often a PHB but not always) just 
> > > for VFIO is quite heavy.
> > 
> > How do you learn the window size and PE extents in the host kernel?
> > 
> > > We could add a ppc64 subfolder under /sys/kernel/iommu/xxx/ and put the 
> > > "dma-window" property there. And replace it with a symlink when and if we 
> > > add something for PE later. Would work?
> 
> Fwiw, I'd suggest a subfolder named for the type of IOMMU, rather than
> "ppc64".
> 
> > To be clear, you're suggesting /sys/kernel/iommu_groups/$GROUP/xxx/,
> > right?  A subfolder really only limits the scope of the mess, so it's
> > not much improvement.  What does the interface look like to make those
> > subfolders?
> > 
> > The problem we're trying to solve is this call flow:
> > 
> > containerfd = open("/dev/vfio/vfio");
> > ioctl(containerfd, VFIO_GET_API_VERSION);
> > ioctl(containerfd, VFIO_CHECK_EXTENSION, ...);
> > groupfd = open("/dev/vfio/$GROUP");
> > ioctl(groupfd, VFIO_GROUP_GET_STATUS);
> > ioctl(groupfd, VFIO_GROUP_SET_CONTAINER, &containerfd);
> > 
> > You wanted to lock all the memory for the DMA window here, before we can
> > call VFIO_IOMMU_GET_INFO, but does it need to happen there?  We still
> > have a MAP_DMA hook.  We could do it all on the first mapping.
> 
> MAP_DMA isn't quite enough, since the guest can also directly cause
> mappings using hypercalls directly implemented in KVM.  I think it
> would be feasible to lock on the first mapping (either via MAP_DMA, or
> H_PUT_TCE) though it would be a bit ugly and require that the first
> H_PUT_TCE always bounce out to virtual mode (Alexey, correct me if I'm
> wrong here).  IIRC there is also a call to bind the vfio container to
> a (qemu assigned) LIOBN, before the guest can use H_PUT_TCE directly,
> so that might be another place we could do the lock.

Somehow hypercall mappings have to be gated by the userspace setup,
right?

> >  It also
> > has a flags field that could augment the behavior to trigger page
> > locking.
> 
> I don't see how the flags help us - we can't have userspace choose to
> skip the locked memory accounting.  Or are you suggesting a flag to
> open the container in some sort of dummy mode where only GET_INFO is
> possible, then re-open with the full locking?

Sort of, I don't think it needs to be re-opened, but we had previously
talked about some kind of enable and disable ioctl.  "enable" would be
the logical place to lock pages, but then we probably got stuck in
questions around what it means to enable an iommu generically.  So what
if instead of a separate enable ioctl we had a flag on DMA_MAP that was
defined as SET_WINDOW where iova and size are passed and specify the
portion of the DMA window that userspace intends to use and which is
therefore locked.  If you don't support subwindows, fine, just fail it.
You could have a matching PUT_WINDOW on DMA_UNMAP if you wanted.

> >  Adding the window size to sysfs seems more readily convenient,
> > but is it so hard for userspace to open the files and call a couple
> > ioctls to get far enough to call IOMMU_GET_INFO?  I'm unconvinced the
> > clutter in sysfs more than just a quick fix.  Thanks,
> 
> And finally, as Alexey points out, isn't the point here so we know how
> much rlimit to give qemu?  Using ioctls we'd need a special tool just
> to check the dma window sizes, which seems a bit hideous.

Is it more hideous that using iommu groups to report a vfio imposed
restriction?  Are a couple open files and a handful of ioctls worse than
code to parse directory entries and the future maintenance of an
unrestricted grab bag of sysfs entries?

Re: [PATCH] iommu: making IOMMU sysfs nodes API public

[Alexey Kardashevskiy]

On 20/02/13 07:11, Alex Williamson wrote:
> On Tue, 2013-02-19 at 18:38 +1100, David Gibson wrote:
>> On Mon, Feb 18, 2013 at 10:24:00PM -0700, Alex Williamson wrote:
>>> On Mon, 2013-02-18 at 17:15 +1100, Alexey Kardashevskiy wrote:
>>>> On 13/02/13 04:15, Alex Williamson wrote:
>>>>> On Wed, 2013-02-13 at 01:42 +1100, Alexey Kardashevskiy wrote:
>>>>>> On 12/02/13 16:07, Alex Williamson wrote:
>>>>>>> On Tue, 2013-02-12 at 15:06 +1100, Alexey Kardashevskiy wrote:
>>>>>>>> Having this patch in a tree, adding new nodes in sysfs
>>>>>>>> for IOMMU groups is going to be easier.
>>>>>>>>
>>>>>>>> The first candidate for this change is a "dma-window-size"
>>>>>>>> property which tells a size of a DMA window of the specific
>>>>>>>> IOMMU group which can be used later for locked pages accounting.
>>>>>>>
>>>>>>> I'm still churning on this one; I'm nervous this would basically creat
>>>>>>> a /proc free-for-all under /sys/kernel/iommu_group/$GROUP/ where any
>>>>>>> iommu driver can add random attributes.  That can get ugly for
>>>>>>> userspace.
>>>>>>
>>>>>> Is not it exactly what sysfs is for (unlike /proc)? :)
>>>>>
>>>>> Um, I hope it's a little more thought out than /proc.
>>>>>
>>>>>>> On the other hand, for the application of userspace knowing how much
>>>>>>> memory to lock for vfio use of a group, it's an appealing location to
>>>>>>> get that information.  Something like libvirt would already be poking
>>>>>>> around here to figure out which devices to bind.  Page limits need to be
>>>>>>> setup prior to use through vfio, so sysfs is more convenient than
>>>>>>> through vfio ioctls.
>>>>>>
>>>>>> True. DMA window properties do not change since boot so sysfs is the right
>>>>>> place to expose them.
>>>>>>
>>>>>>> But then is dma-window-size just a vfio requirement leaking over into
>>>>>>> iommu groups?  Can we allow iommu driver based attributes without giving
>>>>>>> up control of the namespace?  Thanks,
>>>>>>
>>>>>> Who are you asking these questions? :)
>>>>>
>>>>> Anyone, including you.  Rather than dropping misc files in sysfs to
>>>>> describe things about the group, I think the better solution in your
>>>>> case might be a link from the group to an existing sysfs directory
>>>>> describing the PE.  I believe your PE is rooted in a PCI bridge, so that
>>>>> presumably already has a representation in sysfs.  Can the aperture size
>>>>> be determined from something in sysfs for that bridge already?  I'm just
>>>>> not ready to create a grab bag of sysfs entries for a group yet.
>>>>> Thanks,
>>>>
>>>>
>>>> At the moment there is no information neither in sysfs nor
>>>> /proc/device-tree about the dma-window. And adding a sysfs entry per PE
>>>> (powerpc partitionable end-point which is often a PHB but not always) just
>>>> for VFIO is quite heavy.
>>>
>>> How do you learn the window size and PE extents in the host kernel?
>>>
>>>> We could add a ppc64 subfolder under /sys/kernel/iommu/xxx/ and put the
>>>> "dma-window" property there. And replace it with a symlink when and if we
>>>> add something for PE later. Would work?
>>
>> Fwiw, I'd suggest a subfolder named for the type of IOMMU, rather than
>> "ppc64".
>>
>>> To be clear, you're suggesting /sys/kernel/iommu_groups/$GROUP/xxx/,
>>> right?  A subfolder really only limits the scope of the mess, so it's
>>> not much improvement.  What does the interface look like to make those
>>> subfolders?
>>>
>>> The problem we're trying to solve is this call flow:
>>>
>>> containerfd = open("/dev/vfio/vfio");
>>> ioctl(containerfd, VFIO_GET_API_VERSION);
>>> ioctl(containerfd, VFIO_CHECK_EXTENSION, ...);
>>> groupfd = open("/dev/vfio/$GROUP");
>>> ioctl(groupfd, VFIO_GROUP_GET_STATUS);
>>> ioctl(groupfd, VFIO_GROUP_SET_CONTAINER, &containerfd);
>>>
>>> You wanted to lock all the memory for the DMA window here, before we can
>>> call VFIO_IOMMU_GET_INFO, but does it need to happen there?  We still
>>> have a MAP_DMA hook.  We could do it all on the first mapping.
>>
>> MAP_DMA isn't quite enough, since the guest can also directly cause
>> mappings using hypercalls directly implemented in KVM.  I think it
>> would be feasible to lock on the first mapping (either via MAP_DMA, or
>> H_PUT_TCE) though it would be a bit ugly and require that the first
>> H_PUT_TCE always bounce out to virtual mode (Alexey, correct me if I'm
>> wrong here).  IIRC there is also a call to bind the vfio container to
>> a (qemu assigned) LIOBN, before the guest can use H_PUT_TCE directly,
>> so that might be another place we could do the lock.
>
> Somehow hypercall mappings have to be gated by the userspace setup,
> right?


There is a KVM ioctl (and a KVM capability) which hooks LIOBN (PCI bus ID) 
with IOMMU ID. It basically creates an entry in the list of all LIOBNs and 
when TCE call occurs, the host finds correct IOMMU group to pass this call to.

It happens from spapr_register_vfio_container() in QEMU, i.e. after getting 
DMA window properties but only if the host supports real mode TCE handling.


>>>   It also
>>> has a flags field that could augment the behavior to trigger page
>>> locking.
>>
>> I don't see how the flags help us - we can't have userspace choose to
>> skip the locked memory accounting.  Or are you suggesting a flag to
>> open the container in some sort of dummy mode where only GET_INFO is
>> possible, then re-open with the full locking?
>
> Sort of, I don't think it needs to be re-opened, but we had previously
> talked about some kind of enable and disable ioctl.  "enable" would be
> the logical place to lock pages, but then we probably got stuck in
> questions around what it means to enable an iommu generically.

The other question is if a container is ready to work if I add just one 
group? What happens when I add another one (not supported on ppc64 but 
still)? Having "enable" method and disabling new attachments when it is 
"enabled" would keep my brain calm :)

> So what
> if instead of a separate enable ioctl we had a flag on DMA_MAP that was
> defined as SET_WINDOW where iova and size are passed and specify the
> portion of the DMA window that userspace intends to use and which is
> therefore locked.  If you don't support subwindows, fine, just fail it.
> You could have a matching PUT_WINDOW on DMA_UNMAP if you wanted.

DMA_MAP which does not do "map" but does "lock" or "set window"? 
enable()/disable() look better.


>>>   Adding the window size to sysfs seems more readily convenient,
>>> but is it so hard for userspace to open the files and call a couple
>>> ioctls to get far enough to call IOMMU_GET_INFO?  I'm unconvinced the
>>> clutter in sysfs more than just a quick fix.  Thanks,
>>
>> And finally, as Alexey points out, isn't the point here so we know how
>> much rlimit to give qemu?  Using ioctls we'd need a special tool just
>> to check the dma window sizes, which seems a bit hideous.
>
> Is it more hideous that using iommu groups to report a vfio imposed
> restriction?  Are a couple open files and a handful of ioctls worse than
> code to parse directory entries and the future maintenance of an
> unrestricted grab bag of sysfs entries?

At the moment DMA32 window properties are static. So I can easily get rid 
of VFIO_IOMMU_SPAPR_TCE_GET_INFO and be happy.

Ah, anyway, how do you see these ioctls to work on a user machine?
A separate tool which takes an iommu id, returns DMA window size and 
adjusts rlimit?



-- 
Alexey

Re: [PATCH] iommu: making IOMMU sysfs nodes API public

[Alex Williamson]

On Wed, 2013-02-20 at 13:31 +1100, Alexey Kardashevskiy wrote:
> On 20/02/13 07:11, Alex Williamson wrote:
> > On Tue, 2013-02-19 at 18:38 +1100, David Gibson wrote:
> >> On Mon, Feb 18, 2013 at 10:24:00PM -0700, Alex Williamson wrote:
> >>> On Mon, 2013-02-18 at 17:15 +1100, Alexey Kardashevskiy wrote:
> >>>> On 13/02/13 04:15, Alex Williamson wrote:
> >>>>> On Wed, 2013-02-13 at 01:42 +1100, Alexey Kardashevskiy wrote:
> >>>>>> On 12/02/13 16:07, Alex Williamson wrote:
> >>>>>>> On Tue, 2013-02-12 at 15:06 +1100, Alexey Kardashevskiy wrote:
> >>>>>>>> Having this patch in a tree, adding new nodes in sysfs
> >>>>>>>> for IOMMU groups is going to be easier.
> >>>>>>>>
> >>>>>>>> The first candidate for this change is a "dma-window-size"
> >>>>>>>> property which tells a size of a DMA window of the specific
> >>>>>>>> IOMMU group which can be used later for locked pages accounting.
> >>>>>>>
> >>>>>>> I'm still churning on this one; I'm nervous this would basically creat
> >>>>>>> a /proc free-for-all under /sys/kernel/iommu_group/$GROUP/ where any
> >>>>>>> iommu driver can add random attributes.  That can get ugly for
> >>>>>>> userspace.
> >>>>>>
> >>>>>> Is not it exactly what sysfs is for (unlike /proc)? :)
> >>>>>
> >>>>> Um, I hope it's a little more thought out than /proc.
> >>>>>
> >>>>>>> On the other hand, for the application of userspace knowing how much
> >>>>>>> memory to lock for vfio use of a group, it's an appealing location to
> >>>>>>> get that information.  Something like libvirt would already be poking
> >>>>>>> around here to figure out which devices to bind.  Page limits need to be
> >>>>>>> setup prior to use through vfio, so sysfs is more convenient than
> >>>>>>> through vfio ioctls.
> >>>>>>
> >>>>>> True. DMA window properties do not change since boot so sysfs is the right
> >>>>>> place to expose them.
> >>>>>>
> >>>>>>> But then is dma-window-size just a vfio requirement leaking over into
> >>>>>>> iommu groups?  Can we allow iommu driver based attributes without giving
> >>>>>>> up control of the namespace?  Thanks,
> >>>>>>
> >>>>>> Who are you asking these questions? :)
> >>>>>
> >>>>> Anyone, including you.  Rather than dropping misc files in sysfs to
> >>>>> describe things about the group, I think the better solution in your
> >>>>> case might be a link from the group to an existing sysfs directory
> >>>>> describing the PE.  I believe your PE is rooted in a PCI bridge, so that
> >>>>> presumably already has a representation in sysfs.  Can the aperture size
> >>>>> be determined from something in sysfs for that bridge already?  I'm just
> >>>>> not ready to create a grab bag of sysfs entries for a group yet.
> >>>>> Thanks,
> >>>>
> >>>>
> >>>> At the moment there is no information neither in sysfs nor
> >>>> /proc/device-tree about the dma-window. And adding a sysfs entry per PE
> >>>> (powerpc partitionable end-point which is often a PHB but not always) just
> >>>> for VFIO is quite heavy.
> >>>
> >>> How do you learn the window size and PE extents in the host kernel?
> >>>
> >>>> We could add a ppc64 subfolder under /sys/kernel/iommu/xxx/ and put the
> >>>> "dma-window" property there. And replace it with a symlink when and if we
> >>>> add something for PE later. Would work?
> >>
> >> Fwiw, I'd suggest a subfolder named for the type of IOMMU, rather than
> >> "ppc64".
> >>
> >>> To be clear, you're suggesting /sys/kernel/iommu_groups/$GROUP/xxx/,
> >>> right?  A subfolder really only limits the scope of the mess, so it's
> >>> not much improvement.  What does the interface look like to make those
> >>> subfolders?
> >>>
> >>> The problem we're trying to solve is this call flow:
> >>>
> >>> containerfd = open("/dev/vfio/vfio");
> >>> ioctl(containerfd, VFIO_GET_API_VERSION);
> >>> ioctl(containerfd, VFIO_CHECK_EXTENSION, ...);
> >>> groupfd = open("/dev/vfio/$GROUP");
> >>> ioctl(groupfd, VFIO_GROUP_GET_STATUS);
> >>> ioctl(groupfd, VFIO_GROUP_SET_CONTAINER, &containerfd);
> >>>
> >>> You wanted to lock all the memory for the DMA window here, before we can
> >>> call VFIO_IOMMU_GET_INFO, but does it need to happen there?  We still
> >>> have a MAP_DMA hook.  We could do it all on the first mapping.
> >>
> >> MAP_DMA isn't quite enough, since the guest can also directly cause
> >> mappings using hypercalls directly implemented in KVM.  I think it
> >> would be feasible to lock on the first mapping (either via MAP_DMA, or
> >> H_PUT_TCE) though it would be a bit ugly and require that the first
> >> H_PUT_TCE always bounce out to virtual mode (Alexey, correct me if I'm
> >> wrong here).  IIRC there is also a call to bind the vfio container to
> >> a (qemu assigned) LIOBN, before the guest can use H_PUT_TCE directly,
> >> so that might be another place we could do the lock.
> >
> > Somehow hypercall mappings have to be gated by the userspace setup,
> > right?
> 
> 
> There is a KVM ioctl (and a KVM capability) which hooks LIOBN (PCI bus ID) 
> with IOMMU ID. It basically creates an entry in the list of all LIOBNs and 
> when TCE call occurs, the host finds correct IOMMU group to pass this call to.
> 
> It happens from spapr_register_vfio_container() in QEMU, i.e. after getting 
> DMA window properties but only if the host supports real mode TCE handling.
> 
> 
> >>>   It also
> >>> has a flags field that could augment the behavior to trigger page
> >>> locking.
> >>
> >> I don't see how the flags help us - we can't have userspace choose to
> >> skip the locked memory accounting.  Or are you suggesting a flag to
> >> open the container in some sort of dummy mode where only GET_INFO is
> >> possible, then re-open with the full locking?
> >
> > Sort of, I don't think it needs to be re-opened, but we had previously
> > talked about some kind of enable and disable ioctl.  "enable" would be
> > the logical place to lock pages, but then we probably got stuck in
> > questions around what it means to enable an iommu generically.
> 
> The other question is if a container is ready to work if I add just one 
> group? What happens when I add another one (not supported on ppc64 but 
> still)?

This is also the problem with exposing a dma window under the group in
sysfs.  Do I require the ability to lock the sum of the window, the
largest window, what?  If we rely on the ioctls, userspace can figure
out that they can't be combined and know it's the sum.  I'm not sure
what your plans are around hotplug of a PHB though.

> Having "enable" method and disabling new attachments when it is 
> "enabled" would keep my brain calm :)

Now I'm not sure whether you're for or against it ;)

> > So what
> > if instead of a separate enable ioctl we had a flag on DMA_MAP that was
> > defined as SET_WINDOW where iova and size are passed and specify the
> > portion of the DMA window that userspace intends to use and which is
> > therefore locked.  If you don't support subwindows, fine, just fail it.
> > You could have a matching PUT_WINDOW on DMA_UNMAP if you wanted.
> 
> DMA_MAP which does not do "map" but does "lock" or "set window"? 
> enable()/disable() look better.

Sure, this is why we have a modular iommu interface, spapr can create an
enable ioctl if necessary.  I think there are ways to use the
DMA_MAP/UNMAP ioctl in ways that aren't a complete kludge though.

> >>>   Adding the window size to sysfs seems more readily convenient,
> >>> but is it so hard for userspace to open the files and call a couple
> >>> ioctls to get far enough to call IOMMU_GET_INFO?  I'm unconvinced the
> >>> clutter in sysfs more than just a quick fix.  Thanks,
> >>
> >> And finally, as Alexey points out, isn't the point here so we know how
> >> much rlimit to give qemu?  Using ioctls we'd need a special tool just
> >> to check the dma window sizes, which seems a bit hideous.
> >
> > Is it more hideous that using iommu groups to report a vfio imposed
> > restriction?  Are a couple open files and a handful of ioctls worse than
> > code to parse directory entries and the future maintenance of an
> > unrestricted grab bag of sysfs entries?
> 
> At the moment DMA32 window properties are static. So I can easily get rid 
> of VFIO_IOMMU_SPAPR_TCE_GET_INFO and be happy.

Like, for instance, every PE always gets 512MB DMA window, fixed base
address, not configurable, end of story?

> Ah, anyway, how do you see these ioctls to work on a user machine?
> A separate tool which takes an iommu id, returns DMA window size and 
> adjusts rlimit?

Sure, we need something that provides the function of libvirt and
unbinds devices from host drivers, re-binds them to vfio-pci.  That tool
needs to have permissions to manipulate groups, so we're just talking
about whether it's stepping over the line for it to open the group and a
container, associate them, and probe the iommu info vs reading a sysfs
file.  Thanks,

Alex

Re: [PATCH] iommu: making IOMMU sysfs nodes API public

[Alexey Kardashevskiy]

On 20/02/13 14:47, Alex Williamson wrote:
> On Wed, 2013-02-20 at 13:31 +1100, Alexey Kardashevskiy wrote:
>> On 20/02/13 07:11, Alex Williamson wrote:
>>> On Tue, 2013-02-19 at 18:38 +1100, David Gibson wrote:
>>>> On Mon, Feb 18, 2013 at 10:24:00PM -0700, Alex Williamson wrote:
>>>>> On Mon, 2013-02-18 at 17:15 +1100, Alexey Kardashevskiy wrote:
>>>>>> On 13/02/13 04:15, Alex Williamson wrote:
>>>>>>> On Wed, 2013-02-13 at 01:42 +1100, Alexey Kardashevskiy wrote:
>>>>>>>> On 12/02/13 16:07, Alex Williamson wrote:
>>>>>>>>> On Tue, 2013-02-12 at 15:06 +1100, Alexey Kardashevskiy wrote:
>>>>>>>>>> Having this patch in a tree, adding new nodes in sysfs
>>>>>>>>>> for IOMMU groups is going to be easier.
>>>>>>>>>>
>>>>>>>>>> The first candidate for this change is a "dma-window-size"
>>>>>>>>>> property which tells a size of a DMA window of the specific
>>>>>>>>>> IOMMU group which can be used later for locked pages accounting.
>>>>>>>>>
>>>>>>>>> I'm still churning on this one; I'm nervous this would basically creat
>>>>>>>>> a /proc free-for-all under /sys/kernel/iommu_group/$GROUP/ where any
>>>>>>>>> iommu driver can add random attributes.  That can get ugly for
>>>>>>>>> userspace.
>>>>>>>>
>>>>>>>> Is not it exactly what sysfs is for (unlike /proc)? :)
>>>>>>>
>>>>>>> Um, I hope it's a little more thought out than /proc.
>>>>>>>
>>>>>>>>> On the other hand, for the application of userspace knowing how much
>>>>>>>>> memory to lock for vfio use of a group, it's an appealing location to
>>>>>>>>> get that information.  Something like libvirt would already be poking
>>>>>>>>> around here to figure out which devices to bind.  Page limits need to be
>>>>>>>>> setup prior to use through vfio, so sysfs is more convenient than
>>>>>>>>> through vfio ioctls.
>>>>>>>>
>>>>>>>> True. DMA window properties do not change since boot so sysfs is the right
>>>>>>>> place to expose them.
>>>>>>>>
>>>>>>>>> But then is dma-window-size just a vfio requirement leaking over into
>>>>>>>>> iommu groups?  Can we allow iommu driver based attributes without giving
>>>>>>>>> up control of the namespace?  Thanks,
>>>>>>>>
>>>>>>>> Who are you asking these questions? :)
>>>>>>>
>>>>>>> Anyone, including you.  Rather than dropping misc files in sysfs to
>>>>>>> describe things about the group, I think the better solution in your
>>>>>>> case might be a link from the group to an existing sysfs directory
>>>>>>> describing the PE.  I believe your PE is rooted in a PCI bridge, so that
>>>>>>> presumably already has a representation in sysfs.  Can the aperture size
>>>>>>> be determined from something in sysfs for that bridge already?  I'm just
>>>>>>> not ready to create a grab bag of sysfs entries for a group yet.
>>>>>>> Thanks,
>>>>>>
>>>>>>
>>>>>> At the moment there is no information neither in sysfs nor
>>>>>> /proc/device-tree about the dma-window. And adding a sysfs entry per PE
>>>>>> (powerpc partitionable end-point which is often a PHB but not always) just
>>>>>> for VFIO is quite heavy.
>>>>>
>>>>> How do you learn the window size and PE extents in the host kernel?
>>>>>
>>>>>> We could add a ppc64 subfolder under /sys/kernel/iommu/xxx/ and put the
>>>>>> "dma-window" property there. And replace it with a symlink when and if we
>>>>>> add something for PE later. Would work?
>>>>
>>>> Fwiw, I'd suggest a subfolder named for the type of IOMMU, rather than
>>>> "ppc64".
>>>>
>>>>> To be clear, you're suggesting /sys/kernel/iommu_groups/$GROUP/xxx/,
>>>>> right?  A subfolder really only limits the scope of the mess, so it's
>>>>> not much improvement.  What does the interface look like to make those
>>>>> subfolders?
>>>>>
>>>>> The problem we're trying to solve is this call flow:
>>>>>
>>>>> containerfd = open("/dev/vfio/vfio");
>>>>> ioctl(containerfd, VFIO_GET_API_VERSION);
>>>>> ioctl(containerfd, VFIO_CHECK_EXTENSION, ...);
>>>>> groupfd = open("/dev/vfio/$GROUP");
>>>>> ioctl(groupfd, VFIO_GROUP_GET_STATUS);
>>>>> ioctl(groupfd, VFIO_GROUP_SET_CONTAINER, &containerfd);
>>>>>
>>>>> You wanted to lock all the memory for the DMA window here, before we can
>>>>> call VFIO_IOMMU_GET_INFO, but does it need to happen there?  We still
>>>>> have a MAP_DMA hook.  We could do it all on the first mapping.
>>>>
>>>> MAP_DMA isn't quite enough, since the guest can also directly cause
>>>> mappings using hypercalls directly implemented in KVM.  I think it
>>>> would be feasible to lock on the first mapping (either via MAP_DMA, or
>>>> H_PUT_TCE) though it would be a bit ugly and require that the first
>>>> H_PUT_TCE always bounce out to virtual mode (Alexey, correct me if I'm
>>>> wrong here).  IIRC there is also a call to bind the vfio container to
>>>> a (qemu assigned) LIOBN, before the guest can use H_PUT_TCE directly,
>>>> so that might be another place we could do the lock.
>>>
>>> Somehow hypercall mappings have to be gated by the userspace setup,
>>> right?
>>
>>
>> There is a KVM ioctl (and a KVM capability) which hooks LIOBN (PCI bus ID)
>> with IOMMU ID. It basically creates an entry in the list of all LIOBNs and
>> when TCE call occurs, the host finds correct IOMMU group to pass this call to.
>>
>> It happens from spapr_register_vfio_container() in QEMU, i.e. after getting
>> DMA window properties but only if the host supports real mode TCE handling.
>>
>>
>>>>>    It also
>>>>> has a flags field that could augment the behavior to trigger page
>>>>> locking.
>>>>
>>>> I don't see how the flags help us - we can't have userspace choose to
>>>> skip the locked memory accounting.  Or are you suggesting a flag to
>>>> open the container in some sort of dummy mode where only GET_INFO is
>>>> possible, then re-open with the full locking?
>>>
>>> Sort of, I don't think it needs to be re-opened, but we had previously
>>> talked about some kind of enable and disable ioctl.  "enable" would be
>>> the logical place to lock pages, but then we probably got stuck in
>>> questions around what it means to enable an iommu generically.
>>
>> The other question is if a container is ready to work if I add just one
>> group? What happens when I add another one (not supported on ppc64 but
>> still)?
>
> This is also the problem with exposing a dma window under the group in
> sysfs.  Do I require the ability to lock the sum of the window, the
> largest window, what?  If we rely on the ioctls, userspace can figure
> out that they can't be combined and know it's the sum.  I'm not sure
> what your plans are around hotplug of a PHB though.
>
>> Having "enable" method and disabling new attachments when it is
>> "enabled" would keep my brain calm :)
>
> Now I'm not sure whether you're for or against it ;)


I am for introducing enable() ioctls :) Or even "lock" ioctl.


>>> So what
>>> if instead of a separate enable ioctl we had a flag on DMA_MAP that was
>>> defined as SET_WINDOW where iova and size are passed and specify the
>>> portion of the DMA window that userspace intends to use and which is
>>> therefore locked.  If you don't support subwindows, fine, just fail it.
>>> You could have a matching PUT_WINDOW on DMA_UNMAP if you wanted.
>>
>> DMA_MAP which does not do "map" but does "lock" or "set window"?
>> enable()/disable() look better.
>
> Sure, this is why we have a modular iommu interface, spapr can create an
> enable ioctl if necessary.  I think there are ways to use the
> DMA_MAP/UNMAP ioctl in ways that aren't a complete kludge though.
>
>>>>>    Adding the window size to sysfs seems more readily convenient,
>>>>> but is it so hard for userspace to open the files and call a couple
>>>>> ioctls to get far enough to call IOMMU_GET_INFO?  I'm unconvinced the
>>>>> clutter in sysfs more than just a quick fix.  Thanks,
>>>>
>>>> And finally, as Alexey points out, isn't the point here so we know how
>>>> much rlimit to give qemu?  Using ioctls we'd need a special tool just
>>>> to check the dma window sizes, which seems a bit hideous.
>>>
>>> Is it more hideous that using iommu groups to report a vfio imposed
>>> restriction?  Are a couple open files and a handful of ioctls worse than
>>> code to parse directory entries and the future maintenance of an
>>> unrestricted grab bag of sysfs entries?
>>
>> At the moment DMA32 window properties are static. So I can easily get rid
>> of VFIO_IOMMU_SPAPR_TCE_GET_INFO and be happy.
>
> Like, for instance, every PE always gets 512MB DMA window, fixed base
> address, not configurable, end of story?


Almost :) 1GB, starting at 0 (sometime at 2GB). Multiple PCI domains are 
supported on ppc64 so it does not make a problem as bus address spaces are 
separated. But yes, not flexible at all.


>> Ah, anyway, how do you see these ioctls to work on a user machine?
>> A separate tool which takes an iommu id, returns DMA window size and
>> adjusts rlimit?
>
> Sure, we need something that provides the function of libvirt and
> unbinds devices from host drivers, re-binds them to vfio-pci.  That tool
> needs to have permissions to manipulate groups, so we're just talking
> about whether it's stepping over the line for it to open the group and a
> container, associate them, and probe the iommu info vs reading a sysfs
> file.  Thanks,

So the Tool is going to be a part of libvirt but not kernel or qemu, right?
Then implementing "LOCK" (and call it after GET_INFO in QEMU and not call 
it from the Tool) should work fine.



-- 
Alexey

Re: [PATCH] iommu: making IOMMU sysfs nodes API public

[Alex Williamson]

On Wed, 2013-02-20 at 15:20 +1100, Alexey Kardashevskiy wrote:
> On 20/02/13 14:47, Alex Williamson wrote:
> > On Wed, 2013-02-20 at 13:31 +1100, Alexey Kardashevskiy wrote:
> >> On 20/02/13 07:11, Alex Williamson wrote:
> >>> On Tue, 2013-02-19 at 18:38 +1100, David Gibson wrote:
> >>>> On Mon, Feb 18, 2013 at 10:24:00PM -0700, Alex Williamson wrote:
> >>>>> On Mon, 2013-02-18 at 17:15 +1100, Alexey Kardashevskiy wrote:
> >>>>>> On 13/02/13 04:15, Alex Williamson wrote:
> >>>>>>> On Wed, 2013-02-13 at 01:42 +1100, Alexey Kardashevskiy wrote:
> >>>>>>>> On 12/02/13 16:07, Alex Williamson wrote:
> >>>>>>>>> On Tue, 2013-02-12 at 15:06 +1100, Alexey Kardashevskiy wrote:
> >>>>>>>>>> Having this patch in a tree, adding new nodes in sysfs
> >>>>>>>>>> for IOMMU groups is going to be easier.
> >>>>>>>>>>
> >>>>>>>>>> The first candidate for this change is a "dma-window-size"
> >>>>>>>>>> property which tells a size of a DMA window of the specific
> >>>>>>>>>> IOMMU group which can be used later for locked pages accounting.
> >>>>>>>>>
> >>>>>>>>> I'm still churning on this one; I'm nervous this would basically creat
> >>>>>>>>> a /proc free-for-all under /sys/kernel/iommu_group/$GROUP/ where any
> >>>>>>>>> iommu driver can add random attributes.  That can get ugly for
> >>>>>>>>> userspace.
> >>>>>>>>
> >>>>>>>> Is not it exactly what sysfs is for (unlike /proc)? :)
> >>>>>>>
> >>>>>>> Um, I hope it's a little more thought out than /proc.
> >>>>>>>
> >>>>>>>>> On the other hand, for the application of userspace knowing how much
> >>>>>>>>> memory to lock for vfio use of a group, it's an appealing location to
> >>>>>>>>> get that information.  Something like libvirt would already be poking
> >>>>>>>>> around here to figure out which devices to bind.  Page limits need to be
> >>>>>>>>> setup prior to use through vfio, so sysfs is more convenient than
> >>>>>>>>> through vfio ioctls.
> >>>>>>>>
> >>>>>>>> True. DMA window properties do not change since boot so sysfs is the right
> >>>>>>>> place to expose them.
> >>>>>>>>
> >>>>>>>>> But then is dma-window-size just a vfio requirement leaking over into
> >>>>>>>>> iommu groups?  Can we allow iommu driver based attributes without giving
> >>>>>>>>> up control of the namespace?  Thanks,
> >>>>>>>>
> >>>>>>>> Who are you asking these questions? :)
> >>>>>>>
> >>>>>>> Anyone, including you.  Rather than dropping misc files in sysfs to
> >>>>>>> describe things about the group, I think the better solution in your
> >>>>>>> case might be a link from the group to an existing sysfs directory
> >>>>>>> describing the PE.  I believe your PE is rooted in a PCI bridge, so that
> >>>>>>> presumably already has a representation in sysfs.  Can the aperture size
> >>>>>>> be determined from something in sysfs for that bridge already?  I'm just
> >>>>>>> not ready to create a grab bag of sysfs entries for a group yet.
> >>>>>>> Thanks,
> >>>>>>
> >>>>>>
> >>>>>> At the moment there is no information neither in sysfs nor
> >>>>>> /proc/device-tree about the dma-window. And adding a sysfs entry per PE
> >>>>>> (powerpc partitionable end-point which is often a PHB but not always) just
> >>>>>> for VFIO is quite heavy.
> >>>>>
> >>>>> How do you learn the window size and PE extents in the host kernel?
> >>>>>
> >>>>>> We could add a ppc64 subfolder under /sys/kernel/iommu/xxx/ and put the
> >>>>>> "dma-window" property there. And replace it with a symlink when and if we
> >>>>>> add something for PE later. Would work?
> >>>>
> >>>> Fwiw, I'd suggest a subfolder named for the type of IOMMU, rather than
> >>>> "ppc64".
> >>>>
> >>>>> To be clear, you're suggesting /sys/kernel/iommu_groups/$GROUP/xxx/,
> >>>>> right?  A subfolder really only limits the scope of the mess, so it's
> >>>>> not much improvement.  What does the interface look like to make those
> >>>>> subfolders?
> >>>>>
> >>>>> The problem we're trying to solve is this call flow:
> >>>>>
> >>>>> containerfd = open("/dev/vfio/vfio");
> >>>>> ioctl(containerfd, VFIO_GET_API_VERSION);
> >>>>> ioctl(containerfd, VFIO_CHECK_EXTENSION, ...);
> >>>>> groupfd = open("/dev/vfio/$GROUP");
> >>>>> ioctl(groupfd, VFIO_GROUP_GET_STATUS);
> >>>>> ioctl(groupfd, VFIO_GROUP_SET_CONTAINER, &containerfd);
> >>>>>
> >>>>> You wanted to lock all the memory for the DMA window here, before we can
> >>>>> call VFIO_IOMMU_GET_INFO, but does it need to happen there?  We still
> >>>>> have a MAP_DMA hook.  We could do it all on the first mapping.
> >>>>
> >>>> MAP_DMA isn't quite enough, since the guest can also directly cause
> >>>> mappings using hypercalls directly implemented in KVM.  I think it
> >>>> would be feasible to lock on the first mapping (either via MAP_DMA, or
> >>>> H_PUT_TCE) though it would be a bit ugly and require that the first
> >>>> H_PUT_TCE always bounce out to virtual mode (Alexey, correct me if I'm
> >>>> wrong here).  IIRC there is also a call to bind the vfio container to
> >>>> a (qemu assigned) LIOBN, before the guest can use H_PUT_TCE directly,
> >>>> so that might be another place we could do the lock.
> >>>
> >>> Somehow hypercall mappings have to be gated by the userspace setup,
> >>> right?
> >>
> >>
> >> There is a KVM ioctl (and a KVM capability) which hooks LIOBN (PCI bus ID)
> >> with IOMMU ID. It basically creates an entry in the list of all LIOBNs and
> >> when TCE call occurs, the host finds correct IOMMU group to pass this call to.
> >>
> >> It happens from spapr_register_vfio_container() in QEMU, i.e. after getting
> >> DMA window properties but only if the host supports real mode TCE handling.
> >>
> >>
> >>>>>    It also
> >>>>> has a flags field that could augment the behavior to trigger page
> >>>>> locking.
> >>>>
> >>>> I don't see how the flags help us - we can't have userspace choose to
> >>>> skip the locked memory accounting.  Or are you suggesting a flag to
> >>>> open the container in some sort of dummy mode where only GET_INFO is
> >>>> possible, then re-open with the full locking?
> >>>
> >>> Sort of, I don't think it needs to be re-opened, but we had previously
> >>> talked about some kind of enable and disable ioctl.  "enable" would be
> >>> the logical place to lock pages, but then we probably got stuck in
> >>> questions around what it means to enable an iommu generically.
> >>
> >> The other question is if a container is ready to work if I add just one
> >> group? What happens when I add another one (not supported on ppc64 but
> >> still)?
> >
> > This is also the problem with exposing a dma window under the group in
> > sysfs.  Do I require the ability to lock the sum of the window, the
> > largest window, what?  If we rely on the ioctls, userspace can figure
> > out that they can't be combined and know it's the sum.  I'm not sure
> > what your plans are around hotplug of a PHB though.
> >
> >> Having "enable" method and disabling new attachments when it is
> >> "enabled" would keep my brain calm :)
> >
> > Now I'm not sure whether you're for or against it ;)
> 
> 
> I am for introducing enable() ioctls :) Or even "lock" ioctl.
> 
> 
> >>> So what
> >>> if instead of a separate enable ioctl we had a flag on DMA_MAP that was
> >>> defined as SET_WINDOW where iova and size are passed and specify the
> >>> portion of the DMA window that userspace intends to use and which is
> >>> therefore locked.  If you don't support subwindows, fine, just fail it.
> >>> You could have a matching PUT_WINDOW on DMA_UNMAP if you wanted.
> >>
> >> DMA_MAP which does not do "map" but does "lock" or "set window"?
> >> enable()/disable() look better.
> >
> > Sure, this is why we have a modular iommu interface, spapr can create an
> > enable ioctl if necessary.  I think there are ways to use the
> > DMA_MAP/UNMAP ioctl in ways that aren't a complete kludge though.
> >
> >>>>>    Adding the window size to sysfs seems more readily convenient,
> >>>>> but is it so hard for userspace to open the files and call a couple
> >>>>> ioctls to get far enough to call IOMMU_GET_INFO?  I'm unconvinced the
> >>>>> clutter in sysfs more than just a quick fix.  Thanks,
> >>>>
> >>>> And finally, as Alexey points out, isn't the point here so we know how
> >>>> much rlimit to give qemu?  Using ioctls we'd need a special tool just
> >>>> to check the dma window sizes, which seems a bit hideous.
> >>>
> >>> Is it more hideous that using iommu groups to report a vfio imposed
> >>> restriction?  Are a couple open files and a handful of ioctls worse than
> >>> code to parse directory entries and the future maintenance of an
> >>> unrestricted grab bag of sysfs entries?
> >>
> >> At the moment DMA32 window properties are static. So I can easily get rid
> >> of VFIO_IOMMU_SPAPR_TCE_GET_INFO and be happy.
> >
> > Like, for instance, every PE always gets 512MB DMA window, fixed base
> > address, not configurable, end of story?
> 
> 
> Almost :) 1GB, starting at 0 (sometime at 2GB). Multiple PCI domains are 
> supported on ppc64 so it does not make a problem as bus address spaces are 
> separated. But yes, not flexible at all.

Statements like "at the moment...", "[but] sometimes at..." make me
think it's best to keep the GET_INFO call.

> >> Ah, anyway, how do you see these ioctls to work on a user machine?
> >> A separate tool which takes an iommu id, returns DMA window size and
> >> adjusts rlimit?
> >
> > Sure, we need something that provides the function of libvirt and
> > unbinds devices from host drivers, re-binds them to vfio-pci.  That tool
> > needs to have permissions to manipulate groups, so we're just talking
> > about whether it's stepping over the line for it to open the group and a
> > container, associate them, and probe the iommu info vs reading a sysfs
> > file.  Thanks,
> 
> So the Tool is going to be a part of libvirt but not kernel or qemu, right?
> Then implementing "LOCK" (and call it after GET_INFO in QEMU and not call 
> it from the Tool) should work fine.

Right, a probe tool would check the value, close the files and set the
locked page limit for qemu, which would take the next step to trigger
the in-kernel accounting.  Thanks,

Alex

Re: [PATCH] iommu: making IOMMU sysfs nodes API public

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 1367 bytes --]

On Tue, Feb 19, 2013 at 01:11:51PM -0700, Alex Williamson wrote:
> On Tue, 2013-02-19 at 18:38 +1100, David Gibson wrote:
> > On Mon, Feb 18, 2013 at 10:24:00PM -0700, Alex Williamson wrote:
> > > On Mon, 2013-02-18 at 17:15 +1100, Alexey Kardashevskiy wrote:
[snip]
> > >  Adding the window size to sysfs seems more readily convenient,
> > > but is it so hard for userspace to open the files and call a couple
> > > ioctls to get far enough to call IOMMU_GET_INFO?  I'm unconvinced the
> > > clutter in sysfs more than just a quick fix.  Thanks,
> > 
> > And finally, as Alexey points out, isn't the point here so we know how
> > much rlimit to give qemu?  Using ioctls we'd need a special tool just
> > to check the dma window sizes, which seems a bit hideous.
> 
> Is it more hideous that using iommu groups to report a vfio imposed
> restriction?  Are a couple open files and a handful of ioctls worse than
> code to parse directory entries and the future maintenance of an
> unrestricted grab bag of sysfs entries?

The fact that the memory is locked is a vfio restriction, but the
actual dma window size is, genuinely, a property of the group.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH] iommu: making IOMMU sysfs nodes API public

[Alex Williamson]

On Fri, 2013-02-22 at 11:04 +1100, David Gibson wrote:
> On Tue, Feb 19, 2013 at 01:11:51PM -0700, Alex Williamson wrote:
> > On Tue, 2013-02-19 at 18:38 +1100, David Gibson wrote:
> > > On Mon, Feb 18, 2013 at 10:24:00PM -0700, Alex Williamson wrote:
> > > > On Mon, 2013-02-18 at 17:15 +1100, Alexey Kardashevskiy wrote:
> [snip]
> > > >  Adding the window size to sysfs seems more readily convenient,
> > > > but is it so hard for userspace to open the files and call a couple
> > > > ioctls to get far enough to call IOMMU_GET_INFO?  I'm unconvinced the
> > > > clutter in sysfs more than just a quick fix.  Thanks,
> > > 
> > > And finally, as Alexey points out, isn't the point here so we know how
> > > much rlimit to give qemu?  Using ioctls we'd need a special tool just
> > > to check the dma window sizes, which seems a bit hideous.
> > 
> > Is it more hideous that using iommu groups to report a vfio imposed
> > restriction?  Are a couple open files and a handful of ioctls worse than
> > code to parse directory entries and the future maintenance of an
> > unrestricted grab bag of sysfs entries?
> 
> The fact that the memory is locked is a vfio restriction, but the
> actual dma window size is, genuinely, a property of the group.

A group is an association of devices based on isolation and visibility.
The dma window happens to be associated with a group on your platform,
but that's not always the case.  This is why I was hoping something in
sysfs already reported the dma window so that we could point to it
rather than creating an interface where it doesn't really belong.
Thanks,

Alex

Re: [PATCH] iommu: making IOMMU sysfs nodes API public

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 2103 bytes --]

On Thu, Feb 21, 2013 at 09:11:13PM -0700, Alex Williamson wrote:
> On Fri, 2013-02-22 at 11:04 +1100, David Gibson wrote:
> > On Tue, Feb 19, 2013 at 01:11:51PM -0700, Alex Williamson wrote:
> > > On Tue, 2013-02-19 at 18:38 +1100, David Gibson wrote:
> > > > On Mon, Feb 18, 2013 at 10:24:00PM -0700, Alex Williamson wrote:
> > > > > On Mon, 2013-02-18 at 17:15 +1100, Alexey Kardashevskiy wrote:
> > [snip]
> > > > >  Adding the window size to sysfs seems more readily convenient,
> > > > > but is it so hard for userspace to open the files and call a couple
> > > > > ioctls to get far enough to call IOMMU_GET_INFO?  I'm unconvinced the
> > > > > clutter in sysfs more than just a quick fix.  Thanks,
> > > > 
> > > > And finally, as Alexey points out, isn't the point here so we know how
> > > > much rlimit to give qemu?  Using ioctls we'd need a special tool just
> > > > to check the dma window sizes, which seems a bit hideous.
> > > 
> > > Is it more hideous that using iommu groups to report a vfio imposed
> > > restriction?  Are a couple open files and a handful of ioctls worse than
> > > code to parse directory entries and the future maintenance of an
> > > unrestricted grab bag of sysfs entries?
> > 
> > The fact that the memory is locked is a vfio restriction, but the
> > actual dma window size is, genuinely, a property of the group.
> 
> A group is an association of devices based on isolation and visibility.
> The dma window happens to be associated with a group on your platform,
> but that's not always the case.

It's certainly an iommu driver specific group property, but a group
property nonetheless.

>  This is why I was hoping something in
> sysfs already reported the dma window so that we could point to it
> rather than creating an interface where it doesn't really belong.

Alas, no.  There's been no reason to expose PEs previously.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH 1/2] vfio powerpc: enabled on powernv platform

[Paul Mackerras]

On Mon, Feb 11, 2013 at 03:16:43PM -0700, Alex Williamson wrote:
> 
> Why do these all return long (vs int)?  Is this a POWER-ism?

On ppc64 the compiler tends to generate slightly shorter code with
longs than with ints.  The reason is that with ints the compiler has
to put in "extend sign word" instructions to convert 64-bit values
from arithmetic instructions to values in the 32-bit range.

Paul.

Re: [PATCH] iommu: making IOMMU sysfs nodes API public

[Alexey Kardashevskiy]

On 20/02/13 15:33, Alex Williamson wrote:
> On Wed, 2013-02-20 at 15:20 +1100, Alexey Kardashevskiy wrote:
>> On 20/02/13 14:47, Alex Williamson wrote:
>>> On Wed, 2013-02-20 at 13:31 +1100, Alexey Kardashevskiy wrote:
>>>> On 20/02/13 07:11, Alex Williamson wrote:
>>>>> On Tue, 2013-02-19 at 18:38 +1100, David Gibson wrote:
>>>>>> On Mon, Feb 18, 2013 at 10:24:00PM -0700, Alex Williamson wrote:
>>>>>>> On Mon, 2013-02-18 at 17:15 +1100, Alexey Kardashevskiy wrote:
>>>>>>>> On 13/02/13 04:15, Alex Williamson wrote:
>>>>>>>>> On Wed, 2013-02-13 at 01:42 +1100, Alexey Kardashevskiy wrote:
>>>>>>>>>> On 12/02/13 16:07, Alex Williamson wrote:
>>>>>>>>>>> On Tue, 2013-02-12 at 15:06 +1100, Alexey Kardashevskiy wrote:
>>>>>>>>>>>> Having this patch in a tree, adding new nodes in sysfs
>>>>>>>>>>>> for IOMMU groups is going to be easier.
>>>>>>>>>>>>
>>>>>>>>>>>> The first candidate for this change is a "dma-window-size"
>>>>>>>>>>>> property which tells a size of a DMA window of the specific
>>>>>>>>>>>> IOMMU group which can be used later for locked pages accounting.
>>>>>>>>>>>
>>>>>>>>>>> I'm still churning on this one; I'm nervous this would basically creat
>>>>>>>>>>> a /proc free-for-all under /sys/kernel/iommu_group/$GROUP/ where any
>>>>>>>>>>> iommu driver can add random attributes.  That can get ugly for
>>>>>>>>>>> userspace.
>>>>>>>>>>
>>>>>>>>>> Is not it exactly what sysfs is for (unlike /proc)? :)
>>>>>>>>>
>>>>>>>>> Um, I hope it's a little more thought out than /proc.
>>>>>>>>>
>>>>>>>>>>> On the other hand, for the application of userspace knowing how much
>>>>>>>>>>> memory to lock for vfio use of a group, it's an appealing location to
>>>>>>>>>>> get that information.  Something like libvirt would already be poking
>>>>>>>>>>> around here to figure out which devices to bind.  Page limits need to be
>>>>>>>>>>> setup prior to use through vfio, so sysfs is more convenient than
>>>>>>>>>>> through vfio ioctls.
>>>>>>>>>>
>>>>>>>>>> True. DMA window properties do not change since boot so sysfs is the right
>>>>>>>>>> place to expose them.
>>>>>>>>>>
>>>>>>>>>>> But then is dma-window-size just a vfio requirement leaking over into
>>>>>>>>>>> iommu groups?  Can we allow iommu driver based attributes without giving
>>>>>>>>>>> up control of the namespace?  Thanks,
>>>>>>>>>>
>>>>>>>>>> Who are you asking these questions? :)
>>>>>>>>>
>>>>>>>>> Anyone, including you.  Rather than dropping misc files in sysfs to
>>>>>>>>> describe things about the group, I think the better solution in your
>>>>>>>>> case might be a link from the group to an existing sysfs directory
>>>>>>>>> describing the PE.  I believe your PE is rooted in a PCI bridge, so that
>>>>>>>>> presumably already has a representation in sysfs.  Can the aperture size
>>>>>>>>> be determined from something in sysfs for that bridge already?  I'm just
>>>>>>>>> not ready to create a grab bag of sysfs entries for a group yet.
>>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>>
>>>>>>>> At the moment there is no information neither in sysfs nor
>>>>>>>> /proc/device-tree about the dma-window. And adding a sysfs entry per PE
>>>>>>>> (powerpc partitionable end-point which is often a PHB but not always) just
>>>>>>>> for VFIO is quite heavy.
>>>>>>>
>>>>>>> How do you learn the window size and PE extents in the host kernel?
>>>>>>>
>>>>>>>> We could add a ppc64 subfolder under /sys/kernel/iommu/xxx/ and put the
>>>>>>>> "dma-window" property there. And replace it with a symlink when and if we
>>>>>>>> add something for PE later. Would work?
>>>>>>
>>>>>> Fwiw, I'd suggest a subfolder named for the type of IOMMU, rather than
>>>>>> "ppc64".
>>>>>>
>>>>>>> To be clear, you're suggesting /sys/kernel/iommu_groups/$GROUP/xxx/,
>>>>>>> right?  A subfolder really only limits the scope of the mess, so it's
>>>>>>> not much improvement.  What does the interface look like to make those
>>>>>>> subfolders?
>>>>>>>
>>>>>>> The problem we're trying to solve is this call flow:
>>>>>>>
>>>>>>> containerfd = open("/dev/vfio/vfio");
>>>>>>> ioctl(containerfd, VFIO_GET_API_VERSION);
>>>>>>> ioctl(containerfd, VFIO_CHECK_EXTENSION, ...);
>>>>>>> groupfd = open("/dev/vfio/$GROUP");
>>>>>>> ioctl(groupfd, VFIO_GROUP_GET_STATUS);
>>>>>>> ioctl(groupfd, VFIO_GROUP_SET_CONTAINER, &containerfd);
>>>>>>>
>>>>>>> You wanted to lock all the memory for the DMA window here, before we can
>>>>>>> call VFIO_IOMMU_GET_INFO, but does it need to happen there?  We still
>>>>>>> have a MAP_DMA hook.  We could do it all on the first mapping.
>>>>>>
>>>>>> MAP_DMA isn't quite enough, since the guest can also directly cause
>>>>>> mappings using hypercalls directly implemented in KVM.  I think it
>>>>>> would be feasible to lock on the first mapping (either via MAP_DMA, or
>>>>>> H_PUT_TCE) though it would be a bit ugly and require that the first
>>>>>> H_PUT_TCE always bounce out to virtual mode (Alexey, correct me if I'm
>>>>>> wrong here).  IIRC there is also a call to bind the vfio container to
>>>>>> a (qemu assigned) LIOBN, before the guest can use H_PUT_TCE directly,
>>>>>> so that might be another place we could do the lock.
>>>>>
>>>>> Somehow hypercall mappings have to be gated by the userspace setup,
>>>>> right?
>>>>
>>>>
>>>> There is a KVM ioctl (and a KVM capability) which hooks LIOBN (PCI bus ID)
>>>> with IOMMU ID. It basically creates an entry in the list of all LIOBNs and
>>>> when TCE call occurs, the host finds correct IOMMU group to pass this call to.
>>>>
>>>> It happens from spapr_register_vfio_container() in QEMU, i.e. after getting
>>>> DMA window properties but only if the host supports real mode TCE handling.
>>>>
>>>>
>>>>>>>     It also
>>>>>>> has a flags field that could augment the behavior to trigger page
>>>>>>> locking.
>>>>>>
>>>>>> I don't see how the flags help us - we can't have userspace choose to
>>>>>> skip the locked memory accounting.  Or are you suggesting a flag to
>>>>>> open the container in some sort of dummy mode where only GET_INFO is
>>>>>> possible, then re-open with the full locking?
>>>>>
>>>>> Sort of, I don't think it needs to be re-opened, but we had previously
>>>>> talked about some kind of enable and disable ioctl.  "enable" would be
>>>>> the logical place to lock pages, but then we probably got stuck in
>>>>> questions around what it means to enable an iommu generically.
>>>>
>>>> The other question is if a container is ready to work if I add just one
>>>> group? What happens when I add another one (not supported on ppc64 but
>>>> still)?
>>>
>>> This is also the problem with exposing a dma window under the group in
>>> sysfs.  Do I require the ability to lock the sum of the window, the
>>> largest window, what?  If we rely on the ioctls, userspace can figure
>>> out that they can't be combined and know it's the sum.  I'm not sure
>>> what your plans are around hotplug of a PHB though.
>>>
>>>> Having "enable" method and disabling new attachments when it is
>>>> "enabled" would keep my brain calm :)
>>>
>>> Now I'm not sure whether you're for or against it ;)
>>
>>
>> I am for introducing enable() ioctls :) Or even "lock" ioctl.
>>
>>
>>>>> So what
>>>>> if instead of a separate enable ioctl we had a flag on DMA_MAP that was
>>>>> defined as SET_WINDOW where iova and size are passed and specify the
>>>>> portion of the DMA window that userspace intends to use and which is
>>>>> therefore locked.  If you don't support subwindows, fine, just fail it.
>>>>> You could have a matching PUT_WINDOW on DMA_UNMAP if you wanted.
>>>>
>>>> DMA_MAP which does not do "map" but does "lock" or "set window"?
>>>> enable()/disable() look better.
>>>
>>> Sure, this is why we have a modular iommu interface, spapr can create an
>>> enable ioctl if necessary.  I think there are ways to use the
>>> DMA_MAP/UNMAP ioctl in ways that aren't a complete kludge though.
>>>
>>>>>>>     Adding the window size to sysfs seems more readily convenient,
>>>>>>> but is it so hard for userspace to open the files and call a couple
>>>>>>> ioctls to get far enough to call IOMMU_GET_INFO?  I'm unconvinced the
>>>>>>> clutter in sysfs more than just a quick fix.  Thanks,
>>>>>>
>>>>>> And finally, as Alexey points out, isn't the point here so we know how
>>>>>> much rlimit to give qemu?  Using ioctls we'd need a special tool just
>>>>>> to check the dma window sizes, which seems a bit hideous.
>>>>>
>>>>> Is it more hideous that using iommu groups to report a vfio imposed
>>>>> restriction?  Are a couple open files and a handful of ioctls worse than
>>>>> code to parse directory entries and the future maintenance of an
>>>>> unrestricted grab bag of sysfs entries?
>>>>
>>>> At the moment DMA32 window properties are static. So I can easily get rid
>>>> of VFIO_IOMMU_SPAPR_TCE_GET_INFO and be happy.
>>>
>>> Like, for instance, every PE always gets 512MB DMA window, fixed base
>>> address, not configurable, end of story?
>>
>>
>> Almost :) 1GB, starting at 0 (sometime at 2GB). Multiple PCI domains are
>> supported on ppc64 so it does not make a problem as bus address spaces are
>> separated. But yes, not flexible at all.
>
> Statements like "at the moment...", "[but] sometimes at..." make me
> think it's best to keep the GET_INFO call.
>
>>>> Ah, anyway, how do you see these ioctls to work on a user machine?
>>>> A separate tool which takes an iommu id, returns DMA window size and
>>>> adjusts rlimit?
>>>
>>> Sure, we need something that provides the function of libvirt and
>>> unbinds devices from host drivers, re-binds them to vfio-pci.  That tool
>>> needs to have permissions to manipulate groups, so we're just talking
>>> about whether it's stepping over the line for it to open the group and a
>>> container, associate them, and probe the iommu info vs reading a sysfs
>>> file.  Thanks,
>>
>> So the Tool is going to be a part of libvirt but not kernel or qemu, right?
>> Then implementing "LOCK" (and call it after GET_INFO in QEMU and not call
>> it from the Tool) should work fine.
>
> Right, a probe tool would check the value, close the files and set the
> locked page limit for qemu, which would take the next step to trigger
> the in-kernel accounting.  Thanks,

Continuing the discussion :)
In meanwhile I added/tested VFIO_IOMMU_ENABLE and VFIO_IOMMU_DISABLE like 
that (will repost the patch later, may be this week, only few changes there):


+       case VFIO_IOMMU_ENABLE: {
+               mutex_lock(&container->lock);
+               ret = tce_iommu_enable(container);
+               mutex_unlock(&container->lock);
+
+               return ret;
+       }
+       case VFIO_IOMMU_DISABLE: {
+               mutex_lock(&container->lock);
+               tce_iommu_disable(container);
+               mutex_unlock(&container->lock);
+
+               return 0;
+       }

and defined them as (not arch specific):

+/* IOCTLs to enable/disable IOMMU container usage */
+#define VFIO_IOMMU_ENABLE      _IO(VFIO_TYPE, VFIO_BASE + 15)
+#define VFIO_IOMMU_DISABLE     _IO(VFIO_TYPE, VFIO_BASE + 16)


should be ok, right?


There is another question. It is possible to compile
vfio_iommu_spapr_tce as a module. How/when is it supposed to be loaded?
A user may not want to do "modprobe vfio_iommu_spapr_tce" manually.


-- 
Alexey

Re: [PATCH] iommu: making IOMMU sysfs nodes API public

[Alex Williamson]

On Mon, 2013-03-18 at 14:53 +1100, Alexey Kardashevskiy wrote:
> On 20/02/13 15:33, Alex Williamson wrote:
> > On Wed, 2013-02-20 at 15:20 +1100, Alexey Kardashevskiy wrote:
> >> On 20/02/13 14:47, Alex Williamson wrote:
> >>> On Wed, 2013-02-20 at 13:31 +1100, Alexey Kardashevskiy wrote:
> >>>> On 20/02/13 07:11, Alex Williamson wrote:
> >>>>> On Tue, 2013-02-19 at 18:38 +1100, David Gibson wrote:
> >>>>>> On Mon, Feb 18, 2013 at 10:24:00PM -0700, Alex Williamson wrote:
> >>>>>>> On Mon, 2013-02-18 at 17:15 +1100, Alexey Kardashevskiy wrote:
> >>>>>>>> On 13/02/13 04:15, Alex Williamson wrote:
> >>>>>>>>> On Wed, 2013-02-13 at 01:42 +1100, Alexey Kardashevskiy wrote:
> >>>>>>>>>> On 12/02/13 16:07, Alex Williamson wrote:
> >>>>>>>>>>> On Tue, 2013-02-12 at 15:06 +1100, Alexey Kardashevskiy wrote:
> >>>>>>>>>>>> Having this patch in a tree, adding new nodes in sysfs
> >>>>>>>>>>>> for IOMMU groups is going to be easier.
> >>>>>>>>>>>>
> >>>>>>>>>>>> The first candidate for this change is a "dma-window-size"
> >>>>>>>>>>>> property which tells a size of a DMA window of the specific
> >>>>>>>>>>>> IOMMU group which can be used later for locked pages accounting.
> >>>>>>>>>>>
> >>>>>>>>>>> I'm still churning on this one; I'm nervous this would basically creat
> >>>>>>>>>>> a /proc free-for-all under /sys/kernel/iommu_group/$GROUP/ where any
> >>>>>>>>>>> iommu driver can add random attributes.  That can get ugly for
> >>>>>>>>>>> userspace.
> >>>>>>>>>>
> >>>>>>>>>> Is not it exactly what sysfs is for (unlike /proc)? :)
> >>>>>>>>>
> >>>>>>>>> Um, I hope it's a little more thought out than /proc.
> >>>>>>>>>
> >>>>>>>>>>> On the other hand, for the application of userspace knowing how much
> >>>>>>>>>>> memory to lock for vfio use of a group, it's an appealing location to
> >>>>>>>>>>> get that information.  Something like libvirt would already be poking
> >>>>>>>>>>> around here to figure out which devices to bind.  Page limits need to be
> >>>>>>>>>>> setup prior to use through vfio, so sysfs is more convenient than
> >>>>>>>>>>> through vfio ioctls.
> >>>>>>>>>>
> >>>>>>>>>> True. DMA window properties do not change since boot so sysfs is the right
> >>>>>>>>>> place to expose them.
> >>>>>>>>>>
> >>>>>>>>>>> But then is dma-window-size just a vfio requirement leaking over into
> >>>>>>>>>>> iommu groups?  Can we allow iommu driver based attributes without giving
> >>>>>>>>>>> up control of the namespace?  Thanks,
> >>>>>>>>>>
> >>>>>>>>>> Who are you asking these questions? :)
> >>>>>>>>>
> >>>>>>>>> Anyone, including you.  Rather than dropping misc files in sysfs to
> >>>>>>>>> describe things about the group, I think the better solution in your
> >>>>>>>>> case might be a link from the group to an existing sysfs directory
> >>>>>>>>> describing the PE.  I believe your PE is rooted in a PCI bridge, so that
> >>>>>>>>> presumably already has a representation in sysfs.  Can the aperture size
> >>>>>>>>> be determined from something in sysfs for that bridge already?  I'm just
> >>>>>>>>> not ready to create a grab bag of sysfs entries for a group yet.
> >>>>>>>>> Thanks,
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> At the moment there is no information neither in sysfs nor
> >>>>>>>> /proc/device-tree about the dma-window. And adding a sysfs entry per PE
> >>>>>>>> (powerpc partitionable end-point which is often a PHB but not always) just
> >>>>>>>> for VFIO is quite heavy.
> >>>>>>>
> >>>>>>> How do you learn the window size and PE extents in the host kernel?
> >>>>>>>
> >>>>>>>> We could add a ppc64 subfolder under /sys/kernel/iommu/xxx/ and put the
> >>>>>>>> "dma-window" property there. And replace it with a symlink when and if we
> >>>>>>>> add something for PE later. Would work?
> >>>>>>
> >>>>>> Fwiw, I'd suggest a subfolder named for the type of IOMMU, rather than
> >>>>>> "ppc64".
> >>>>>>
> >>>>>>> To be clear, you're suggesting /sys/kernel/iommu_groups/$GROUP/xxx/,
> >>>>>>> right?  A subfolder really only limits the scope of the mess, so it's
> >>>>>>> not much improvement.  What does the interface look like to make those
> >>>>>>> subfolders?
> >>>>>>>
> >>>>>>> The problem we're trying to solve is this call flow:
> >>>>>>>
> >>>>>>> containerfd = open("/dev/vfio/vfio");
> >>>>>>> ioctl(containerfd, VFIO_GET_API_VERSION);
> >>>>>>> ioctl(containerfd, VFIO_CHECK_EXTENSION, ...);
> >>>>>>> groupfd = open("/dev/vfio/$GROUP");
> >>>>>>> ioctl(groupfd, VFIO_GROUP_GET_STATUS);
> >>>>>>> ioctl(groupfd, VFIO_GROUP_SET_CONTAINER, &containerfd);
> >>>>>>>
> >>>>>>> You wanted to lock all the memory for the DMA window here, before we can
> >>>>>>> call VFIO_IOMMU_GET_INFO, but does it need to happen there?  We still
> >>>>>>> have a MAP_DMA hook.  We could do it all on the first mapping.
> >>>>>>
> >>>>>> MAP_DMA isn't quite enough, since the guest can also directly cause
> >>>>>> mappings using hypercalls directly implemented in KVM.  I think it
> >>>>>> would be feasible to lock on the first mapping (either via MAP_DMA, or
> >>>>>> H_PUT_TCE) though it would be a bit ugly and require that the first
> >>>>>> H_PUT_TCE always bounce out to virtual mode (Alexey, correct me if I'm
> >>>>>> wrong here).  IIRC there is also a call to bind the vfio container to
> >>>>>> a (qemu assigned) LIOBN, before the guest can use H_PUT_TCE directly,
> >>>>>> so that might be another place we could do the lock.
> >>>>>
> >>>>> Somehow hypercall mappings have to be gated by the userspace setup,
> >>>>> right?
> >>>>
> >>>>
> >>>> There is a KVM ioctl (and a KVM capability) which hooks LIOBN (PCI bus ID)
> >>>> with IOMMU ID. It basically creates an entry in the list of all LIOBNs and
> >>>> when TCE call occurs, the host finds correct IOMMU group to pass this call to.
> >>>>
> >>>> It happens from spapr_register_vfio_container() in QEMU, i.e. after getting
> >>>> DMA window properties but only if the host supports real mode TCE handling.
> >>>>
> >>>>
> >>>>>>>     It also
> >>>>>>> has a flags field that could augment the behavior to trigger page
> >>>>>>> locking.
> >>>>>>
> >>>>>> I don't see how the flags help us - we can't have userspace choose to
> >>>>>> skip the locked memory accounting.  Or are you suggesting a flag to
> >>>>>> open the container in some sort of dummy mode where only GET_INFO is
> >>>>>> possible, then re-open with the full locking?
> >>>>>
> >>>>> Sort of, I don't think it needs to be re-opened, but we had previously
> >>>>> talked about some kind of enable and disable ioctl.  "enable" would be
> >>>>> the logical place to lock pages, but then we probably got stuck in
> >>>>> questions around what it means to enable an iommu generically.
> >>>>
> >>>> The other question is if a container is ready to work if I add just one
> >>>> group? What happens when I add another one (not supported on ppc64 but
> >>>> still)?
> >>>
> >>> This is also the problem with exposing a dma window under the group in
> >>> sysfs.  Do I require the ability to lock the sum of the window, the
> >>> largest window, what?  If we rely on the ioctls, userspace can figure
> >>> out that they can't be combined and know it's the sum.  I'm not sure
> >>> what your plans are around hotplug of a PHB though.
> >>>
> >>>> Having "enable" method and disabling new attachments when it is
> >>>> "enabled" would keep my brain calm :)
> >>>
> >>> Now I'm not sure whether you're for or against it ;)
> >>
> >>
> >> I am for introducing enable() ioctls :) Or even "lock" ioctl.
> >>
> >>
> >>>>> So what
> >>>>> if instead of a separate enable ioctl we had a flag on DMA_MAP that was
> >>>>> defined as SET_WINDOW where iova and size are passed and specify the
> >>>>> portion of the DMA window that userspace intends to use and which is
> >>>>> therefore locked.  If you don't support subwindows, fine, just fail it.
> >>>>> You could have a matching PUT_WINDOW on DMA_UNMAP if you wanted.
> >>>>
> >>>> DMA_MAP which does not do "map" but does "lock" or "set window"?
> >>>> enable()/disable() look better.
> >>>
> >>> Sure, this is why we have a modular iommu interface, spapr can create an
> >>> enable ioctl if necessary.  I think there are ways to use the
> >>> DMA_MAP/UNMAP ioctl in ways that aren't a complete kludge though.
> >>>
> >>>>>>>     Adding the window size to sysfs seems more readily convenient,
> >>>>>>> but is it so hard for userspace to open the files and call a couple
> >>>>>>> ioctls to get far enough to call IOMMU_GET_INFO?  I'm unconvinced the
> >>>>>>> clutter in sysfs more than just a quick fix.  Thanks,
> >>>>>>
> >>>>>> And finally, as Alexey points out, isn't the point here so we know how
> >>>>>> much rlimit to give qemu?  Using ioctls we'd need a special tool just
> >>>>>> to check the dma window sizes, which seems a bit hideous.
> >>>>>
> >>>>> Is it more hideous that using iommu groups to report a vfio imposed
> >>>>> restriction?  Are a couple open files and a handful of ioctls worse than
> >>>>> code to parse directory entries and the future maintenance of an
> >>>>> unrestricted grab bag of sysfs entries?
> >>>>
> >>>> At the moment DMA32 window properties are static. So I can easily get rid
> >>>> of VFIO_IOMMU_SPAPR_TCE_GET_INFO and be happy.
> >>>
> >>> Like, for instance, every PE always gets 512MB DMA window, fixed base
> >>> address, not configurable, end of story?
> >>
> >>
> >> Almost :) 1GB, starting at 0 (sometime at 2GB). Multiple PCI domains are
> >> supported on ppc64 so it does not make a problem as bus address spaces are
> >> separated. But yes, not flexible at all.
> >
> > Statements like "at the moment...", "[but] sometimes at..." make me
> > think it's best to keep the GET_INFO call.
> >
> >>>> Ah, anyway, how do you see these ioctls to work on a user machine?
> >>>> A separate tool which takes an iommu id, returns DMA window size and
> >>>> adjusts rlimit?
> >>>
> >>> Sure, we need something that provides the function of libvirt and
> >>> unbinds devices from host drivers, re-binds them to vfio-pci.  That tool
> >>> needs to have permissions to manipulate groups, so we're just talking
> >>> about whether it's stepping over the line for it to open the group and a
> >>> container, associate them, and probe the iommu info vs reading a sysfs
> >>> file.  Thanks,
> >>
> >> So the Tool is going to be a part of libvirt but not kernel or qemu, right?
> >> Then implementing "LOCK" (and call it after GET_INFO in QEMU and not call
> >> it from the Tool) should work fine.
> >
> > Right, a probe tool would check the value, close the files and set the
> > locked page limit for qemu, which would take the next step to trigger
> > the in-kernel accounting.  Thanks,
> 
> Continuing the discussion :)
> In meanwhile I added/tested VFIO_IOMMU_ENABLE and VFIO_IOMMU_DISABLE like 
> that (will repost the patch later, may be this week, only few changes there):
> 
> 
> +       case VFIO_IOMMU_ENABLE: {
> +               mutex_lock(&container->lock);
> +               ret = tce_iommu_enable(container);
> +               mutex_unlock(&container->lock);
> +
> +               return ret;
> +       }
> +       case VFIO_IOMMU_DISABLE: {
> +               mutex_lock(&container->lock);
> +               tce_iommu_disable(container);
> +               mutex_unlock(&container->lock);
> +
> +               return 0;
> +       }
> 
> and defined them as (not arch specific):
> 
> +/* IOCTLs to enable/disable IOMMU container usage */
> +#define VFIO_IOMMU_ENABLE      _IO(VFIO_TYPE, VFIO_BASE + 15)
> +#define VFIO_IOMMU_DISABLE     _IO(VFIO_TYPE, VFIO_BASE + 16)
> 
> 
> should be ok, right?

Seems fine.  Can you envision any parameters to either of these in the
future?  Be sure to document in the header and maybe add a SPAPR section
to Documentation/vfio.txt making note of the call flow for this IOMMU
backend.

> There is another question. It is possible to compile
> vfio_iommu_spapr_tce as a module. How/when is it supposed to be loaded?
> A user may not want to do "modprobe vfio_iommu_spapr_tce" manually.

See the request_module() call in drivers/vfio/vfio.c.  I'd think you'd
just add another for vfio_iommu_spapr_tce.  Thanks,

Alex

[PATCH] vfio powerpc: implement IOMMU driver for VFIO

[Alexey Kardashevskiy]

VFIO implements platform independent stuff such as
a PCI driver, BAR access (via read/write on a file descriptor
or direct mapping when possible) and IRQ signaling.

The platform dependent part includes IOMMU initialization
and handling. This patch implements an IOMMU driver for VFIO
which does mapping/unmapping pages for the guest IO and
provides information about DMA window (required by a POWERPC
guest).

The counterpart in QEMU is required to support this functionality.

Changelog:
* documentation updated
* containter enable/disable ioctls added
* request_module(spapr_iommu) added
* various locks fixed

Cc: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
 Documentation/vfio.txt              |   63 ++++++
 drivers/vfio/Kconfig                |    6 +
 drivers/vfio/Makefile               |    1 +
 drivers/vfio/vfio.c                 |    1 +
 drivers/vfio/vfio_iommu_spapr_tce.c |  365 +++++++++++++++++++++++++++++++++++
 include/uapi/linux/vfio.h           |   38 ++++
 6 files changed, 474 insertions(+)
 create mode 100644 drivers/vfio/vfio_iommu_spapr_tce.c

diff --git a/Documentation/vfio.txt b/Documentation/vfio.txt
index 8eda363..351f7c9 100644
--- a/Documentation/vfio.txt
+++ b/Documentation/vfio.txt
@@ -283,6 +283,69 @@ a direct pass through for VFIO_DEVICE_* ioctls.  The read/write/mmap
 interfaces implement the device region access defined by the device's
 own VFIO_DEVICE_GET_REGION_INFO ioctl.
 
+
+PPC64 sPAPR implementation note
+-------------------------------------------------------------------------------
+
+This implementation has some specifics:
+
+1) Only one IOMMU group per container is supported as an IOMMU group
+represents the minimal entity which isolation can be guaranteed for and
+groups are allocated statically, one per a Partitionable Endpoint (PE)
+(PE is often a PCI domain but not always).
+
+2) The hardware supports so called DMA windows - the PCI address range
+within which DMA transfer is allowed, any attempt to access address space
+out of the window leads to the whole PE isolation.
+
+3) PPC64 guests are paravirtualized but not fully emulated. There is an API
+to map/unmap pages for DMA, and it normally maps 1..32 pages per call and
+currently there is no way to reduce the number of calls. In order to make things
+faster, the map/unmap handling has been implented in real mode which provides
+an excellent performance which has limitations such as inability to do
+locked pages accounting in real time.
+
+So 3 additional ioctls have been added:
+
+	VFIO_IOMMU_SPAPR_TCE_GET_INFO - returns the size and the start
+		of the DMA window on the PCI bus.
+
+	VFIO_IOMMU_ENABLE - enables the container. The locked pages accounting
+		is done at this point. This lets user first to know what
+		the DMA window is and adjust rlimit before doing any real job.
+
+	VFIO_IOMMU_DISABLE - disables the container.
+
+
+The code flow from the example above should be slightly changed:
+
+	.....
+	/* Add the group to the container */
+	ioctl(group, VFIO_GROUP_SET_CONTAINER, &container);
+
+	/* Enable the IOMMU model we want */
+	ioctl(container, VFIO_SET_IOMMU, VFIO_SPAPR_TCE_IOMMU)
+
+	/* Get addition sPAPR IOMMU info */
+	vfio_iommu_spapr_tce_info spapr_iommu_info;
+	ioctl(container, VFIO_IOMMU_SPAPR_TCE_GET_INFO, &spapr_iommu_info);
+
+	if (ioctl(container, VFIO_IOMMU_ENABLE))
+		/* Cannot enable container, may be low rlimit */
+
+	/* Allocate some space and setup a DMA mapping */
+	dma_map.vaddr = mmap(0, 1024 * 1024, PROT_READ | PROT_WRITE,
+			     MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
+
+	dma_map.size = 1024 * 1024;
+	dma_map.iova = 0; /* 1MB starting at 0x0 from device view */
+	dma_map.flags = VFIO_DMA_MAP_FLAG_READ | VFIO_DMA_MAP_FLAG_WRITE;
+
+	/* Check here is .iova/.size are within DMA window from spapr_iommu_info */
+
+	ioctl(container, VFIO_IOMMU_MAP_DMA, &dma_map);
+	.....
+
 -------------------------------------------------------------------------------
 
 [1] VFIO was originally an acronym for "Virtual Function I/O" in its
diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
index 7cd5dec..b464687 100644
--- a/drivers/vfio/Kconfig
+++ b/drivers/vfio/Kconfig
@@ -3,10 +3,16 @@ config VFIO_IOMMU_TYPE1
 	depends on VFIO
 	default n
 
+config VFIO_IOMMU_SPAPR_TCE
+	tristate
+	depends on VFIO && SPAPR_TCE_IOMMU
+	default n
+
 menuconfig VFIO
 	tristate "VFIO Non-Privileged userspace driver framework"
 	depends on IOMMU_API
 	select VFIO_IOMMU_TYPE1 if X86
+	select VFIO_IOMMU_SPAPR_TCE if PPC_POWERNV
 	help
 	  VFIO provides a framework for secure userspace device drivers.
 	  See Documentation/vfio.txt for more details.
diff --git a/drivers/vfio/Makefile b/drivers/vfio/Makefile
index 2398d4a..72bfabc 100644
--- a/drivers/vfio/Makefile
+++ b/drivers/vfio/Makefile
@@ -1,3 +1,4 @@
 obj-$(CONFIG_VFIO) += vfio.o
 obj-$(CONFIG_VFIO_IOMMU_TYPE1) += vfio_iommu_type1.o
+obj-$(CONFIG_VFIO_IOMMU_SPAPR_TCE) += vfio_iommu_spapr_tce.o
 obj-$(CONFIG_VFIO_PCI) += pci/
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 12c264d..004033d 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -1376,6 +1376,7 @@ static int __init vfio_init(void)
 	 * drivers.
 	 */
 	request_module_nowait("vfio_iommu_type1");
+	request_module_nowait("vfio_iommu_spapr");
 
 	return 0;
 
diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c b/drivers/vfio/vfio_iommu_spapr_tce.c
new file mode 100644
index 0000000..22ba0b5
--- /dev/null
+++ b/drivers/vfio/vfio_iommu_spapr_tce.c
@@ -0,0 +1,365 @@
+/*
+ * VFIO: IOMMU DMA mapping support for TCE on POWER
+ *
+ * Copyright (C) 2013 IBM Corp.  All rights reserved.
+ *     Author: Alexey Kardashevskiy <aik@ozlabs.ru>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Derived from original vfio_iommu_type1.c:
+ * Copyright (C) 2012 Red Hat, Inc.  All rights reserved.
+ *     Author: Alex Williamson <alex.williamson@redhat.com>
+ */
+
+#include <linux/module.h>
+#include <linux/pci.h>
+#include <linux/slab.h>
+#include <linux/uaccess.h>
+#include <linux/err.h>
+#include <linux/vfio.h>
+#include <asm/iommu.h>
+#include <asm/tce.h>
+
+#define DRIVER_VERSION  "0.1"
+#define DRIVER_AUTHOR   "aik@ozlabs.ru"
+#define DRIVER_DESC     "VFIO IOMMU SPAPR TCE"
+
+static void tce_iommu_detach_group(void *iommu_data,
+		struct iommu_group *iommu_group);
+
+/*
+ * VFIO IOMMU fd for SPAPR_TCE IOMMU implementation
+ *
+ * This code handles mapping and unmapping of user data buffers
+ * into DMA'ble space using the IOMMU
+ */
+
+/*
+ * The container descriptor supports only a single group per container.
+ * Required by the API as the container is not supplied with the IOMMU group
+ * at the moment of initialization.
+ */
+struct tce_container {
+	struct mutex lock;
+	struct iommu_table *tbl;
+	bool enabled;
+};
+
+static int tce_iommu_enable(struct tce_container *container)
+{
+	int ret = 0;
+	unsigned long locked, lock_limit, npages;
+	struct iommu_table *tbl = container->tbl;
+
+	if (!container->tbl)
+		return -ENXIO;
+
+	if (!current->mm)
+		return -ESRCH; /* process exited */
+
+	mutex_lock(&container->lock);
+	if (container->enabled) {
+		mutex_unlock(&container->lock);
+		return -EBUSY;
+	}
+
+	/*
+	 * Accounting for locked pages.
+	 *
+	 * On sPAPR platform, IOMMU translation table contains
+	 * an entry per 4K page. Every map/unmap request is sent
+	 * by the guest via hypercall and supposed to be handled
+	 * quickly, ecpesially in real mode (if such option is
+	 * supported and enabled).
+	 * As handling the accounting in real time is rather
+	 * impossible, it may require switching to virtual mode
+	 * which is quite expensive operation.
+	 * As the whole window can be actuall mapped on high
+	 * performance guests and we do not want such guests
+	 * to fail, we do the accounting as a part of IOMMU
+	 * enablement process.
+	 */
+	down_write(&current->mm->mmap_sem);
+	npages = (tbl->it_size << IOMMU_PAGE_SHIFT) >> PAGE_SHIFT;
+	locked = current->mm->locked_vm + npages;
+	lock_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
+	if (locked > lock_limit && !capable(CAP_IPC_LOCK)) {
+		pr_warn("RLIMIT_MEMLOCK (%ld) exceeded\n",
+				rlimit(RLIMIT_MEMLOCK));
+		ret = -ENOMEM;
+	} else {
+
+		current->mm->locked_vm += npages;
+		container->enabled = true;
+	}
+	up_write(&current->mm->mmap_sem);
+
+	mutex_unlock(&container->lock);
+
+	return ret;
+}
+
+static void tce_iommu_disable(struct tce_container *container)
+{
+	mutex_lock(&container->lock);
+
+	if (container->enabled && container->tbl) {
+		if (current->mm) {
+			down_write(&current->mm->mmap_sem);
+			current->mm->locked_vm -= (container->tbl->it_size <<
+					IOMMU_PAGE_SHIFT) >> PAGE_SHIFT;
+			up_write(&current->mm->mmap_sem);
+		}
+		container->enabled = false;
+	}
+
+	mutex_unlock(&container->lock);
+}
+
+static void *tce_iommu_open(unsigned long arg)
+{
+	struct tce_container *container;
+
+	if (arg != VFIO_SPAPR_TCE_IOMMU) {
+		pr_err("tce_vfio: Wrong IOMMU type\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	container = kzalloc(sizeof(*container), GFP_KERNEL);
+	if (!container)
+		return ERR_PTR(-ENOMEM);
+
+	mutex_init(&container->lock);
+
+	return container;
+}
+
+static void tce_iommu_release(void *iommu_data)
+{
+	struct tce_container *container = iommu_data;
+
+	WARN_ON(container->tbl && !container->tbl->it_group);
+	tce_iommu_disable(container);
+
+	if (container->tbl && container->tbl->it_group)
+		tce_iommu_detach_group(iommu_data, container->tbl->it_group);
+
+	mutex_destroy(&container->lock);
+
+	kfree(container);
+}
+
+static long tce_iommu_ioctl(void *iommu_data,
+				 unsigned int cmd, unsigned long arg)
+{
+	struct tce_container *container = iommu_data;
+	unsigned long minsz;
+	long ret;
+
+	switch (cmd) {
+	case VFIO_CHECK_EXTENSION:
+		return (arg == VFIO_SPAPR_TCE_IOMMU) ? 1 : 0;
+
+	case VFIO_IOMMU_SPAPR_TCE_GET_INFO: {
+		struct vfio_iommu_spapr_tce_info info;
+		struct iommu_table *tbl = container->tbl;
+
+		if (WARN_ON(!tbl))
+			return -ENXIO;
+
+		minsz = offsetofend(struct vfio_iommu_spapr_tce_info,
+				dma32_window_size);
+
+		if (copy_from_user(&info, (void __user *)arg, minsz))
+			return -EFAULT;
+
+		if (info.argsz < minsz)
+			return -EINVAL;
+
+		info.dma32_window_start = tbl->it_offset << IOMMU_PAGE_SHIFT;
+		info.dma32_window_size = tbl->it_size << IOMMU_PAGE_SHIFT;
+		info.flags = 0;
+
+		if (copy_to_user((void __user *)arg, &info, minsz))
+			return -EFAULT;
+
+		return 0;
+	}
+	case VFIO_IOMMU_MAP_DMA: {
+		vfio_iommu_spapr_tce_dma_map param;
+		struct iommu_table *tbl = container->tbl;
+		unsigned long tce;
+
+		if (WARN_ON(!tbl))
+			return -ENXIO;
+
+		minsz = offsetofend(vfio_iommu_spapr_tce_dma_map, size);
+
+		if (copy_from_user(&param, (void __user *)arg, minsz))
+			return -EFAULT;
+
+		if (param.argsz < minsz)
+			return -EINVAL;
+
+		if (param.flags & ~(VFIO_DMA_MAP_FLAG_READ |
+				VFIO_DMA_MAP_FLAG_WRITE))
+			return -EINVAL;
+
+		if ((param.size & ~IOMMU_PAGE_MASK) ||
+				(param.vaddr & ~IOMMU_PAGE_MASK))
+			return -EINVAL;
+
+		/* TODO: support multiple TCEs */
+		if (param.size != IOMMU_PAGE_SIZE) {
+			pr_err("VFIO map on POWER supports only %lu page size\n",
+					IOMMU_PAGE_SIZE);
+			return -EINVAL;
+		}
+
+		/* iova is checked by the IOMMU API */
+		tce = param.vaddr;
+		if (param.flags & VFIO_DMA_MAP_FLAG_READ)
+			tce |= TCE_PCI_READ;
+		if (param.flags & VFIO_DMA_MAP_FLAG_WRITE)
+			tce |= TCE_PCI_WRITE;
+
+		ret = iommu_tce_put_param_check(tbl, param.iova, tce);
+		if (ret)
+			return ret;
+
+		ret = iommu_put_tce_user_mode(tbl,
+				param.iova >> IOMMU_PAGE_SHIFT, tce);
+		iommu_flush_tce(tbl);
+
+		return ret;
+	}
+	case VFIO_IOMMU_UNMAP_DMA: {
+		vfio_iommu_spapr_tce_dma_unmap param;
+		struct iommu_table *tbl = container->tbl;
+
+		if (WARN_ON(!tbl))
+			return -ENXIO;
+
+		minsz = offsetofend(vfio_iommu_spapr_tce_dma_unmap, size);
+
+		if (copy_from_user(&param, (void __user *)arg, minsz))
+			return -EFAULT;
+
+		if (param.argsz < minsz)
+			return -EINVAL;
+
+		/* No flag is supported now */
+		if (param.flags)
+			return -EINVAL;
+
+		if (param.size & ~IOMMU_PAGE_MASK)
+			return -EINVAL;
+
+		ret = iommu_tce_clear_param_check(tbl, param.iova, 0,
+				param.size >> IOMMU_PAGE_SHIFT);
+		if (ret)
+			return ret;
+
+		ret = iommu_clear_tces_and_put_pages(tbl,
+				param.iova >> IOMMU_PAGE_SHIFT,
+				param.size >> IOMMU_PAGE_SHIFT);
+		iommu_flush_tce(tbl);
+
+		return ret;
+	}
+	case VFIO_IOMMU_ENABLE: {
+		return tce_iommu_enable(container);
+	}
+	case VFIO_IOMMU_DISABLE: {
+		tce_iommu_disable(container);
+		return 0;
+	}
+	}
+
+	return -ENOTTY;
+}
+
+static int tce_iommu_attach_group(void *iommu_data,
+		struct iommu_group *iommu_group)
+{
+	int ret;
+	struct tce_container *container = iommu_data;
+	struct iommu_table *tbl = iommu_group_get_iommudata(iommu_group);
+
+	BUG_ON(!tbl);
+	mutex_lock(&container->lock);
+	pr_debug("tce_vfio: Attaching group #%u to iommu %p\n",
+			iommu_group_id(iommu_group), iommu_group);
+	if (container->tbl) {
+		pr_warn("tce_vfio: Only one group per IOMMU container is allowed, existing id=%d, attaching id=%d\n",
+				iommu_group_id(container->tbl->it_group),
+				iommu_group_id(iommu_group));
+		mutex_unlock(&container->lock);
+		return -EBUSY;
+	}
+
+	ret = iommu_take_ownership(tbl);
+	if (!ret)
+		container->tbl = tbl;
+
+	mutex_unlock(&container->lock);
+
+	return ret;
+}
+
+static void tce_iommu_detach_group(void *iommu_data,
+		struct iommu_group *iommu_group)
+{
+	struct tce_container *container = iommu_data;
+	struct iommu_table *tbl = iommu_group_get_iommudata(iommu_group);
+
+	BUG_ON(!tbl);
+	mutex_lock(&container->lock);
+	if (tbl != container->tbl) {
+		pr_warn("tce_vfio: detaching group #%u, expected group is #%u\n",
+				iommu_group_id(iommu_group),
+				iommu_group_id(tbl->it_group));
+	} else if (container->enabled) {
+		pr_err("tce_vfio: detaching group #%u from enabled container\n",
+				iommu_group_id(tbl->it_group));
+	} else {
+
+		pr_debug("tce_vfio: detaching group #%u from iommu %p\n",
+				iommu_group_id(iommu_group), iommu_group);
+
+		container->tbl = NULL;
+		iommu_release_ownership(tbl);
+	}
+	mutex_unlock(&container->lock);
+}
+
+const struct vfio_iommu_driver_ops tce_iommu_driver_ops = {
+	.name		= "iommu-vfio-powerpc",
+	.owner		= THIS_MODULE,
+	.open		= tce_iommu_open,
+	.release	= tce_iommu_release,
+	.ioctl		= tce_iommu_ioctl,
+	.attach_group	= tce_iommu_attach_group,
+	.detach_group	= tce_iommu_detach_group,
+};
+
+static int __init tce_iommu_init(void)
+{
+	return vfio_register_iommu_driver(&tce_iommu_driver_ops);
+}
+
+static void __exit tce_iommu_cleanup(void)
+{
+	vfio_unregister_iommu_driver(&tce_iommu_driver_ops);
+}
+
+module_init(tce_iommu_init);
+module_exit(tce_iommu_cleanup);
+
+MODULE_VERSION(DRIVER_VERSION);
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR(DRIVER_AUTHOR);
+MODULE_DESCRIPTION(DRIVER_DESC);
+
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 4758d1b..38ecccf 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -22,6 +22,7 @@
 /* Extensions */
 
 #define VFIO_TYPE1_IOMMU		1
+#define VFIO_SPAPR_TCE_IOMMU		2
 
 /*
  * The IOCTL interface is designed for extensibility by embedding the
@@ -365,4 +366,41 @@ struct vfio_iommu_type1_dma_unmap {
 
 #define VFIO_IOMMU_UNMAP_DMA _IO(VFIO_TYPE, VFIO_BASE + 14)
 
+/*
+ * IOCTLs to enable/disable IOMMU container usage.
+ * No parameters are supported.
+ */
+#define VFIO_IOMMU_ENABLE	_IO(VFIO_TYPE, VFIO_BASE + 15)
+#define VFIO_IOMMU_DISABLE	_IO(VFIO_TYPE, VFIO_BASE + 16)
+
+/* -------- Additional API for SPAPR TCE (Server POWERPC) IOMMU -------- */
+
+/*
+ * The SPAPR TCE info struct provides the information about the PCI bus
+ * address ranges available for DMA, these values are programmed into
+ * the hardware so the guest has to know that information.
+ *
+ * The DMA 32 bit window start is an absolute PCI bus address.
+ * The IOVA address passed via map/unmap ioctls are absolute PCI bus
+ * addresses too so the window works as a filter rather than an offset
+ * for IOVA addresses.
+ *
+ * A flag will need to be added if other page sizes are supported,
+ * so as defined here, it is always 4k.
+ */
+struct vfio_iommu_spapr_tce_info {
+	__u32 argsz;
+	__u32 flags;			/* reserved for future use */
+	__u32 dma32_window_start;	/* 32 bit window start (bytes) */
+	__u32 dma32_window_size;	/* 32 bit window size (bytes) */
+};
+
+#define VFIO_IOMMU_SPAPR_TCE_GET_INFO	_IO(VFIO_TYPE, VFIO_BASE + 12)
+
+/* Reuse type1 map/unmap structs as they are the same at the moment */
+typedef struct vfio_iommu_type1_dma_map vfio_iommu_spapr_tce_dma_map;
+typedef struct vfio_iommu_type1_dma_unmap vfio_iommu_spapr_tce_dma_unmap;
+
+/* ***************************************************************** */
+
 #endif /* _UAPIVFIO_H */
-- 
1.7.10.4

Re: [PATCH] vfio powerpc: implement IOMMU driver for VFIO

[Alex Williamson]

On Tue, 2013-03-19 at 18:08 +1100, Alexey Kardashevskiy wrote:
> VFIO implements platform independent stuff such as
> a PCI driver, BAR access (via read/write on a file descriptor
> or direct mapping when possible) and IRQ signaling.
> 
> The platform dependent part includes IOMMU initialization
> and handling. This patch implements an IOMMU driver for VFIO
> which does mapping/unmapping pages for the guest IO and
> provides information about DMA window (required by a POWERPC
> guest).
> 
> The counterpart in QEMU is required to support this functionality.
> 
> Changelog:
> * documentation updated
> * containter enable/disable ioctls added
> * request_module(spapr_iommu) added
> * various locks fixed
> 
> Cc: David Gibson <david@gibson.dropbear.id.au>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---


Looking pretty good.  There's one problem with the detach_group,
otherwise just some trivial comments below.  What's the status of the
tce code that this depends on?  Thanks,

Alex

>  Documentation/vfio.txt              |   63 ++++++
>  drivers/vfio/Kconfig                |    6 +
>  drivers/vfio/Makefile               |    1 +
>  drivers/vfio/vfio.c                 |    1 +
>  drivers/vfio/vfio_iommu_spapr_tce.c |  365 +++++++++++++++++++++++++++++++++++
>  include/uapi/linux/vfio.h           |   38 ++++
>  6 files changed, 474 insertions(+)
>  create mode 100644 drivers/vfio/vfio_iommu_spapr_tce.c
> 
> diff --git a/Documentation/vfio.txt b/Documentation/vfio.txt
> index 8eda363..351f7c9 100644
> --- a/Documentation/vfio.txt
> +++ b/Documentation/vfio.txt
> @@ -283,6 +283,69 @@ a direct pass through for VFIO_DEVICE_* ioctls.  The read/write/mmap
>  interfaces implement the device region access defined by the device's
>  own VFIO_DEVICE_GET_REGION_INFO ioctl.
>  
> +
> +PPC64 sPAPR implementation note
> +-------------------------------------------------------------------------------
> +
> +This implementation has some specifics:
> +
> +1) Only one IOMMU group per container is supported as an IOMMU group
> +represents the minimal entity which isolation can be guaranteed for and
> +groups are allocated statically, one per a Partitionable Endpoint (PE)
> +(PE is often a PCI domain but not always).
> +
> +2) The hardware supports so called DMA windows - the PCI address range
> +within which DMA transfer is allowed, any attempt to access address space
> +out of the window leads to the whole PE isolation.
> +
> +3) PPC64 guests are paravirtualized but not fully emulated. There is an API
> +to map/unmap pages for DMA, and it normally maps 1..32 pages per call and
> +currently there is no way to reduce the number of calls. In order to make things
> +faster, the map/unmap handling has been implented in real mode which provides

s/implented/implemented/

> +an excellent performance which has limitations such as inability to do
> +locked pages accounting in real time.
> +
> +So 3 additional ioctls have been added:
> +
> +	VFIO_IOMMU_SPAPR_TCE_GET_INFO - returns the size and the start
> +		of the DMA window on the PCI bus.
> +
> +	VFIO_IOMMU_ENABLE - enables the container. The locked pages accounting
> +		is done at this point. This lets user first to know what
> +		the DMA window is and adjust rlimit before doing any real job.
> +
> +	VFIO_IOMMU_DISABLE - disables the container.
> +
> +
> +The code flow from the example above should be slightly changed:
> +
> +	.....
> +	/* Add the group to the container */
> +	ioctl(group, VFIO_GROUP_SET_CONTAINER, &container);
> +
> +	/* Enable the IOMMU model we want */
> +	ioctl(container, VFIO_SET_IOMMU, VFIO_SPAPR_TCE_IOMMU)
> +
> +	/* Get addition sPAPR IOMMU info */
> +	vfio_iommu_spapr_tce_info spapr_iommu_info;
> +	ioctl(container, VFIO_IOMMU_SPAPR_TCE_GET_INFO, &spapr_iommu_info);
> +
> +	if (ioctl(container, VFIO_IOMMU_ENABLE))
> +		/* Cannot enable container, may be low rlimit */
> +
> +	/* Allocate some space and setup a DMA mapping */
> +	dma_map.vaddr = mmap(0, 1024 * 1024, PROT_READ | PROT_WRITE,
> +			     MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
> +
> +	dma_map.size = 1024 * 1024;
> +	dma_map.iova = 0; /* 1MB starting at 0x0 from device view */
> +	dma_map.flags = VFIO_DMA_MAP_FLAG_READ | VFIO_DMA_MAP_FLAG_WRITE;
> +
> +	/* Check here is .iova/.size are within DMA window from spapr_iommu_info */
> +
> +	ioctl(container, VFIO_IOMMU_MAP_DMA, &dma_map);
> +	.....
> +

Awesome, thanks for the docs update

>  -------------------------------------------------------------------------------
>  
>  [1] VFIO was originally an acronym for "Virtual Function I/O" in its
> diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
> index 7cd5dec..b464687 100644
> --- a/drivers/vfio/Kconfig
> +++ b/drivers/vfio/Kconfig
> @@ -3,10 +3,16 @@ config VFIO_IOMMU_TYPE1
>  	depends on VFIO
>  	default n
>  
> +config VFIO_IOMMU_SPAPR_TCE
> +	tristate
> +	depends on VFIO && SPAPR_TCE_IOMMU
> +	default n
> +
>  menuconfig VFIO
>  	tristate "VFIO Non-Privileged userspace driver framework"
>  	depends on IOMMU_API
>  	select VFIO_IOMMU_TYPE1 if X86
> +	select VFIO_IOMMU_SPAPR_TCE if PPC_POWERNV
>  	help
>  	  VFIO provides a framework for secure userspace device drivers.
>  	  See Documentation/vfio.txt for more details.
> diff --git a/drivers/vfio/Makefile b/drivers/vfio/Makefile
> index 2398d4a..72bfabc 100644
> --- a/drivers/vfio/Makefile
> +++ b/drivers/vfio/Makefile
> @@ -1,3 +1,4 @@
>  obj-$(CONFIG_VFIO) += vfio.o
>  obj-$(CONFIG_VFIO_IOMMU_TYPE1) += vfio_iommu_type1.o
> +obj-$(CONFIG_VFIO_IOMMU_SPAPR_TCE) += vfio_iommu_spapr_tce.o
>  obj-$(CONFIG_VFIO_PCI) += pci/
> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> index 12c264d..004033d 100644
> --- a/drivers/vfio/vfio.c
> +++ b/drivers/vfio/vfio.c
> @@ -1376,6 +1376,7 @@ static int __init vfio_init(void)
>  	 * drivers.
>  	 */
>  	request_module_nowait("vfio_iommu_type1");
> +	request_module_nowait("vfio_iommu_spapr");
>  
>  	return 0;
>  
> diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c b/drivers/vfio/vfio_iommu_spapr_tce.c
> new file mode 100644
> index 0000000..22ba0b5
> --- /dev/null
> +++ b/drivers/vfio/vfio_iommu_spapr_tce.c
> @@ -0,0 +1,365 @@
> +/*
> + * VFIO: IOMMU DMA mapping support for TCE on POWER
> + *
> + * Copyright (C) 2013 IBM Corp.  All rights reserved.
> + *     Author: Alexey Kardashevskiy <aik@ozlabs.ru>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * Derived from original vfio_iommu_type1.c:
> + * Copyright (C) 2012 Red Hat, Inc.  All rights reserved.
> + *     Author: Alex Williamson <alex.williamson@redhat.com>
> + */
> +
> +#include <linux/module.h>
> +#include <linux/pci.h>
> +#include <linux/slab.h>
> +#include <linux/uaccess.h>
> +#include <linux/err.h>
> +#include <linux/vfio.h>
> +#include <asm/iommu.h>
> +#include <asm/tce.h>
> +
> +#define DRIVER_VERSION  "0.1"
> +#define DRIVER_AUTHOR   "aik@ozlabs.ru"
> +#define DRIVER_DESC     "VFIO IOMMU SPAPR TCE"
> +
> +static void tce_iommu_detach_group(void *iommu_data,
> +		struct iommu_group *iommu_group);
> +
> +/*
> + * VFIO IOMMU fd for SPAPR_TCE IOMMU implementation
> + *
> + * This code handles mapping and unmapping of user data buffers
> + * into DMA'ble space using the IOMMU
> + */
> +
> +/*
> + * The container descriptor supports only a single group per container.
> + * Required by the API as the container is not supplied with the IOMMU group
> + * at the moment of initialization.
> + */
> +struct tce_container {
> +	struct mutex lock;
> +	struct iommu_table *tbl;
> +	bool enabled;
> +};
> +
> +static int tce_iommu_enable(struct tce_container *container)
> +{
> +	int ret = 0;
> +	unsigned long locked, lock_limit, npages;
> +	struct iommu_table *tbl = container->tbl;
> +
> +	if (!container->tbl)
> +		return -ENXIO;
> +
> +	if (!current->mm)
> +		return -ESRCH; /* process exited */
> +
> +	mutex_lock(&container->lock);
> +	if (container->enabled) {
> +		mutex_unlock(&container->lock);
> +		return -EBUSY;
> +	}
> +
> +	/*
> +	 * Accounting for locked pages.
> +	 *
> +	 * On sPAPR platform, IOMMU translation table contains
> +	 * an entry per 4K page. Every map/unmap request is sent
> +	 * by the guest via hypercall and supposed to be handled
> +	 * quickly, ecpesially in real mode (if such option is

s/ecpesially/especially/

> +	 * supported and enabled).
> +	 * As handling the accounting in real time is rather
> +	 * impossible, it may require switching to virtual mode
> +	 * which is quite expensive operation.
> +	 * As the whole window can be actuall mapped on high

s/actuall/actually/

> +	 * performance guests and we do not want such guests
> +	 * to fail, we do the accounting as a part of IOMMU
> +	 * enablement process.
> +	 */
> +	down_write(&current->mm->mmap_sem);
> +	npages = (tbl->it_size << IOMMU_PAGE_SHIFT) >> PAGE_SHIFT;
> +	locked = current->mm->locked_vm + npages;
> +	lock_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
> +	if (locked > lock_limit && !capable(CAP_IPC_LOCK)) {
> +		pr_warn("RLIMIT_MEMLOCK (%ld) exceeded\n",
> +				rlimit(RLIMIT_MEMLOCK));
> +		ret = -ENOMEM;
> +	} else {
> +
> +		current->mm->locked_vm += npages;
> +		container->enabled = true;
> +	}
> +	up_write(&current->mm->mmap_sem);
> +
> +	mutex_unlock(&container->lock);
> +
> +	return ret;
> +}
> +
> +static void tce_iommu_disable(struct tce_container *container)
> +{
> +	mutex_lock(&container->lock);
> +
> +	if (container->enabled && container->tbl) {
> +		if (current->mm) {
> +			down_write(&current->mm->mmap_sem);
> +			current->mm->locked_vm -= (container->tbl->it_size <<
> +					IOMMU_PAGE_SHIFT) >> PAGE_SHIFT;
> +			up_write(&current->mm->mmap_sem);
> +		}
> +		container->enabled = false;
> +	}
> +
> +	mutex_unlock(&container->lock);
> +}
> +
> +static void *tce_iommu_open(unsigned long arg)
> +{
> +	struct tce_container *container;
> +
> +	if (arg != VFIO_SPAPR_TCE_IOMMU) {
> +		pr_err("tce_vfio: Wrong IOMMU type\n");
> +		return ERR_PTR(-EINVAL);
> +	}
> +
> +	container = kzalloc(sizeof(*container), GFP_KERNEL);
> +	if (!container)
> +		return ERR_PTR(-ENOMEM);
> +
> +	mutex_init(&container->lock);
> +
> +	return container;
> +}
> +
> +static void tce_iommu_release(void *iommu_data)
> +{
> +	struct tce_container *container = iommu_data;
> +
> +	WARN_ON(container->tbl && !container->tbl->it_group);
> +	tce_iommu_disable(container);
> +
> +	if (container->tbl && container->tbl->it_group)
> +		tce_iommu_detach_group(iommu_data, container->tbl->it_group);
> +
> +	mutex_destroy(&container->lock);
> +
> +	kfree(container);
> +}
> +
> +static long tce_iommu_ioctl(void *iommu_data,
> +				 unsigned int cmd, unsigned long arg)
> +{
> +	struct tce_container *container = iommu_data;
> +	unsigned long minsz;
> +	long ret;
> +
> +	switch (cmd) {
> +	case VFIO_CHECK_EXTENSION:
> +		return (arg == VFIO_SPAPR_TCE_IOMMU) ? 1 : 0;
> +
> +	case VFIO_IOMMU_SPAPR_TCE_GET_INFO: {
> +		struct vfio_iommu_spapr_tce_info info;
> +		struct iommu_table *tbl = container->tbl;
> +
> +		if (WARN_ON(!tbl))
> +			return -ENXIO;
> +
> +		minsz = offsetofend(struct vfio_iommu_spapr_tce_info,
> +				dma32_window_size);
> +
> +		if (copy_from_user(&info, (void __user *)arg, minsz))
> +			return -EFAULT;
> +
> +		if (info.argsz < minsz)
> +			return -EINVAL;
> +
> +		info.dma32_window_start = tbl->it_offset << IOMMU_PAGE_SHIFT;
> +		info.dma32_window_size = tbl->it_size << IOMMU_PAGE_SHIFT;
> +		info.flags = 0;
> +
> +		if (copy_to_user((void __user *)arg, &info, minsz))
> +			return -EFAULT;
> +
> +		return 0;
> +	}
> +	case VFIO_IOMMU_MAP_DMA: {
> +		vfio_iommu_spapr_tce_dma_map param;
> +		struct iommu_table *tbl = container->tbl;
> +		unsigned long tce;
> +
> +		if (WARN_ON(!tbl))
> +			return -ENXIO;
> +
> +		minsz = offsetofend(vfio_iommu_spapr_tce_dma_map, size);
> +
> +		if (copy_from_user(&param, (void __user *)arg, minsz))
> +			return -EFAULT;
> +
> +		if (param.argsz < minsz)
> +			return -EINVAL;
> +
> +		if (param.flags & ~(VFIO_DMA_MAP_FLAG_READ |
> +				VFIO_DMA_MAP_FLAG_WRITE))
> +			return -EINVAL;
> +
> +		if ((param.size & ~IOMMU_PAGE_MASK) ||
> +				(param.vaddr & ~IOMMU_PAGE_MASK))
> +			return -EINVAL;
> +
> +		/* TODO: support multiple TCEs */
> +		if (param.size != IOMMU_PAGE_SIZE) {
> +			pr_err("VFIO map on POWER supports only %lu page size\n",
> +					IOMMU_PAGE_SIZE);
> +			return -EINVAL;
> +		}
> +
> +		/* iova is checked by the IOMMU API */
> +		tce = param.vaddr;
> +		if (param.flags & VFIO_DMA_MAP_FLAG_READ)
> +			tce |= TCE_PCI_READ;
> +		if (param.flags & VFIO_DMA_MAP_FLAG_WRITE)
> +			tce |= TCE_PCI_WRITE;
> +
> +		ret = iommu_tce_put_param_check(tbl, param.iova, tce);
> +		if (ret)
> +			return ret;
> +
> +		ret = iommu_put_tce_user_mode(tbl,
> +				param.iova >> IOMMU_PAGE_SHIFT, tce);
> +		iommu_flush_tce(tbl);
> +
> +		return ret;
> +	}
> +	case VFIO_IOMMU_UNMAP_DMA: {
> +		vfio_iommu_spapr_tce_dma_unmap param;
> +		struct iommu_table *tbl = container->tbl;
> +
> +		if (WARN_ON(!tbl))
> +			return -ENXIO;
> +
> +		minsz = offsetofend(vfio_iommu_spapr_tce_dma_unmap, size);
> +
> +		if (copy_from_user(&param, (void __user *)arg, minsz))
> +			return -EFAULT;
> +
> +		if (param.argsz < minsz)
> +			return -EINVAL;
> +
> +		/* No flag is supported now */
> +		if (param.flags)
> +			return -EINVAL;
> +
> +		if (param.size & ~IOMMU_PAGE_MASK)
> +			return -EINVAL;
> +
> +		ret = iommu_tce_clear_param_check(tbl, param.iova, 0,
> +				param.size >> IOMMU_PAGE_SHIFT);
> +		if (ret)
> +			return ret;
> +
> +		ret = iommu_clear_tces_and_put_pages(tbl,
> +				param.iova >> IOMMU_PAGE_SHIFT,
> +				param.size >> IOMMU_PAGE_SHIFT);
> +		iommu_flush_tce(tbl);
> +
> +		return ret;
> +	}
> +	case VFIO_IOMMU_ENABLE: {
> +		return tce_iommu_enable(container);
> +	}
> +	case VFIO_IOMMU_DISABLE: {
> +		tce_iommu_disable(container);
> +		return 0;
> +	}

Unnecessary brackets

> +	}
> +
> +	return -ENOTTY;
> +}
> +
> +static int tce_iommu_attach_group(void *iommu_data,
> +		struct iommu_group *iommu_group)
> +{
> +	int ret;
> +	struct tce_container *container = iommu_data;
> +	struct iommu_table *tbl = iommu_group_get_iommudata(iommu_group);
> +
> +	BUG_ON(!tbl);
> +	mutex_lock(&container->lock);
> +	pr_debug("tce_vfio: Attaching group #%u to iommu %p\n",
> +			iommu_group_id(iommu_group), iommu_group);
> +	if (container->tbl) {
> +		pr_warn("tce_vfio: Only one group per IOMMU container is allowed, existing id=%d, attaching id=%d\n",
> +				iommu_group_id(container->tbl->it_group),
> +				iommu_group_id(iommu_group));
> +		mutex_unlock(&container->lock);
> +		return -EBUSY;
> +	}
> +
> +	ret = iommu_take_ownership(tbl);
> +	if (!ret)
> +		container->tbl = tbl;
> +
> +	mutex_unlock(&container->lock);
> +
> +	return ret;
> +}
> +
> +static void tce_iommu_detach_group(void *iommu_data,
> +		struct iommu_group *iommu_group)
> +{
> +	struct tce_container *container = iommu_data;
> +	struct iommu_table *tbl = iommu_group_get_iommudata(iommu_group);
> +
> +	BUG_ON(!tbl);
> +	mutex_lock(&container->lock);
> +	if (tbl != container->tbl) {
> +		pr_warn("tce_vfio: detaching group #%u, expected group is #%u\n",
> +				iommu_group_id(iommu_group),
> +				iommu_group_id(tbl->it_group));
> +	} else if (container->enabled) {
> +		pr_err("tce_vfio: detaching group #%u from enabled container\n",
> +				iommu_group_id(tbl->it_group));

Hmm, something more than a pr_err needs to happen here.  Wouldn't this
imply a disable and going back to an unprivileged container?

> +	} else {
> +
> +		pr_debug("tce_vfio: detaching group #%u from iommu %p\n",
> +				iommu_group_id(iommu_group), iommu_group);
> +
> +		container->tbl = NULL;
> +		iommu_release_ownership(tbl);
> +	}
> +	mutex_unlock(&container->lock);
> +}
> +
> +const struct vfio_iommu_driver_ops tce_iommu_driver_ops = {
> +	.name		= "iommu-vfio-powerpc",
> +	.owner		= THIS_MODULE,
> +	.open		= tce_iommu_open,
> +	.release	= tce_iommu_release,
> +	.ioctl		= tce_iommu_ioctl,
> +	.attach_group	= tce_iommu_attach_group,
> +	.detach_group	= tce_iommu_detach_group,
> +};
> +
> +static int __init tce_iommu_init(void)
> +{
> +	return vfio_register_iommu_driver(&tce_iommu_driver_ops);
> +}
> +
> +static void __exit tce_iommu_cleanup(void)
> +{
> +	vfio_unregister_iommu_driver(&tce_iommu_driver_ops);
> +}
> +
> +module_init(tce_iommu_init);
> +module_exit(tce_iommu_cleanup);
> +
> +MODULE_VERSION(DRIVER_VERSION);
> +MODULE_LICENSE("GPL v2");
> +MODULE_AUTHOR(DRIVER_AUTHOR);
> +MODULE_DESCRIPTION(DRIVER_DESC);
> +
> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> index 4758d1b..38ecccf 100644
> --- a/include/uapi/linux/vfio.h
> +++ b/include/uapi/linux/vfio.h
> @@ -22,6 +22,7 @@
>  /* Extensions */
>  
>  #define VFIO_TYPE1_IOMMU		1
> +#define VFIO_SPAPR_TCE_IOMMU		2
>  
>  /*
>   * The IOCTL interface is designed for extensibility by embedding the
> @@ -365,4 +366,41 @@ struct vfio_iommu_type1_dma_unmap {
>  
>  #define VFIO_IOMMU_UNMAP_DMA _IO(VFIO_TYPE, VFIO_BASE + 14)
>  
> +/*
> + * IOCTLs to enable/disable IOMMU container usage.
> + * No parameters are supported.
> + */
> +#define VFIO_IOMMU_ENABLE	_IO(VFIO_TYPE, VFIO_BASE + 15)
> +#define VFIO_IOMMU_DISABLE	_IO(VFIO_TYPE, VFIO_BASE + 16)
> +
> +/* -------- Additional API for SPAPR TCE (Server POWERPC) IOMMU -------- */
> +
> +/*
> + * The SPAPR TCE info struct provides the information about the PCI bus
> + * address ranges available for DMA, these values are programmed into
> + * the hardware so the guest has to know that information.
> + *
> + * The DMA 32 bit window start is an absolute PCI bus address.
> + * The IOVA address passed via map/unmap ioctls are absolute PCI bus
> + * addresses too so the window works as a filter rather than an offset
> + * for IOVA addresses.
> + *
> + * A flag will need to be added if other page sizes are supported,
> + * so as defined here, it is always 4k.
> + */
> +struct vfio_iommu_spapr_tce_info {
> +	__u32 argsz;
> +	__u32 flags;			/* reserved for future use */
> +	__u32 dma32_window_start;	/* 32 bit window start (bytes) */
> +	__u32 dma32_window_size;	/* 32 bit window size (bytes) */
> +};
> +
> +#define VFIO_IOMMU_SPAPR_TCE_GET_INFO	_IO(VFIO_TYPE, VFIO_BASE + 12)
> +
> +/* Reuse type1 map/unmap structs as they are the same at the moment */
> +typedef struct vfio_iommu_type1_dma_map vfio_iommu_spapr_tce_dma_map;
> +typedef struct vfio_iommu_type1_dma_unmap vfio_iommu_spapr_tce_dma_unmap;
> +
> +/* ***************************************************************** */
> +
>  #endif /* _UAPIVFIO_H */

Re: [PATCH] vfio powerpc: implement IOMMU driver for VFIO

[Alexey Kardashevskiy]

On 21/03/13 07:45, Alex Williamson wrote:
> On Tue, 2013-03-19 at 18:08 +1100, Alexey Kardashevskiy wrote:
>> VFIO implements platform independent stuff such as
>> a PCI driver, BAR access (via read/write on a file descriptor
>> or direct mapping when possible) and IRQ signaling.
>>
>> The platform dependent part includes IOMMU initialization
>> and handling. This patch implements an IOMMU driver for VFIO
>> which does mapping/unmapping pages for the guest IO and
>> provides information about DMA window (required by a POWERPC
>> guest).
>>
>> The counterpart in QEMU is required to support this functionality.
>>
>> Changelog:
>> * documentation updated
>> * containter enable/disable ioctls added
>> * request_module(spapr_iommu) added
>> * various locks fixed
>>
>> Cc: David Gibson <david@gibson.dropbear.id.au>
>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>> ---
>
>
> Looking pretty good.  There's one problem with the detach_group,
> otherwise just some trivial comments below.  What's the status of the
> tce code that this depends on?  Thanks,


It is done, I am just waiting till other patches of the series will be 
reviewed (by guys) and fixed (by me) and then I'll post everything again.

[skipped]

>> +static int tce_iommu_enable(struct tce_container *container)
>> +{
>> +	int ret = 0;
>> +	unsigned long locked, lock_limit, npages;
>> +	struct iommu_table *tbl = container->tbl;
>> +
>> +	if (!container->tbl)
>> +		return -ENXIO;
>> +
>> +	if (!current->mm)
>> +		return -ESRCH; /* process exited */
>> +
>> +	mutex_lock(&container->lock);
>> +	if (container->enabled) {
>> +		mutex_unlock(&container->lock);
>> +		return -EBUSY;
>> +	}
>> +
>> +	/*
>> +	 * Accounting for locked pages.
>> +	 *
>> +	 * On sPAPR platform, IOMMU translation table contains
>> +	 * an entry per 4K page. Every map/unmap request is sent
>> +	 * by the guest via hypercall and supposed to be handled
>> +	 * quickly, ecpesially in real mode (if such option is
>
> s/ecpesially/especially/


I replaced the whole text by the one written by Ben and David.

[skipped]

>> +	}
>> +
>> +	return -ENOTTY;
>> +}
>> +
>> +static int tce_iommu_attach_group(void *iommu_data,
>> +		struct iommu_group *iommu_group)
>> +{
>> +	int ret;
>> +	struct tce_container *container = iommu_data;
>> +	struct iommu_table *tbl = iommu_group_get_iommudata(iommu_group);
>> +
>> +	BUG_ON(!tbl);
>> +	mutex_lock(&container->lock);
>> +	pr_debug("tce_vfio: Attaching group #%u to iommu %p\n",
>> +			iommu_group_id(iommu_group), iommu_group);
>> +	if (container->tbl) {
>> +		pr_warn("tce_vfio: Only one group per IOMMU container is allowed, existing id=%d, attaching id=%d\n",
>> +				iommu_group_id(container->tbl->it_group),
>> +				iommu_group_id(iommu_group));
>> +		mutex_unlock(&container->lock);
>> +		return -EBUSY;
>> +	}
>> +
>> +	ret = iommu_take_ownership(tbl);
>> +	if (!ret)
>> +		container->tbl = tbl;
>> +
>> +	mutex_unlock(&container->lock);
>> +
>> +	return ret;
>> +}
>> +
>> +static void tce_iommu_detach_group(void *iommu_data,
>> +		struct iommu_group *iommu_group)
>> +{
>> +	struct tce_container *container = iommu_data;
>> +	struct iommu_table *tbl = iommu_group_get_iommudata(iommu_group);
>> +
>> +	BUG_ON(!tbl);
>> +	mutex_lock(&container->lock);
>> +	if (tbl != container->tbl) {
>> +		pr_warn("tce_vfio: detaching group #%u, expected group is #%u\n",
>> +				iommu_group_id(iommu_group),
>> +				iommu_group_id(tbl->it_group));
>> +	} else if (container->enabled) {
>> +		pr_err("tce_vfio: detaching group #%u from enabled container\n",
>> +				iommu_group_id(tbl->it_group));
>
> Hmm, something more than a pr_err needs to happen here.  Wouldn't this
> imply a disable and going back to an unprivileged container?

Ah. It does not return error code... Then something like that?

...
          } else if (container->enabled) {
                  pr_warn("tce_vfio: detaching group #%u from enabled 
container, forcing disable\n",
                                  iommu_group_id(tbl->it_group));
                  tce_iommu_disable(container);
...

-- 
Alexey

Re: [PATCH] vfio powerpc: implement IOMMU driver for VFIO

[Alex Williamson]

On Thu, 2013-03-21 at 11:57 +1100, Alexey Kardashevskiy wrote:
> On 21/03/13 07:45, Alex Williamson wrote:
> > On Tue, 2013-03-19 at 18:08 +1100, Alexey Kardashevskiy wrote:
> >> VFIO implements platform independent stuff such as
> >> a PCI driver, BAR access (via read/write on a file descriptor
> >> or direct mapping when possible) and IRQ signaling.
> >>
> >> The platform dependent part includes IOMMU initialization
> >> and handling. This patch implements an IOMMU driver for VFIO
> >> which does mapping/unmapping pages for the guest IO and
> >> provides information about DMA window (required by a POWERPC
> >> guest).
> >>
> >> The counterpart in QEMU is required to support this functionality.
> >>
> >> Changelog:
> >> * documentation updated
> >> * containter enable/disable ioctls added
> >> * request_module(spapr_iommu) added
> >> * various locks fixed
> >>
> >> Cc: David Gibson <david@gibson.dropbear.id.au>
> >> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> >> ---
> >
> >
> > Looking pretty good.  There's one problem with the detach_group,
> > otherwise just some trivial comments below.  What's the status of the
> > tce code that this depends on?  Thanks,
> 
> 
> It is done, I am just waiting till other patches of the series will be 
> reviewed (by guys) and fixed (by me) and then I'll post everything again.
> 
> [skipped]
> 
> >> +static int tce_iommu_enable(struct tce_container *container)
> >> +{
> >> +	int ret = 0;
> >> +	unsigned long locked, lock_limit, npages;
> >> +	struct iommu_table *tbl = container->tbl;
> >> +
> >> +	if (!container->tbl)
> >> +		return -ENXIO;
> >> +
> >> +	if (!current->mm)
> >> +		return -ESRCH; /* process exited */
> >> +
> >> +	mutex_lock(&container->lock);
> >> +	if (container->enabled) {
> >> +		mutex_unlock(&container->lock);
> >> +		return -EBUSY;
> >> +	}
> >> +
> >> +	/*
> >> +	 * Accounting for locked pages.
> >> +	 *
> >> +	 * On sPAPR platform, IOMMU translation table contains
> >> +	 * an entry per 4K page. Every map/unmap request is sent
> >> +	 * by the guest via hypercall and supposed to be handled
> >> +	 * quickly, ecpesially in real mode (if such option is
> >
> > s/ecpesially/especially/
> 
> 
> I replaced the whole text by the one written by Ben and David.
> 
> [skipped]
> 
> >> +	}
> >> +
> >> +	return -ENOTTY;
> >> +}
> >> +
> >> +static int tce_iommu_attach_group(void *iommu_data,
> >> +		struct iommu_group *iommu_group)
> >> +{
> >> +	int ret;
> >> +	struct tce_container *container = iommu_data;
> >> +	struct iommu_table *tbl = iommu_group_get_iommudata(iommu_group);
> >> +
> >> +	BUG_ON(!tbl);
> >> +	mutex_lock(&container->lock);
> >> +	pr_debug("tce_vfio: Attaching group #%u to iommu %p\n",
> >> +			iommu_group_id(iommu_group), iommu_group);
> >> +	if (container->tbl) {
> >> +		pr_warn("tce_vfio: Only one group per IOMMU container is allowed, existing id=%d, attaching id=%d\n",
> >> +				iommu_group_id(container->tbl->it_group),
> >> +				iommu_group_id(iommu_group));
> >> +		mutex_unlock(&container->lock);
> >> +		return -EBUSY;
> >> +	}
> >> +
> >> +	ret = iommu_take_ownership(tbl);
> >> +	if (!ret)
> >> +		container->tbl = tbl;
> >> +
> >> +	mutex_unlock(&container->lock);
> >> +
> >> +	return ret;
> >> +}
> >> +
> >> +static void tce_iommu_detach_group(void *iommu_data,
> >> +		struct iommu_group *iommu_group)
> >> +{
> >> +	struct tce_container *container = iommu_data;
> >> +	struct iommu_table *tbl = iommu_group_get_iommudata(iommu_group);
> >> +
> >> +	BUG_ON(!tbl);
> >> +	mutex_lock(&container->lock);
> >> +	if (tbl != container->tbl) {
> >> +		pr_warn("tce_vfio: detaching group #%u, expected group is #%u\n",
> >> +				iommu_group_id(iommu_group),
> >> +				iommu_group_id(tbl->it_group));
> >> +	} else if (container->enabled) {
> >> +		pr_err("tce_vfio: detaching group #%u from enabled container\n",
> >> +				iommu_group_id(tbl->it_group));
> >
> > Hmm, something more than a pr_err needs to happen here.  Wouldn't this
> > imply a disable and going back to an unprivileged container?
> 
> Ah. It does not return error code... Then something like that?
> 
> ...
>           } else if (container->enabled) {
>                   pr_warn("tce_vfio: detaching group #%u from enabled 
> container, forcing disable\n",
>                                   iommu_group_id(tbl->it_group));
>                   tce_iommu_disable(container);
> ...

Yep, but of course it also needs to fall through and set tbl = NULL and
release ownership as well.  BTW, don't you think the pr_debug in that
path is a little excessive?  Likewise the one in the attach path.
Thanks,

Alex

Re: [PATCH] vfio powerpc: implement IOMMU driver for VFIO

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 2527 bytes --]

On Wed, Mar 20, 2013 at 02:45:24PM -0600, Alex Williamson wrote:
> On Tue, 2013-03-19 at 18:08 +1100, Alexey Kardashevskiy wrote:
> > VFIO implements platform independent stuff such as
> > a PCI driver, BAR access (via read/write on a file descriptor
> > or direct mapping when possible) and IRQ signaling.
> > 
> > The platform dependent part includes IOMMU initialization
> > and handling. This patch implements an IOMMU driver for VFIO
> > which does mapping/unmapping pages for the guest IO and
> > provides information about DMA window (required by a POWERPC
> > guest).
> > 
> > The counterpart in QEMU is required to support this functionality.
> > 
> > Changelog:
> > * documentation updated
> > * containter enable/disable ioctls added
> > * request_module(spapr_iommu) added
> > * various locks fixed
> > 
> > Cc: David Gibson <david@gibson.dropbear.id.au>
> > Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> > ---
> 
> 
> Looking pretty good.  There's one problem with the detach_group,
> otherwise just some trivial comments below.  What's the status of the
> tce code that this depends on?  Thanks,

[snip]
> > +static void tce_iommu_detach_group(void *iommu_data,
> > +		struct iommu_group *iommu_group)
> > +{
> > +	struct tce_container *container = iommu_data;
> > +	struct iommu_table *tbl = iommu_group_get_iommudata(iommu_group);
> > +
> > +	BUG_ON(!tbl);
> > +	mutex_lock(&container->lock);
> > +	if (tbl != container->tbl) {
> > +		pr_warn("tce_vfio: detaching group #%u, expected group is #%u\n",
> > +				iommu_group_id(iommu_group),
> > +				iommu_group_id(tbl->it_group));
> > +	} else if (container->enabled) {
> > +		pr_err("tce_vfio: detaching group #%u from enabled container\n",
> > +				iommu_group_id(tbl->it_group));
> 
> Hmm, something more than a pr_err needs to happen here.  Wouldn't this
> imply a disable and going back to an unprivileged container?

Uh, no.  I think the idea here is that we use the enable/disable
semantic to address some other potential problems.  Specifically,
sidestepping the problems of what happens if you change the
container's capabilities by adding/removing groups while in the middle
of using it.  So the point is that the detach fails when the group is
enabled, rather than implicitly doing anything.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH] vfio powerpc: implement IOMMU driver for VFIO

[Alex Williamson]

On Thu, 2013-03-21 at 12:55 +1100, David Gibson wrote:
> On Wed, Mar 20, 2013 at 02:45:24PM -0600, Alex Williamson wrote:
> > On Tue, 2013-03-19 at 18:08 +1100, Alexey Kardashevskiy wrote:
> > > VFIO implements platform independent stuff such as
> > > a PCI driver, BAR access (via read/write on a file descriptor
> > > or direct mapping when possible) and IRQ signaling.
> > > 
> > > The platform dependent part includes IOMMU initialization
> > > and handling. This patch implements an IOMMU driver for VFIO
> > > which does mapping/unmapping pages for the guest IO and
> > > provides information about DMA window (required by a POWERPC
> > > guest).
> > > 
> > > The counterpart in QEMU is required to support this functionality.
> > > 
> > > Changelog:
> > > * documentation updated
> > > * containter enable/disable ioctls added
> > > * request_module(spapr_iommu) added
> > > * various locks fixed
> > > 
> > > Cc: David Gibson <david@gibson.dropbear.id.au>
> > > Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> > > ---
> > 
> > 
> > Looking pretty good.  There's one problem with the detach_group,
> > otherwise just some trivial comments below.  What's the status of the
> > tce code that this depends on?  Thanks,
> 
> [snip]
> > > +static void tce_iommu_detach_group(void *iommu_data,
> > > +		struct iommu_group *iommu_group)
> > > +{
> > > +	struct tce_container *container = iommu_data;
> > > +	struct iommu_table *tbl = iommu_group_get_iommudata(iommu_group);
> > > +
> > > +	BUG_ON(!tbl);
> > > +	mutex_lock(&container->lock);
> > > +	if (tbl != container->tbl) {
> > > +		pr_warn("tce_vfio: detaching group #%u, expected group is #%u\n",
> > > +				iommu_group_id(iommu_group),
> > > +				iommu_group_id(tbl->it_group));
> > > +	} else if (container->enabled) {
> > > +		pr_err("tce_vfio: detaching group #%u from enabled container\n",
> > > +				iommu_group_id(tbl->it_group));
> > 
> > Hmm, something more than a pr_err needs to happen here.  Wouldn't this
> > imply a disable and going back to an unprivileged container?
> 
> Uh, no.  I think the idea here is that we use the enable/disable
> semantic to address some other potential problems.  Specifically,
> sidestepping the problems of what happens if you change the
> container's capabilities by adding/removing groups while in the middle
> of using it.  So the point is that the detach fails when the group is
> enabled, rather than implicitly doing anything.

The function returns void.  We're not failing the detach, just getting
into a broken state.  This is only called to unwind attaching groups
when the iommu is set or if the user explicitly calls
GROUP_UNSET_CONTAINER.  The former won't have had a chance to call
enable but the latter would need to be fixed.  Thanks,

Alex

Re: [PATCH] vfio powerpc: implement IOMMU driver for VFIO

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 3326 bytes --]

On Wed, Mar 20, 2013 at 09:16:24PM -0600, Alex Williamson wrote:
> On Thu, 2013-03-21 at 12:55 +1100, David Gibson wrote:
> > On Wed, Mar 20, 2013 at 02:45:24PM -0600, Alex Williamson wrote:
> > > On Tue, 2013-03-19 at 18:08 +1100, Alexey Kardashevskiy wrote:
> > > > VFIO implements platform independent stuff such as
> > > > a PCI driver, BAR access (via read/write on a file descriptor
> > > > or direct mapping when possible) and IRQ signaling.
> > > > 
> > > > The platform dependent part includes IOMMU initialization
> > > > and handling. This patch implements an IOMMU driver for VFIO
> > > > which does mapping/unmapping pages for the guest IO and
> > > > provides information about DMA window (required by a POWERPC
> > > > guest).
> > > > 
> > > > The counterpart in QEMU is required to support this functionality.
> > > > 
> > > > Changelog:
> > > > * documentation updated
> > > > * containter enable/disable ioctls added
> > > > * request_module(spapr_iommu) added
> > > > * various locks fixed
> > > > 
> > > > Cc: David Gibson <david@gibson.dropbear.id.au>
> > > > Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> > > > ---
> > > 
> > > 
> > > Looking pretty good.  There's one problem with the detach_group,
> > > otherwise just some trivial comments below.  What's the status of the
> > > tce code that this depends on?  Thanks,
> > 
> > [snip]
> > > > +static void tce_iommu_detach_group(void *iommu_data,
> > > > +		struct iommu_group *iommu_group)
> > > > +{
> > > > +	struct tce_container *container = iommu_data;
> > > > +	struct iommu_table *tbl = iommu_group_get_iommudata(iommu_group);
> > > > +
> > > > +	BUG_ON(!tbl);
> > > > +	mutex_lock(&container->lock);
> > > > +	if (tbl != container->tbl) {
> > > > +		pr_warn("tce_vfio: detaching group #%u, expected group is #%u\n",
> > > > +				iommu_group_id(iommu_group),
> > > > +				iommu_group_id(tbl->it_group));
> > > > +	} else if (container->enabled) {
> > > > +		pr_err("tce_vfio: detaching group #%u from enabled container\n",
> > > > +				iommu_group_id(tbl->it_group));
> > > 
> > > Hmm, something more than a pr_err needs to happen here.  Wouldn't this
> > > imply a disable and going back to an unprivileged container?
> > 
> > Uh, no.  I think the idea here is that we use the enable/disable
> > semantic to address some other potential problems.  Specifically,
> > sidestepping the problems of what happens if you change the
> > container's capabilities by adding/removing groups while in the middle
> > of using it.  So the point is that the detach fails when the group is
> > enabled, rather than implicitly doing anything.
> 
> The function returns void.

Uh, yeah, we should probably fix that.

>  We're not failing the detach, just getting
> into a broken state.  This is only called to unwind attaching groups
> when the iommu is set or if the user explicitly calls
> GROUP_UNSET_CONTAINER.  The former won't have had a chance to call
> enable but the latter would need to be fixed.

Well, in the latter case it's essentialy a silent failure, which isn't
great.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]