search for: virt_dma_configur

...gt; 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 se...

...le mode 100644 > index 000000000000..17d2bd4732e0 > --- /dev/null > +++ b/include/linux/virt_iommu.h > @@ -0,0 +1,15 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +#ifndef VIRT_IOMMU_H_ > +#define VIRT_IOMMU_H_ > + > +#ifdef CONFIG_VIRTIO_IOMMU_TOPOLOGY_HELPERS > +int virt_dma_configure(struct device *dev); > + > +#else /* !CONFIG_VIRTIO_IOMMU_TOPOLOGY_HELPERS */ > +static inline int virt_dma_configure(struct device *dev) > +{ > + /* Don't disturb the normal DMA configuration methods */ > + return 0; > +} > +#endif /* !CONFIG_VIRTIO_IOMMU_TOPOLOGY_HELP...

...d rewriting the whole DMA code, but it wouldn't work with platform endpoints, which are references to items in the ACPI table on IORT. Signed-off-by: Eric Auger <eric.auger at redhat.com> Signed-off-by: Jean-Philippe Brucker <jean-philippe at linaro.org> --- Note that we only call virt_dma_configure() if the host didn't provide either DT or ACPI method. If you want to test this with QEMU, you'll need to manually disable the acpi_dma_configure() part in pci-driver.c --- drivers/base/platform.c | 3 + drivers/iommu/Kconfig | 9 + drivers/iommu/Makefile...

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

...the unions. Maybe add a uniform record length + number of records field. Then just skip types you do not know how to handle. This will also help make sure it's within bounds. What do you think? You will need to do something to address the TODO I think. > --- > Note that we only call virt_dma_configure() if the host didn't provide > either DT or ACPI method. If you want to test this with QEMU, you'll > need to manually disable the acpi_dma_configure() part in pci-driver.c > --- > drivers/base/platform.c | 3 + > drivers/iommu/Kconfig | 9...

...x/virt_iommu.h b/include/linux/virt_iommu.h new file mode 100644 index 000000000000..17d2bd4732e0 --- /dev/null +++ b/include/linux/virt_iommu.h @@ -0,0 +1,15 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef VIRT_IOMMU_H_ +#define VIRT_IOMMU_H_ + +#ifdef CONFIG_VIRTIO_IOMMU_TOPOLOGY_HELPERS +int virt_dma_configure(struct device *dev); + +#else /* !CONFIG_VIRTIO_IOMMU_TOPOLOGY_HELPERS */ +static inline int virt_dma_configure(struct device *dev) +{ + /* Don't disturb the normal DMA configuration methods */ + return 0; +} +#endif /* !CONFIG_VIRTIO_IOMMU_TOPOLOGY_HELPERS */ +#endif /* VIRT_IOMMU_H_ */ diff...

...scovered 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 at linaro.org> --- drive...

...gt; + 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,...

...gt; + 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 > + * pr...

...gt; + 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 > + * pr...

...gt; + 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 > + * pr...

I'm seeking feedback on multi-platform support for virtio-iommu. At the moment only devicetree (DT) is supported and we don't have a pleasant solution for other platforms. Once we figure out the topology description, x86 support is trivial. Since the IOMMU manages memory accesses from other devices, the guest kernel needs to initialize the IOMMU before endpoints start issuing DMA.

I'm seeking feedback on multi-platform support for virtio-iommu. At the moment only devicetree (DT) is supported and we don't have a pleasant solution for other platforms. Once we figure out the topology description, x86 support is trivial. Since the IOMMU manages memory accesses from other devices, the guest kernel needs to initialize the IOMMU before endpoints start issuing DMA.

Add a topology description to the virtio-iommu driver and enable x86 platforms. Since [v2] we have made some progress on adding ACPI support for virtio-iommu, which is the preferred boot method on x86. It will be a new vendor-agnostic table describing para-virtual topologies in a minimal format. However some platforms don't use either ACPI or DT for booting (for example microvm), and will

Add a topology description to the virtio-iommu driver and enable x86 platforms. Since [v2] we have made some progress on adding ACPI support for virtio-iommu, which is the preferred boot method on x86. It will be a new vendor-agnostic table describing para-virtual topologies in a minimal format. However some platforms don't use either ACPI or DT for booting (for example microvm), and will