* [PATCH 0/3] virtio-iommu on non-devicetree platforms
@ 2020-02-14 16:04 Jean-Philippe Brucker
2020-02-14 16:04 ` [PATCH 1/3] iommu/virtio: Add topology description to virtio-iommu config space Jean-Philippe Brucker
` (2 more replies)
0 siblings, 3 replies; 19+ messages in thread
From: Jean-Philippe Brucker @ 2020-02-14 16:04 UTC (permalink / raw)
To: iommu, virtualization, linux-pci
Cc: kevin.tian, mst, sebastien.boeuf, jacob.jun.pan, bhelgaas, jasowang
Add topology description to the virtio-iommu driver and enable x86
platforms. Since the RFC [1] I've mostly given up on ACPI tables, since
the internal discussions seem to have reached a dead end. The built-in
topology description presented here isn't ideal, but it is simple to
implement and doesn't impose a dependency on ACPI or device-tree, which
can be beneficial to lightweight hypervisors.
The built-in description is an array in the virtio config space. The
driver parses the config space early and postpones endpoint probe until
the virtio-iommu device is ready. Each element in the array describes
either a PCI range or a single MMIO endpoint, and their associated
endpoint IDs:
struct virtio_iommu_topo_pci_range {
__le16 type; /* 1: PCI range */
__le16 hierarchy; /* PCI domain number */
__le16 requester_start; /* First BDF */
__le16 requester_end; /* Last BDF */
__le32 endpoint_start; /* First endpoint ID */
};
struct virtio_iommu_topo_endpoint {
__le16 type; /* 2: Endpoint */
__le16 reserved; /* 0 */
__le32 endpoint; /* Endpoint ID */
__le64 address; /* First MMIO address */
};
You can find the QEMU patches based on Eric's latest device on my
virtio-iommu/devel branch [2]. I test on both x86 q35, and aarch64 virt
machine with edk2.
[1] https://lore.kernel.org/linux-iommu/20191122105000.800410-1-jean-philippe@linaro.org/
[2] https://jpbrucker.net/git/qemu virtio-iommu/devel
Jean-Philippe Brucker (3):
iommu/virtio: Add topology description to virtio-iommu config space
PCI: Add DMA configuration for virtual platforms
iommu/virtio: Enable x86 support
MAINTAINERS | 2 +
drivers/iommu/Kconfig | 13 +-
drivers/iommu/Makefile | 1 +
drivers/iommu/virtio-iommu-topology.c | 343 ++++++++++++++++++++++++++
drivers/iommu/virtio-iommu.c | 3 +
drivers/pci/pci-driver.c | 5 +
include/linux/virt_iommu.h | 19 ++
include/uapi/linux/virtio_iommu.h | 26 ++
8 files changed, 411 insertions(+), 1 deletion(-)
create mode 100644 drivers/iommu/virtio-iommu-topology.c
create mode 100644 include/linux/virt_iommu.h
--
2.25.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH 1/3] iommu/virtio: Add topology description to virtio-iommu config space
2020-02-14 16:04 [PATCH 0/3] virtio-iommu on non-devicetree platforms Jean-Philippe Brucker
@ 2020-02-14 16:04 ` Jean-Philippe Brucker
2020-02-14 16:04 ` [PATCH 2/3] PCI: Add DMA configuration for virtual platforms Jean-Philippe Brucker
2020-02-14 16:04 ` [PATCH 3/3] iommu/virtio: Enable x86 support Jean-Philippe Brucker
2 siblings, 0 replies; 19+ messages in thread
From: Jean-Philippe Brucker @ 2020-02-14 16:04 UTC (permalink / raw)
To: iommu, virtualization, linux-pci
Cc: kevin.tian, mst, sebastien.boeuf, jacob.jun.pan, bhelgaas, jasowang
Platforms without device-tree do not currently have a method for
describing the vIOMMU topology. Provide a topology description embedded
into the virtio device.
Use PCI FIXUP to probe the config space early, because we need to
discover the topology before any DMA configuration takes place, and the
virtio driver may be loaded much later. Since we discover the topology
description when probing the PCI hierarchy, the virtual IOMMU cannot
manage other platform devices discovered earlier.
This solution isn't elegant nor foolproof, but is the best we can do at
the moment and works with existing virtio-iommu implementations. It also
enables an IOMMU for lightweight hypervisors that do not rely on
firmware methods for booting.
Signed-off-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
---
MAINTAINERS | 2 +
drivers/iommu/Kconfig | 10 +
drivers/iommu/Makefile | 1 +
drivers/iommu/virtio-iommu-topology.c | 343 ++++++++++++++++++++++++++
drivers/iommu/virtio-iommu.c | 3 +
include/linux/virt_iommu.h | 19 ++
include/uapi/linux/virtio_iommu.h | 26 ++
7 files changed, 404 insertions(+)
create mode 100644 drivers/iommu/virtio-iommu-topology.c
create mode 100644 include/linux/virt_iommu.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 38fe2f3f7b6f..6b978b0d0c90 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17780,6 +17780,8 @@ M: Jean-Philippe Brucker <jean-philippe@linaro.org>
L: virtualization@lists.linux-foundation.org
S: Maintained
F: drivers/iommu/virtio-iommu.c
+F: drivers/iommu/virtio-iommu-topology.c
+F: include/linux/virt_iommu.h
F: include/uapi/linux/virtio_iommu.h
VIRTUAL BOX GUEST DEVICE DRIVER
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index d2fade984999..068d4e0e3541 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -516,4 +516,14 @@ config VIRTIO_IOMMU
Say Y here if you intend to run this kernel as a guest.
+config VIRTIO_IOMMU_TOPOLOGY
+ bool "Topology properties for the virtio-iommu"
+ depends on VIRTIO_IOMMU
+ default y
+ help
+ Enable early probing of the virtio-iommu device, to detect the
+ built-in topology description.
+
+ Say Y here if you intend to run this kernel as a guest.
+
endif # IOMMU_SUPPORT
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 2104fb8afc06..f295cacf9c6e 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -37,3 +37,4 @@ obj-$(CONFIG_S390_IOMMU) += s390-iommu.o
obj-$(CONFIG_QCOM_IOMMU) += qcom_iommu.o
obj-$(CONFIG_HYPERV_IOMMU) += hyperv-iommu.o
obj-$(CONFIG_VIRTIO_IOMMU) += virtio-iommu.o
+obj-$(CONFIG_VIRTIO_IOMMU_TOPOLOGY) += virtio-iommu-topology.o
diff --git a/drivers/iommu/virtio-iommu-topology.c b/drivers/iommu/virtio-iommu-topology.c
new file mode 100644
index 000000000000..e4ab49701df5
--- /dev/null
+++ b/drivers/iommu/virtio-iommu-topology.c
@@ -0,0 +1,343 @@
+// SPDX-License-Identifier: GPL-2.0
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/dma-iommu.h>
+#include <linux/list.h>
+#include <linux/pci.h>
+#include <linux/virt_iommu.h>
+#include <linux/virtio_ids.h>
+#include <linux/virtio_pci.h>
+#include <uapi/linux/virtio_iommu.h>
+
+struct viommu_cap_config {
+ u8 bar;
+ u32 length; /* structure size */
+ u32 offset; /* structure offset within the bar */
+};
+
+union viommu_topo_cfg {
+ __le16 type;
+ struct virtio_iommu_topo_pci_range pci;
+ struct virtio_iommu_topo_endpoint ep;
+};
+
+struct viommu_spec {
+ struct device *dev; /* transport device */
+ struct fwnode_handle *fwnode;
+ struct iommu_ops *ops;
+ struct list_head list;
+ size_t num_items;
+ /* The config array of length num_items follows */
+ union viommu_topo_cfg cfg[];
+};
+
+static LIST_HEAD(viommus);
+static DEFINE_MUTEX(viommus_lock);
+
+#define VPCI_FIELD(field) offsetof(struct virtio_pci_cap, field)
+
+static inline int viommu_pci_find_capability(struct pci_dev *dev, u8 cfg_type,
+ struct viommu_cap_config *cap)
+{
+ int pos;
+ u8 bar;
+
+ for (pos = pci_find_capability(dev, PCI_CAP_ID_VNDR);
+ pos > 0;
+ pos = pci_find_next_capability(dev, pos, PCI_CAP_ID_VNDR)) {
+ u8 type;
+
+ pci_read_config_byte(dev, pos + VPCI_FIELD(cfg_type), &type);
+ if (type != cfg_type)
+ continue;
+
+ pci_read_config_byte(dev, pos + VPCI_FIELD(bar), &bar);
+
+ /* Ignore structures with reserved BAR values */
+ if (type != VIRTIO_PCI_CAP_PCI_CFG && bar > 0x5)
+ continue;
+
+ cap->bar = bar;
+ pci_read_config_dword(dev, pos + VPCI_FIELD(length),
+ &cap->length);
+ pci_read_config_dword(dev, pos + VPCI_FIELD(offset),
+ &cap->offset);
+
+ return pos;
+ }
+ return 0;
+}
+
+static void viommu_ccopy(__le32 *dst, u32 __iomem *src, size_t length)
+{
+ size_t i;
+
+ /* For the moment all our config structures align on 32b */
+ if (WARN_ON(length % 4))
+ return;
+
+ for (i = 0; i < length / 4; i++)
+ /* Keep little-endian data */
+ dst[i] = cpu_to_le32(ioread32(src + i));
+}
+
+static int viommu_parse_topology(struct device *dev,
+ struct virtio_iommu_config __iomem *cfg)
+{
+ size_t i;
+ size_t spec_length;
+ struct viommu_spec *viommu_spec;
+ u32 offset, item_length, num_items;
+
+ offset = ioread32(&cfg->topo_config.offset);
+ item_length = ioread32(&cfg->topo_config.item_length);
+ num_items = ioread32(&cfg->topo_config.num_items);
+ if (!offset || !num_items || !item_length)
+ return 0;
+
+ spec_length = sizeof(*viommu_spec) + num_items *
+ sizeof(union viommu_topo_cfg);
+ viommu_spec = kzalloc(spec_length, GFP_KERNEL);
+ if (!viommu_spec)
+ return -ENOMEM;
+
+ viommu_spec->dev = dev;
+
+ /* Copy in the whole array, sort it out later */
+ for (i = 0; i < num_items; i++) {
+ size_t read_length = min_t(size_t, item_length,
+ sizeof(union viommu_topo_cfg));
+
+ viommu_ccopy((__le32 *)&viommu_spec->cfg[i],
+ (void __iomem *)cfg + offset,
+ read_length);
+
+ offset += item_length;
+ }
+ viommu_spec->num_items = num_items;
+
+ mutex_lock(&viommus_lock);
+ list_add(&viommu_spec->list, &viommus);
+ mutex_unlock(&viommus_lock);
+
+ return 0;
+}
+
+static void viommu_pci_parse_topology(struct pci_dev *dev)
+{
+ int pos;
+ u32 features;
+ void __iomem *regs;
+ struct viommu_cap_config cap = {0};
+ struct virtio_pci_common_cfg __iomem *common_cfg;
+
+ /*
+ * The virtio infrastructure might not be loaded at this point. we need
+ * to access the BARs ourselves.
+ */
+ pos = viommu_pci_find_capability(dev, VIRTIO_PCI_CAP_COMMON_CFG, &cap);
+ if (!pos) {
+ pci_warn(dev, "common capability not found\n");
+ return;
+ }
+
+ if (pci_enable_device_mem(dev))
+ return;
+
+ regs = pci_iomap(dev, cap.bar, 0);
+ if (!regs)
+ return;
+
+ common_cfg = regs + cap.offset;
+
+ /* Find out if the device supports topology description */
+ writel(0, &common_cfg->device_feature_select);
+ features = ioread32(&common_cfg->device_feature);
+
+ pci_iounmap(dev, regs);
+
+ if (!(features & BIT(VIRTIO_IOMMU_F_TOPOLOGY))) {
+ pci_dbg(dev, "device doesn't have topology description");
+ return;
+ }
+
+ pos = viommu_pci_find_capability(dev, VIRTIO_PCI_CAP_DEVICE_CFG, &cap);
+ if (!pos) {
+ pci_warn(dev, "device config capability not found\n");
+ return;
+ }
+
+ regs = pci_iomap(dev, cap.bar, 0);
+ if (!regs)
+ return;
+
+ pci_info(dev, "parsing virtio-iommu topology\n");
+ viommu_parse_topology(&dev->dev, regs + cap.offset);
+ pci_iounmap(dev, regs);
+}
+
+/*
+ * Catch a PCI virtio-iommu implementation early to get the topology description
+ * before we start probing other endpoints.
+ */
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_REDHAT_QUMRANET, 0x1040 + VIRTIO_ID_IOMMU,
+ viommu_pci_parse_topology);
+
+/*
+ * Return true if the device matches this topology structure. Write the endpoint
+ * ID into epid if it's the case.
+ */
+static bool viommu_parse_pci(struct pci_dev *pdev, union viommu_topo_cfg *cfg,
+ u32 *epid)
+{
+ u32 endpoint_start;
+ u16 start, end, domain;
+ u16 devid = pci_dev_id(pdev);
+ u16 type = le16_to_cpu(cfg->type);
+
+ if (type != VIRTIO_IOMMU_TOPO_PCI_RANGE)
+ return false;
+
+ start = le16_to_cpu(cfg->pci.requester_start);
+ end = le16_to_cpu(cfg->pci.requester_end);
+ domain = le16_to_cpu(cfg->pci.hierarchy);
+ endpoint_start = le32_to_cpu(cfg->pci.endpoint_start);
+
+ if (pci_domain_nr(pdev->bus) == domain &&
+ devid >= start && devid <= end) {
+ *epid = devid - start + endpoint_start;
+ return true;
+ }
+ return false;
+}
+
+static const struct iommu_ops *virt_iommu_setup(struct device *dev)
+{
+ struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+ const struct iommu_ops *viommu_ops = NULL;
+ struct fwnode_handle *viommu_fwnode;
+ struct viommu_spec *viommu_spec;
+ struct pci_dev *pci_dev = NULL;
+ struct device *viommu_dev;
+ bool found = false;
+ size_t i;
+ u32 epid;
+ int ret;
+
+ /* Already translated? */
+ if (fwspec && fwspec->ops)
+ return fwspec->ops;
+
+ if (dev_is_pci(dev)) {
+ pci_dev = to_pci_dev(dev);
+ } else {
+ /* At the moment we don't support platform devices */
+ return NULL;
+ }
+
+ mutex_lock(&viommus_lock);
+ list_for_each_entry(viommu_spec, &viommus, list) {
+ for (i = 0; i < viommu_spec->num_items; i++) {
+ union viommu_topo_cfg *cfg = &viommu_spec->cfg[i];
+
+ found = viommu_parse_pci(pci_dev, cfg, &epid);
+ if (found)
+ break;
+ }
+ if (found) {
+ viommu_ops = viommu_spec->ops;
+ viommu_fwnode = viommu_spec->fwnode;
+ viommu_dev = viommu_spec->dev;
+ break;
+ }
+ }
+ mutex_unlock(&viommus_lock);
+ if (!found)
+ return NULL;
+
+ /* We're not translating ourselves. */
+ if (viommu_dev == dev)
+ return NULL;
+
+ /*
+ * If we found a PCI range managed by the viommu, we're the ones that
+ * have to request ACS.
+ */
+ if (pci_dev)
+ pci_request_acs();
+
+ if (!viommu_ops)
+ return ERR_PTR(-EPROBE_DEFER);
+
+ ret = iommu_fwspec_init(dev, viommu_fwnode, viommu_ops);
+ if (ret)
+ return ERR_PTR(ret);
+
+ iommu_fwspec_add_ids(dev, &epid, 1);
+
+ return viommu_ops;
+}
+
+/**
+ * virt_dma_configure - Configure DMA of virtualized devices
+ * @dev: the endpoint
+ *
+ * Setup the DMA and IOMMU ops of a virtual device, for platforms without DT or
+ * ACPI.
+ *
+ * Return: -EPROBE_DEFER if the device is managed by an IOMMU that hasn't been
+ * probed yet, 0 otherwise
+ */
+int virt_dma_configure(struct device *dev)
+{
+ const struct iommu_ops *iommu_ops;
+
+ iommu_ops = virt_iommu_setup(dev);
+ if (IS_ERR_OR_NULL(iommu_ops)) {
+ int ret = PTR_ERR(iommu_ops);
+
+ if (ret == -EPROBE_DEFER || ret == 0)
+ return ret;
+ dev_err(dev, "error %d while setting up virt IOMMU\n", ret);
+ return 0;
+ }
+
+ /*
+ * If we have reason to believe the IOMMU driver missed the initial
+ * add_device callback for dev, replay it to get things in order.
+ */
+ if (dev->bus && !device_iommu_mapped(dev))
+ iommu_probe_device(dev);
+
+ /* Assume coherent, as well as full 64-bit addresses. */
+#ifdef CONFIG_ARCH_HAS_SETUP_DMA_OPS
+ arch_setup_dma_ops(dev, 0, ~0ULL, iommu_ops, true);
+#else
+ iommu_setup_dma_ops(dev, 0, ~0ULL);
+#endif
+ return 0;
+}
+
+/**
+ * virt_set_iommu_ops - Set the IOMMU ops of a virtual IOMMU device
+ * @dev: the IOMMU device (transport)
+ * @ops: the new IOMMU ops or NULL
+ *
+ * Setup the iommu_ops associated to a viommu_spec, once the driver is loaded
+ * and the device probed.
+ */
+void virt_set_iommu_ops(struct device *dev, struct iommu_ops *ops)
+{
+ struct viommu_spec *viommu_spec;
+
+ mutex_lock(&viommus_lock);
+ list_for_each_entry(viommu_spec, &viommus, list) {
+ if (viommu_spec->dev == dev) {
+ viommu_spec->ops = ops;
+ viommu_spec->fwnode = ops ? dev->fwnode : NULL;
+ break;
+ }
+ }
+ mutex_unlock(&viommus_lock);
+}
+EXPORT_SYMBOL_GPL(virt_set_iommu_ops);
diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index cce329d71fba..f18ba8e22ebd 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
@@ -21,6 +21,7 @@
#include <linux/virtio.h>
#include <linux/virtio_config.h>
#include <linux/virtio_ids.h>
+#include <linux/virt_iommu.h>
#include <linux/wait.h>
#include <uapi/linux/virtio_iommu.h>
@@ -1075,6 +1076,7 @@ static int viommu_probe(struct virtio_device *vdev)
if (ret)
goto err_free_vqs;
+ virt_set_iommu_ops(dev->parent, &viommu_ops);
iommu_device_set_ops(&viommu->iommu, &viommu_ops);
iommu_device_set_fwnode(&viommu->iommu, parent_dev->fwnode);
@@ -1122,6 +1124,7 @@ static void viommu_remove(struct virtio_device *vdev)
{
struct viommu_dev *viommu = vdev->priv;
+ virt_set_iommu_ops(vdev->dev.parent, NULL);
iommu_device_sysfs_remove(&viommu->iommu);
iommu_device_unregister(&viommu->iommu);
diff --git a/include/linux/virt_iommu.h b/include/linux/virt_iommu.h
new file mode 100644
index 000000000000..c68b03ec75ba
--- /dev/null
+++ b/include/linux/virt_iommu.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef VIRTIO_IOMMU_H_
+#define VIRTIO_IOMMU_H_
+
+#if IS_ENABLED(CONFIG_VIRTIO_IOMMU_TOPOLOGY)
+int virt_dma_configure(struct device *dev);
+void virt_set_iommu_ops(struct device *dev, struct iommu_ops *ops);
+#else /* !CONFIG_VIRTIO_IOMMU_TOPOLOGY */
+static inline int virt_dma_configure(struct device *dev)
+{
+ /* Don't disturb the normal DMA configuration methods */
+ return 0;
+}
+
+static inline void virt_set_iommu_ops(struct device *dev, struct iommu_ops *ops)
+{ }
+#endif /* !CONFIG_VIRTIO_IOMMU_TOPOLOGY */
+
+#endif /* VIRTIO_IOMMU_H_ */
diff --git a/include/uapi/linux/virtio_iommu.h b/include/uapi/linux/virtio_iommu.h
index 237e36a280cb..ec57d215086a 100644
--- a/include/uapi/linux/virtio_iommu.h
+++ b/include/uapi/linux/virtio_iommu.h
@@ -16,6 +16,7 @@
#define VIRTIO_IOMMU_F_BYPASS 3
#define VIRTIO_IOMMU_F_PROBE 4
#define VIRTIO_IOMMU_F_MMIO 5
+#define VIRTIO_IOMMU_F_TOPOLOGY 6
struct virtio_iommu_range_64 {
__le64 start;
@@ -27,6 +28,12 @@ struct virtio_iommu_range_32 {
__le32 end;
};
+struct virtio_iommu_topo_config {
+ __le32 offset;
+ __le32 num_items;
+ __le32 item_length;
+};
+
struct virtio_iommu_config {
/* Supported page sizes */
__le64 page_size_mask;
@@ -36,6 +43,25 @@ struct virtio_iommu_config {
struct virtio_iommu_range_32 domain_range;
/* Probe buffer size */
__le32 probe_size;
+ struct virtio_iommu_topo_config topo_config;
+};
+
+#define VIRTIO_IOMMU_TOPO_PCI_RANGE 0x1
+#define VIRTIO_IOMMU_TOPO_ENDPOINT 0x2
+
+struct virtio_iommu_topo_pci_range {
+ __le16 type;
+ __le16 hierarchy;
+ __le16 requester_start;
+ __le16 requester_end;
+ __le32 endpoint_start;
+};
+
+struct virtio_iommu_topo_endpoint {
+ __le16 type;
+ __le16 reserved;
+ __le32 endpoint;
+ __le64 address;
};
/* Request types */
--
2.25.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 19+ messages in thread
* [PATCH 2/3] PCI: Add DMA configuration for virtual platforms
2020-02-14 16:04 [PATCH 0/3] virtio-iommu on non-devicetree platforms Jean-Philippe Brucker
2020-02-14 16:04 ` [PATCH 1/3] iommu/virtio: Add topology description to virtio-iommu config space Jean-Philippe Brucker
@ 2020-02-14 16:04 ` Jean-Philippe Brucker
2020-02-14 17:03 ` Robin Murphy
2020-02-14 16:04 ` [PATCH 3/3] iommu/virtio: Enable x86 support Jean-Philippe Brucker
2 siblings, 1 reply; 19+ messages in thread
From: Jean-Philippe Brucker @ 2020-02-14 16:04 UTC (permalink / raw)
To: iommu, virtualization, linux-pci
Cc: kevin.tian, mst, sebastien.boeuf, jacob.jun.pan, bhelgaas, jasowang
Hardware platforms usually describe the IOMMU topology using either
device-tree pointers or vendor-specific ACPI tables. For virtual
platforms that don't provide a device-tree, the virtio-iommu device
contains a description of the endpoints it manages. That information
allows us to probe endpoints after the IOMMU is probed (possibly as late
as userspace modprobe), provided it is discovered early enough.
Add a hook to pci_dma_configure(), which returns -EPROBE_DEFER if the
endpoint is managed by a vIOMMU that will be loaded later, or 0 in any
other case to avoid disturbing the normal DMA configuration methods.
When CONFIG_VIRTIO_IOMMU_TOPOLOGY isn't selected, the call to
virt_dma_configure() is compiled out.
As long as the information is consistent, platforms can provide both a
device-tree and a built-in topology, and the IOMMU infrastructure is
able to deal with multiple DMA configuration methods.
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
---
drivers/pci/pci-driver.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index 0454ca0e4e3f..69303a814f21 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -18,6 +18,7 @@
#include <linux/kexec.h>
#include <linux/of_device.h>
#include <linux/acpi.h>
+#include <linux/virt_iommu.h>
#include "pci.h"
#include "pcie/portdrv.h"
@@ -1602,6 +1603,10 @@ static int pci_dma_configure(struct device *dev)
struct device *bridge;
int ret = 0;
+ ret = virt_dma_configure(dev);
+ if (ret)
+ return ret;
+
bridge = pci_get_host_bridge_device(to_pci_dev(dev));
if (IS_ENABLED(CONFIG_OF) && bridge->parent &&
--
2.25.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 19+ messages in thread
* [PATCH 3/3] iommu/virtio: Enable x86 support
2020-02-14 16:04 [PATCH 0/3] virtio-iommu on non-devicetree platforms Jean-Philippe Brucker
2020-02-14 16:04 ` [PATCH 1/3] iommu/virtio: Add topology description to virtio-iommu config space Jean-Philippe Brucker
2020-02-14 16:04 ` [PATCH 2/3] PCI: Add DMA configuration for virtual platforms Jean-Philippe Brucker
@ 2020-02-14 16:04 ` Jean-Philippe Brucker
2020-02-14 16:57 ` Robin Murphy
2 siblings, 1 reply; 19+ messages in thread
From: Jean-Philippe Brucker @ 2020-02-14 16:04 UTC (permalink / raw)
To: iommu, virtualization, linux-pci
Cc: kevin.tian, mst, sebastien.boeuf, jacob.jun.pan, bhelgaas, jasowang
With the built-in topology description in place, x86 platforms can now
use the virtio-iommu.
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
---
drivers/iommu/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 068d4e0e3541..adcbda44d473 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -508,8 +508,9 @@ config HYPERV_IOMMU
config VIRTIO_IOMMU
bool "Virtio IOMMU driver"
depends on VIRTIO=y
- depends on ARM64
+ depends on (ARM64 || X86)
select IOMMU_API
+ select IOMMU_DMA
select INTERVAL_TREE
help
Para-virtualised IOMMU driver with virtio.
--
2.25.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] iommu/virtio: Enable x86 support
2020-02-14 16:04 ` [PATCH 3/3] iommu/virtio: Enable x86 support Jean-Philippe Brucker
@ 2020-02-14 16:57 ` Robin Murphy
2020-02-16 9:50 ` Michael S. Tsirkin
0 siblings, 1 reply; 19+ messages in thread
From: Robin Murphy @ 2020-02-14 16:57 UTC (permalink / raw)
To: Jean-Philippe Brucker, iommu, virtualization, linux-pci
Cc: kevin.tian, mst, jasowang, sebastien.boeuf, jacob.jun.pan, bhelgaas
On 14/02/2020 4:04 pm, Jean-Philippe Brucker wrote:
> With the built-in topology description in place, x86 platforms can now
> use the virtio-iommu.
>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> ---
> drivers/iommu/Kconfig | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index 068d4e0e3541..adcbda44d473 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -508,8 +508,9 @@ config HYPERV_IOMMU
> config VIRTIO_IOMMU
> bool "Virtio IOMMU driver"
> depends on VIRTIO=y
> - depends on ARM64
> + depends on (ARM64 || X86)
> select IOMMU_API
> + select IOMMU_DMA
Can that have an "if X86" for clarity? AIUI it's not necessary for
virtio-iommu itself (and really shouldn't be), but is merely to satisfy
the x86 arch code's expectation that IOMMU drivers bring their own DMA
ops, right?
Robin.
> select INTERVAL_TREE
> help
> Para-virtualised IOMMU driver with virtio.
>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 2/3] PCI: Add DMA configuration for virtual platforms
2020-02-14 16:04 ` [PATCH 2/3] PCI: Add DMA configuration for virtual platforms Jean-Philippe Brucker
@ 2020-02-14 17:03 ` Robin Murphy
2020-02-17 9:12 ` Jean-Philippe Brucker
0 siblings, 1 reply; 19+ messages in thread
From: Robin Murphy @ 2020-02-14 17:03 UTC (permalink / raw)
To: Jean-Philippe Brucker, iommu, virtualization, linux-pci
Cc: kevin.tian, mst, jasowang, sebastien.boeuf, jacob.jun.pan, bhelgaas
On 14/02/2020 4:04 pm, Jean-Philippe Brucker wrote:
> Hardware platforms usually describe the IOMMU topology using either
> device-tree pointers or vendor-specific ACPI tables. For virtual
> platforms that don't provide a device-tree, the virtio-iommu device
> contains a description of the endpoints it manages. That information
> allows us to probe endpoints after the IOMMU is probed (possibly as late
> as userspace modprobe), provided it is discovered early enough.
>
> Add a hook to pci_dma_configure(), which returns -EPROBE_DEFER if the
> endpoint is managed by a vIOMMU that will be loaded later, or 0 in any
> other case to avoid disturbing the normal DMA configuration methods.
> When CONFIG_VIRTIO_IOMMU_TOPOLOGY isn't selected, the call to
> virt_dma_configure() is compiled out.
>
> As long as the information is consistent, platforms can provide both a
> device-tree and a built-in topology, and the IOMMU infrastructure is
> able to deal with multiple DMA configuration methods.
Urgh, it's already been established[1] that having IOMMU setup tied to
DMA configuration at driver probe time is not just conceptually wrong
but actually broken, so the concept here worries me a bit. In a world
where of_iommu_configure() and friends are being called much earlier
around iommu_probe_device() time, how badly will this fall apart?
Robin.
[1]
https://lore.kernel.org/linux-iommu/9625faf4-48ef-2dd3-d82f-931d9cf26976@huawei.com/
> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> ---
> drivers/pci/pci-driver.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
> index 0454ca0e4e3f..69303a814f21 100644
> --- a/drivers/pci/pci-driver.c
> +++ b/drivers/pci/pci-driver.c
> @@ -18,6 +18,7 @@
> #include <linux/kexec.h>
> #include <linux/of_device.h>
> #include <linux/acpi.h>
> +#include <linux/virt_iommu.h>
> #include "pci.h"
> #include "pcie/portdrv.h"
>
> @@ -1602,6 +1603,10 @@ static int pci_dma_configure(struct device *dev)
> struct device *bridge;
> int ret = 0;
>
> + ret = virt_dma_configure(dev);
> + if (ret)
> + return ret;
> +
> bridge = pci_get_host_bridge_device(to_pci_dev(dev));
>
> if (IS_ENABLED(CONFIG_OF) && bridge->parent &&
>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] iommu/virtio: Enable x86 support
2020-02-14 16:57 ` Robin Murphy
@ 2020-02-16 9:50 ` Michael S. Tsirkin
2020-02-17 9:01 ` Jean-Philippe Brucker
0 siblings, 1 reply; 19+ messages in thread
From: Michael S. Tsirkin @ 2020-02-16 9:50 UTC (permalink / raw)
To: Robin Murphy
Cc: Jean-Philippe Brucker, kevin.tian, linux-pci, jasowang,
virtualization, iommu, sebastien.boeuf, jacob.jun.pan, bhelgaas
On Fri, Feb 14, 2020 at 04:57:11PM +0000, Robin Murphy wrote:
> On 14/02/2020 4:04 pm, Jean-Philippe Brucker wrote:
> > With the built-in topology description in place, x86 platforms can now
> > use the virtio-iommu.
> >
> > Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> > ---
> > drivers/iommu/Kconfig | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> > index 068d4e0e3541..adcbda44d473 100644
> > --- a/drivers/iommu/Kconfig
> > +++ b/drivers/iommu/Kconfig
> > @@ -508,8 +508,9 @@ config HYPERV_IOMMU
> > config VIRTIO_IOMMU
> > bool "Virtio IOMMU driver"
> > depends on VIRTIO=y
> > - depends on ARM64
> > + depends on (ARM64 || X86)
> > select IOMMU_API
> > + select IOMMU_DMA
>
> Can that have an "if X86" for clarity? AIUI it's not necessary for
> virtio-iommu itself (and really shouldn't be), but is merely to satisfy the
> x86 arch code's expectation that IOMMU drivers bring their own DMA ops,
> right?
>
> Robin.
In fact does not this work on any platform now?
> > select INTERVAL_TREE
> > help
> > Para-virtualised IOMMU driver with virtio.
> >
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] iommu/virtio: Enable x86 support
2020-02-16 9:50 ` Michael S. Tsirkin
@ 2020-02-17 9:01 ` Jean-Philippe Brucker
2020-02-17 13:01 ` Michael S. Tsirkin
0 siblings, 1 reply; 19+ messages in thread
From: Jean-Philippe Brucker @ 2020-02-17 9:01 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: kevin.tian, linux-pci, jasowang, virtualization, iommu,
sebastien.boeuf, jacob.jun.pan, bhelgaas, Robin Murphy
On Sun, Feb 16, 2020 at 04:50:33AM -0500, Michael S. Tsirkin wrote:
> On Fri, Feb 14, 2020 at 04:57:11PM +0000, Robin Murphy wrote:
> > On 14/02/2020 4:04 pm, Jean-Philippe Brucker wrote:
> > > With the built-in topology description in place, x86 platforms can now
> > > use the virtio-iommu.
> > >
> > > Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> > > ---
> > > drivers/iommu/Kconfig | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> > > index 068d4e0e3541..adcbda44d473 100644
> > > --- a/drivers/iommu/Kconfig
> > > +++ b/drivers/iommu/Kconfig
> > > @@ -508,8 +508,9 @@ config HYPERV_IOMMU
> > > config VIRTIO_IOMMU
> > > bool "Virtio IOMMU driver"
> > > depends on VIRTIO=y
> > > - depends on ARM64
> > > + depends on (ARM64 || X86)
> > > select IOMMU_API
> > > + select IOMMU_DMA
> >
> > Can that have an "if X86" for clarity? AIUI it's not necessary for
> > virtio-iommu itself (and really shouldn't be), but is merely to satisfy the
> > x86 arch code's expectation that IOMMU drivers bring their own DMA ops,
> > right?
> >
> > Robin.
>
> In fact does not this work on any platform now?
There is ongoing work to use the generic IOMMU_DMA ops on X86. AMD IOMMU
has been converted recently [1] but VT-d still implements its own DMA ops
(conversion patches are on the list [2]). On Arm the arch Kconfig selects
IOMMU_DMA, and I assume we'll have the same on X86 once Tom's work is
complete. Until then I can add a "if X86" here for clarity.
Thanks,
Jean
[1] https://lore.kernel.org/linux-iommu/20190613223901.9523-1-murphyt7@tcd.ie/
[2] https://lore.kernel.org/linux-iommu/20191221150402.13868-1-murphyt7@tcd.ie/
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 2/3] PCI: Add DMA configuration for virtual platforms
2020-02-14 17:03 ` Robin Murphy
@ 2020-02-17 9:12 ` Jean-Philippe Brucker
0 siblings, 0 replies; 19+ messages in thread
From: Jean-Philippe Brucker @ 2020-02-17 9:12 UTC (permalink / raw)
To: Robin Murphy
Cc: kevin.tian, mst, linux-pci, jasowang, virtualization, iommu,
sebastien.boeuf, jacob.jun.pan, bhelgaas
On Fri, Feb 14, 2020 at 05:03:16PM +0000, Robin Murphy wrote:
> On 14/02/2020 4:04 pm, Jean-Philippe Brucker wrote:
> > Hardware platforms usually describe the IOMMU topology using either
> > device-tree pointers or vendor-specific ACPI tables. For virtual
> > platforms that don't provide a device-tree, the virtio-iommu device
> > contains a description of the endpoints it manages. That information
> > allows us to probe endpoints after the IOMMU is probed (possibly as late
> > as userspace modprobe), provided it is discovered early enough.
> >
> > Add a hook to pci_dma_configure(), which returns -EPROBE_DEFER if the
> > endpoint is managed by a vIOMMU that will be loaded later, or 0 in any
> > other case to avoid disturbing the normal DMA configuration methods.
> > When CONFIG_VIRTIO_IOMMU_TOPOLOGY isn't selected, the call to
> > virt_dma_configure() is compiled out.
> >
> > As long as the information is consistent, platforms can provide both a
> > device-tree and a built-in topology, and the IOMMU infrastructure is
> > able to deal with multiple DMA configuration methods.
>
> Urgh, it's already been established[1] that having IOMMU setup tied to DMA
> configuration at driver probe time is not just conceptually wrong but
> actually broken, so the concept here worries me a bit. In a world where
> of_iommu_configure() and friends are being called much earlier around
> iommu_probe_device() time, how badly will this fall apart?
If present the DT configuration should take precedence over this built-in
method, so the earlier it is called the better. virt_dma_configure()
currently gives up if the device already has iommu_ops (well, still calls
setup_dma_ops() which is safe enough, but I think I'll change that to have
virt_iommu_setup() return NULL if iommu_ops are present).
I don't have the full picture of the changes you intend for
{of,acpi}_iommu_configure(), do you think checking the validity of
dev->iommu_fwspec will remain sufficient to have both methods coexist?
Thanks,
Jean
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] iommu/virtio: Enable x86 support
2020-02-17 9:01 ` Jean-Philippe Brucker
@ 2020-02-17 13:01 ` Michael S. Tsirkin
2020-02-17 13:22 ` Robin Murphy
0 siblings, 1 reply; 19+ messages in thread
From: Michael S. Tsirkin @ 2020-02-17 13:01 UTC (permalink / raw)
To: Jean-Philippe Brucker
Cc: kevin.tian, linux-pci, jasowang, virtualization, iommu,
sebastien.boeuf, jacob.jun.pan, bhelgaas, Robin Murphy
On Mon, Feb 17, 2020 at 10:01:07AM +0100, Jean-Philippe Brucker wrote:
> On Sun, Feb 16, 2020 at 04:50:33AM -0500, Michael S. Tsirkin wrote:
> > On Fri, Feb 14, 2020 at 04:57:11PM +0000, Robin Murphy wrote:
> > > On 14/02/2020 4:04 pm, Jean-Philippe Brucker wrote:
> > > > With the built-in topology description in place, x86 platforms can now
> > > > use the virtio-iommu.
> > > >
> > > > Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> > > > ---
> > > > drivers/iommu/Kconfig | 3 ++-
> > > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> > > > index 068d4e0e3541..adcbda44d473 100644
> > > > --- a/drivers/iommu/Kconfig
> > > > +++ b/drivers/iommu/Kconfig
> > > > @@ -508,8 +508,9 @@ config HYPERV_IOMMU
> > > > config VIRTIO_IOMMU
> > > > bool "Virtio IOMMU driver"
> > > > depends on VIRTIO=y
> > > > - depends on ARM64
> > > > + depends on (ARM64 || X86)
> > > > select IOMMU_API
> > > > + select IOMMU_DMA
> > >
> > > Can that have an "if X86" for clarity? AIUI it's not necessary for
> > > virtio-iommu itself (and really shouldn't be), but is merely to satisfy the
> > > x86 arch code's expectation that IOMMU drivers bring their own DMA ops,
> > > right?
> > >
> > > Robin.
> >
> > In fact does not this work on any platform now?
>
> There is ongoing work to use the generic IOMMU_DMA ops on X86. AMD IOMMU
> has been converted recently [1] but VT-d still implements its own DMA ops
> (conversion patches are on the list [2]). On Arm the arch Kconfig selects
> IOMMU_DMA, and I assume we'll have the same on X86 once Tom's work is
> complete. Until then I can add a "if X86" here for clarity.
>
> Thanks,
> Jean
>
> [1] https://lore.kernel.org/linux-iommu/20190613223901.9523-1-murphyt7@tcd.ie/
> [2] https://lore.kernel.org/linux-iommu/20191221150402.13868-1-murphyt7@tcd.ie/
What about others? E.g. PPC?
--
MST
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] iommu/virtio: Enable x86 support
2020-02-17 13:01 ` Michael S. Tsirkin
@ 2020-02-17 13:22 ` Robin Murphy
2020-02-17 13:31 ` Michael S. Tsirkin
0 siblings, 1 reply; 19+ messages in thread
From: Robin Murphy @ 2020-02-17 13:22 UTC (permalink / raw)
To: Michael S. Tsirkin, Jean-Philippe Brucker
Cc: kevin.tian, linux-pci, jasowang, virtualization, iommu,
sebastien.boeuf, jacob.jun.pan, bhelgaas
On 17/02/2020 1:01 pm, Michael S. Tsirkin wrote:
> On Mon, Feb 17, 2020 at 10:01:07AM +0100, Jean-Philippe Brucker wrote:
>> On Sun, Feb 16, 2020 at 04:50:33AM -0500, Michael S. Tsirkin wrote:
>>> On Fri, Feb 14, 2020 at 04:57:11PM +0000, Robin Murphy wrote:
>>>> On 14/02/2020 4:04 pm, Jean-Philippe Brucker wrote:
>>>>> With the built-in topology description in place, x86 platforms can now
>>>>> use the virtio-iommu.
>>>>>
>>>>> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
>>>>> ---
>>>>> drivers/iommu/Kconfig | 3 ++-
>>>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
>>>>> index 068d4e0e3541..adcbda44d473 100644
>>>>> --- a/drivers/iommu/Kconfig
>>>>> +++ b/drivers/iommu/Kconfig
>>>>> @@ -508,8 +508,9 @@ config HYPERV_IOMMU
>>>>> config VIRTIO_IOMMU
>>>>> bool "Virtio IOMMU driver"
>>>>> depends on VIRTIO=y
>>>>> - depends on ARM64
>>>>> + depends on (ARM64 || X86)
>>>>> select IOMMU_API
>>>>> + select IOMMU_DMA
>>>>
>>>> Can that have an "if X86" for clarity? AIUI it's not necessary for
>>>> virtio-iommu itself (and really shouldn't be), but is merely to satisfy the
>>>> x86 arch code's expectation that IOMMU drivers bring their own DMA ops,
>>>> right?
>>>>
>>>> Robin.
>>>
>>> In fact does not this work on any platform now?
>>
>> There is ongoing work to use the generic IOMMU_DMA ops on X86. AMD IOMMU
>> has been converted recently [1] but VT-d still implements its own DMA ops
>> (conversion patches are on the list [2]). On Arm the arch Kconfig selects
>> IOMMU_DMA, and I assume we'll have the same on X86 once Tom's work is
>> complete. Until then I can add a "if X86" here for clarity.
>>
>> Thanks,
>> Jean
>>
>> [1] https://lore.kernel.org/linux-iommu/20190613223901.9523-1-murphyt7@tcd.ie/
>> [2] https://lore.kernel.org/linux-iommu/20191221150402.13868-1-murphyt7@tcd.ie/
>
> What about others? E.g. PPC?
That was the point I was getting at - while iommu-dma should build just
fine for the likes of PPC, s390, 32-bit Arm, etc., they have no
architecture code to correctly wire up iommu_dma_ops to devices. Thus
there's currently no point pulling it in and pretending it's anything
more than a waste of space for architectures other than arm64 and x86.
It's merely a historical artefact of the x86 DMA API implementation that
when the IOMMU drivers were split out to form drivers/iommu they took
some of their relevant arch code with them.
Robin.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] iommu/virtio: Enable x86 support
2020-02-17 13:22 ` Robin Murphy
@ 2020-02-17 13:31 ` Michael S. Tsirkin
2020-02-17 14:10 ` Robin Murphy
0 siblings, 1 reply; 19+ messages in thread
From: Michael S. Tsirkin @ 2020-02-17 13:31 UTC (permalink / raw)
To: Robin Murphy
Cc: Jean-Philippe Brucker, kevin.tian, linux-pci, jasowang,
virtualization, iommu, sebastien.boeuf, jacob.jun.pan, bhelgaas
On Mon, Feb 17, 2020 at 01:22:44PM +0000, Robin Murphy wrote:
> On 17/02/2020 1:01 pm, Michael S. Tsirkin wrote:
> > On Mon, Feb 17, 2020 at 10:01:07AM +0100, Jean-Philippe Brucker wrote:
> > > On Sun, Feb 16, 2020 at 04:50:33AM -0500, Michael S. Tsirkin wrote:
> > > > On Fri, Feb 14, 2020 at 04:57:11PM +0000, Robin Murphy wrote:
> > > > > On 14/02/2020 4:04 pm, Jean-Philippe Brucker wrote:
> > > > > > With the built-in topology description in place, x86 platforms can now
> > > > > > use the virtio-iommu.
> > > > > >
> > > > > > Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> > > > > > ---
> > > > > > drivers/iommu/Kconfig | 3 ++-
> > > > > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> > > > > > index 068d4e0e3541..adcbda44d473 100644
> > > > > > --- a/drivers/iommu/Kconfig
> > > > > > +++ b/drivers/iommu/Kconfig
> > > > > > @@ -508,8 +508,9 @@ config HYPERV_IOMMU
> > > > > > config VIRTIO_IOMMU
> > > > > > bool "Virtio IOMMU driver"
> > > > > > depends on VIRTIO=y
> > > > > > - depends on ARM64
> > > > > > + depends on (ARM64 || X86)
> > > > > > select IOMMU_API
> > > > > > + select IOMMU_DMA
> > > > >
> > > > > Can that have an "if X86" for clarity? AIUI it's not necessary for
> > > > > virtio-iommu itself (and really shouldn't be), but is merely to satisfy the
> > > > > x86 arch code's expectation that IOMMU drivers bring their own DMA ops,
> > > > > right?
> > > > >
> > > > > Robin.
> > > >
> > > > In fact does not this work on any platform now?
> > >
> > > There is ongoing work to use the generic IOMMU_DMA ops on X86. AMD IOMMU
> > > has been converted recently [1] but VT-d still implements its own DMA ops
> > > (conversion patches are on the list [2]). On Arm the arch Kconfig selects
> > > IOMMU_DMA, and I assume we'll have the same on X86 once Tom's work is
> > > complete. Until then I can add a "if X86" here for clarity.
> > >
> > > Thanks,
> > > Jean
> > >
> > > [1] https://lore.kernel.org/linux-iommu/20190613223901.9523-1-murphyt7@tcd.ie/
> > > [2] https://lore.kernel.org/linux-iommu/20191221150402.13868-1-murphyt7@tcd.ie/
> >
> > What about others? E.g. PPC?
>
> That was the point I was getting at - while iommu-dma should build just fine
> for the likes of PPC, s390, 32-bit Arm, etc., they have no architecture code
> to correctly wire up iommu_dma_ops to devices. Thus there's currently no
> point pulling it in and pretending it's anything more than a waste of space
> for architectures other than arm64 and x86. It's merely a historical
> artefact of the x86 DMA API implementation that when the IOMMU drivers were
> split out to form drivers/iommu they took some of their relevant arch code
> with them.
>
> Robin.
Rather than white-listing architectures, how about making the
architectures in question set some kind of symbol, and depend on it?
--
MST
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] iommu/virtio: Enable x86 support
2020-02-17 13:31 ` Michael S. Tsirkin
@ 2020-02-17 14:10 ` Robin Murphy
0 siblings, 0 replies; 19+ messages in thread
From: Robin Murphy @ 2020-02-17 14:10 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Jean-Philippe Brucker, kevin.tian, linux-pci, jasowang,
virtualization, iommu, sebastien.boeuf, jacob.jun.pan, bhelgaas
On 17/02/2020 1:31 pm, Michael S. Tsirkin wrote:
> On Mon, Feb 17, 2020 at 01:22:44PM +0000, Robin Murphy wrote:
>> On 17/02/2020 1:01 pm, Michael S. Tsirkin wrote:
>>> On Mon, Feb 17, 2020 at 10:01:07AM +0100, Jean-Philippe Brucker wrote:
>>>> On Sun, Feb 16, 2020 at 04:50:33AM -0500, Michael S. Tsirkin wrote:
>>>>> On Fri, Feb 14, 2020 at 04:57:11PM +0000, Robin Murphy wrote:
>>>>>> On 14/02/2020 4:04 pm, Jean-Philippe Brucker wrote:
>>>>>>> With the built-in topology description in place, x86 platforms can now
>>>>>>> use the virtio-iommu.
>>>>>>>
>>>>>>> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
>>>>>>> ---
>>>>>>> drivers/iommu/Kconfig | 3 ++-
>>>>>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
>>>>>>> index 068d4e0e3541..adcbda44d473 100644
>>>>>>> --- a/drivers/iommu/Kconfig
>>>>>>> +++ b/drivers/iommu/Kconfig
>>>>>>> @@ -508,8 +508,9 @@ config HYPERV_IOMMU
>>>>>>> config VIRTIO_IOMMU
>>>>>>> bool "Virtio IOMMU driver"
>>>>>>> depends on VIRTIO=y
>>>>>>> - depends on ARM64
>>>>>>> + depends on (ARM64 || X86)
>>>>>>> select IOMMU_API
>>>>>>> + select IOMMU_DMA
>>>>>>
>>>>>> Can that have an "if X86" for clarity? AIUI it's not necessary for
>>>>>> virtio-iommu itself (and really shouldn't be), but is merely to satisfy the
>>>>>> x86 arch code's expectation that IOMMU drivers bring their own DMA ops,
>>>>>> right?
>>>>>>
>>>>>> Robin.
>>>>>
>>>>> In fact does not this work on any platform now?
>>>>
>>>> There is ongoing work to use the generic IOMMU_DMA ops on X86. AMD IOMMU
>>>> has been converted recently [1] but VT-d still implements its own DMA ops
>>>> (conversion patches are on the list [2]). On Arm the arch Kconfig selects
>>>> IOMMU_DMA, and I assume we'll have the same on X86 once Tom's work is
>>>> complete. Until then I can add a "if X86" here for clarity.
>>>>
>>>> Thanks,
>>>> Jean
>>>>
>>>> [1] https://lore.kernel.org/linux-iommu/20190613223901.9523-1-murphyt7@tcd.ie/
>>>> [2] https://lore.kernel.org/linux-iommu/20191221150402.13868-1-murphyt7@tcd.ie/
>>>
>>> What about others? E.g. PPC?
>>
>> That was the point I was getting at - while iommu-dma should build just fine
>> for the likes of PPC, s390, 32-bit Arm, etc., they have no architecture code
>> to correctly wire up iommu_dma_ops to devices. Thus there's currently no
>> point pulling it in and pretending it's anything more than a waste of space
>> for architectures other than arm64 and x86. It's merely a historical
>> artefact of the x86 DMA API implementation that when the IOMMU drivers were
>> split out to form drivers/iommu they took some of their relevant arch code
>> with them.
>>
>> Robin.
>
>
> Rather than white-listing architectures, how about making the
> architectures in question set some kind of symbol, and depend on it?
Umm, that's basically what we have already? Architectures that use
iommu_dma_ops select IOMMU_DMA.
The only issue is the oddity of x86 treating IOMMU drivers as part of
its arch code, which has never come up against a cross-architecture
driver until now. Hence the options of either maintaining that paradigm
and having the 'x86 arch code' aspect of this driver "select IOMMU_DMA
if x86" such that it works out equivalent to AMD_IOMMU, or a more
involved cleanup to move that responsibility out of
drivers/iommu/Kconfig entirely and have arch/x86/Kconfig do something
like "select IOMMU_DMA if IOMMU_API", as Jean suggested up-thread.
In the specific context of IOMMU_DMA we're not talking about any kind of
white-list, merely a one-off special case for one particular architecture.
Robin.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] iommu/virtio: Enable x86 support
2021-03-18 18:28 ` Michael S. Tsirkin
@ 2021-04-15 15:15 ` Jean-Philippe Brucker
0 siblings, 0 replies; 19+ messages in thread
From: Jean-Philippe Brucker @ 2021-04-15 15:15 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: kevin.tian, robin.murphy, rjw, virtualization, linux-acpi, iommu,
sebastien.boeuf, will, lenb
On Thu, Mar 18, 2021 at 02:28:02PM -0400, Michael S. Tsirkin wrote:
> On Tue, Mar 16, 2021 at 08:16:54PM +0100, Jean-Philippe Brucker wrote:
> > With the VIOT support in place, x86 platforms can now use the
> > virtio-iommu.
> >
> > The arm64 Kconfig selects IOMMU_DMA, while x86 IOMMU drivers select it
> > themselves.
> >
> > Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
>
> Acked-by: Michael S. Tsirkin <mst@redhat.com>
>
> > ---
> > drivers/iommu/Kconfig | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> > index 2819b5c8ec30..ccca83ef2f06 100644
> > --- a/drivers/iommu/Kconfig
> > +++ b/drivers/iommu/Kconfig
> > @@ -400,8 +400,9 @@ config HYPERV_IOMMU
> > config VIRTIO_IOMMU
> > tristate "Virtio IOMMU driver"
> > depends on VIRTIO
> > - depends on ARM64
> > + depends on (ARM64 || X86)
> > select IOMMU_API
> > + select IOMMU_DMA if X86
>
> Would it hurt to just select unconditionally? Seems a bit cleaner
> ...
Yes I think I'll do this for the moment
Thanks,
Jean
>
> > select INTERVAL_TREE
> > select ACPI_VIOT if ACPI
> > help
> > --
> > 2.30.2
>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] iommu/virtio: Enable x86 support
2021-03-18 11:43 ` Robin Murphy
@ 2021-04-15 15:14 ` Jean-Philippe Brucker
0 siblings, 0 replies; 19+ messages in thread
From: Jean-Philippe Brucker @ 2021-04-15 15:14 UTC (permalink / raw)
To: Robin Murphy
Cc: kevin.tian, mst, rjw, virtualization, linux-acpi, iommu,
sebastien.boeuf, will, lenb
On Thu, Mar 18, 2021 at 11:43:38AM +0000, Robin Murphy wrote:
> On 2021-03-16 19:16, Jean-Philippe Brucker wrote:
> > With the VIOT support in place, x86 platforms can now use the
> > virtio-iommu.
> >
> > The arm64 Kconfig selects IOMMU_DMA, while x86 IOMMU drivers select it
> > themselves.
>
> Actually, now that both AMD and Intel are converted over, maybe it's finally
> time to punt that to x86 arch code to match arm64?
x86 also has CONFIG_HYPERV_IOMMU that doesn't use IOMMU_DMA, and might not
want to pull in dma-iommu.o + iova.o (don't know if they care about guest
size). There also is the old gart driver, but that doesn't select
IOMMU_SUPPORT.
Thanks,
Jean
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] iommu/virtio: Enable x86 support
2021-03-16 19:16 ` [PATCH 3/3] iommu/virtio: Enable x86 support Jean-Philippe Brucker
2021-03-18 10:44 ` Joerg Roedel
2021-03-18 11:43 ` Robin Murphy
@ 2021-03-18 18:28 ` Michael S. Tsirkin
2021-04-15 15:15 ` Jean-Philippe Brucker
2 siblings, 1 reply; 19+ messages in thread
From: Michael S. Tsirkin @ 2021-03-18 18:28 UTC (permalink / raw)
To: Jean-Philippe Brucker
Cc: kevin.tian, robin.murphy, rjw, virtualization, linux-acpi, iommu,
sebastien.boeuf, will, lenb
On Tue, Mar 16, 2021 at 08:16:54PM +0100, Jean-Philippe Brucker wrote:
> With the VIOT support in place, x86 platforms can now use the
> virtio-iommu.
>
> The arm64 Kconfig selects IOMMU_DMA, while x86 IOMMU drivers select it
> themselves.
>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> drivers/iommu/Kconfig | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index 2819b5c8ec30..ccca83ef2f06 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -400,8 +400,9 @@ config HYPERV_IOMMU
> config VIRTIO_IOMMU
> tristate "Virtio IOMMU driver"
> depends on VIRTIO
> - depends on ARM64
> + depends on (ARM64 || X86)
> select IOMMU_API
> + select IOMMU_DMA if X86
Would it hurt to just select unconditionally? Seems a bit cleaner
...
> select INTERVAL_TREE
> select ACPI_VIOT if ACPI
> help
> --
> 2.30.2
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] iommu/virtio: Enable x86 support
2021-03-16 19:16 ` [PATCH 3/3] iommu/virtio: Enable x86 support Jean-Philippe Brucker
2021-03-18 10:44 ` Joerg Roedel
@ 2021-03-18 11:43 ` Robin Murphy
2021-04-15 15:14 ` Jean-Philippe Brucker
2021-03-18 18:28 ` Michael S. Tsirkin
2 siblings, 1 reply; 19+ messages in thread
From: Robin Murphy @ 2021-03-18 11:43 UTC (permalink / raw)
To: Jean-Philippe Brucker, rjw, lenb, joro, mst
Cc: kevin.tian, virtualization, linux-acpi, iommu, sebastien.boeuf, will
On 2021-03-16 19:16, Jean-Philippe Brucker wrote:
> With the VIOT support in place, x86 platforms can now use the
> virtio-iommu.
>
> The arm64 Kconfig selects IOMMU_DMA, while x86 IOMMU drivers select it
> themselves.
Actually, now that both AMD and Intel are converted over, maybe it's
finally time to punt that to x86 arch code to match arm64?
Robin.
> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> ---
> drivers/iommu/Kconfig | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index 2819b5c8ec30..ccca83ef2f06 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -400,8 +400,9 @@ config HYPERV_IOMMU
> config VIRTIO_IOMMU
> tristate "Virtio IOMMU driver"
> depends on VIRTIO
> - depends on ARM64
> + depends on (ARM64 || X86)
> select IOMMU_API
> + select IOMMU_DMA if X86
> select INTERVAL_TREE
> select ACPI_VIOT if ACPI
> help
>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] iommu/virtio: Enable x86 support
2021-03-16 19:16 ` [PATCH 3/3] iommu/virtio: Enable x86 support Jean-Philippe Brucker
@ 2021-03-18 10:44 ` Joerg Roedel
2021-03-18 11:43 ` Robin Murphy
2021-03-18 18:28 ` Michael S. Tsirkin
2 siblings, 0 replies; 19+ messages in thread
From: Joerg Roedel @ 2021-03-18 10:44 UTC (permalink / raw)
To: Jean-Philippe Brucker
Cc: kevin.tian, mst, robin.murphy, rjw, virtualization, linux-acpi,
iommu, sebastien.boeuf, will, lenb
On Tue, Mar 16, 2021 at 08:16:54PM +0100, Jean-Philippe Brucker wrote:
> With the VIOT support in place, x86 platforms can now use the
> virtio-iommu.
>
> The arm64 Kconfig selects IOMMU_DMA, while x86 IOMMU drivers select it
> themselves.
>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> ---
> drivers/iommu/Kconfig | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index 2819b5c8ec30..ccca83ef2f06 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -400,8 +400,9 @@ config HYPERV_IOMMU
> config VIRTIO_IOMMU
> tristate "Virtio IOMMU driver"
> depends on VIRTIO
> - depends on ARM64
> + depends on (ARM64 || X86)
> select IOMMU_API
> + select IOMMU_DMA if X86
> select INTERVAL_TREE
> select ACPI_VIOT if ACPI
> help
Acked-by: Joerg Roedel <jroedel@suse.de>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH 3/3] iommu/virtio: Enable x86 support
2021-03-16 19:16 [PATCH 0/3] Add support for ACPI VIOT Jean-Philippe Brucker
@ 2021-03-16 19:16 ` Jean-Philippe Brucker
2021-03-18 10:44 ` Joerg Roedel
` (2 more replies)
0 siblings, 3 replies; 19+ messages in thread
From: Jean-Philippe Brucker @ 2021-03-16 19:16 UTC (permalink / raw)
To: rjw, lenb, joro, mst
Cc: jean-philippe, kevin.tian, robin.murphy, virtualization,
linux-acpi, iommu, sebastien.boeuf, will
With the VIOT support in place, x86 platforms can now use the
virtio-iommu.
The arm64 Kconfig selects IOMMU_DMA, while x86 IOMMU drivers select it
themselves.
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
---
drivers/iommu/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 2819b5c8ec30..ccca83ef2f06 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -400,8 +400,9 @@ config HYPERV_IOMMU
config VIRTIO_IOMMU
tristate "Virtio IOMMU driver"
depends on VIRTIO
- depends on ARM64
+ depends on (ARM64 || X86)
select IOMMU_API
+ select IOMMU_DMA if X86
select INTERVAL_TREE
select ACPI_VIOT if ACPI
help
--
2.30.2
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 19+ messages in thread
end of thread, other threads:[~2021-04-15 15:15 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-14 16:04 [PATCH 0/3] virtio-iommu on non-devicetree platforms Jean-Philippe Brucker
2020-02-14 16:04 ` [PATCH 1/3] iommu/virtio: Add topology description to virtio-iommu config space Jean-Philippe Brucker
2020-02-14 16:04 ` [PATCH 2/3] PCI: Add DMA configuration for virtual platforms Jean-Philippe Brucker
2020-02-14 17:03 ` Robin Murphy
2020-02-17 9:12 ` Jean-Philippe Brucker
2020-02-14 16:04 ` [PATCH 3/3] iommu/virtio: Enable x86 support Jean-Philippe Brucker
2020-02-14 16:57 ` Robin Murphy
2020-02-16 9:50 ` Michael S. Tsirkin
2020-02-17 9:01 ` Jean-Philippe Brucker
2020-02-17 13:01 ` Michael S. Tsirkin
2020-02-17 13:22 ` Robin Murphy
2020-02-17 13:31 ` Michael S. Tsirkin
2020-02-17 14:10 ` Robin Murphy
2021-03-16 19:16 [PATCH 0/3] Add support for ACPI VIOT Jean-Philippe Brucker
2021-03-16 19:16 ` [PATCH 3/3] iommu/virtio: Enable x86 support Jean-Philippe Brucker
2021-03-18 10:44 ` Joerg Roedel
2021-03-18 11:43 ` Robin Murphy
2021-04-15 15:14 ` Jean-Philippe Brucker
2021-03-18 18:28 ` Michael S. Tsirkin
2021-04-15 15:15 ` Jean-Philippe Brucker
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).