By SMMUv3 specification it can be attached either to PCIe Root Complex or regular IO bus devices. However, current implementation only allow to associate with PCI bus. This patch series add support to use SMMU for sysbus devices. One usage example implemented for virtio-mmio, which allow devices to perform DMA operations SMMUv3 with address translation and isolation. The patchset has a basic support to create multiple SMMU's on sysbus. The next step would probably to add qemu-option to create arm-smmuv3 devices similarly to PCIe logic, e.g.: '-device arm-smmuv3,generic-bus=id'. This is not implemented yet.
On Fri, 19 Dec 2025 at 22:25, <ruslichenko.r@gmail.com> wrote: > > By SMMUv3 specification it can be attached either to PCIe Root > Complex or regular IO bus devices. However, current > implementation only allow to associate with PCI bus. > > This patch series add support to use SMMU for sysbus devices. > > One usage example implemented for virtio-mmio, which allow > devices to perform DMA operations SMMUv3 with address translation > and isolation. If you want virtio devices behind an SMMU, why not use the PCI virtio? The only SMMU sysbus requirement I'm aware of is that for RME we will want to have things like the GIC do GPT lookups, which is most conveniently done by having them route through the existing for-PCI SMMU, rather than by having an extra SMMU just for them. thanks -- PMM
On Sun, Dec 28, 2025 at 5:59 PM Peter Maydell <peter.maydell@linaro.org> wrote: > > On Fri, 19 Dec 2025 at 22:25, <ruslichenko.r@gmail.com> wrote: > > > > By SMMUv3 specification it can be attached either to PCIe Root > > Complex or regular IO bus devices. However, current > > implementation only allow to associate with PCI bus. > > > > This patch series add support to use SMMU for sysbus devices. > > > > One usage example implemented for virtio-mmio, which allow > > devices to perform DMA operations SMMUv3 with address translation > > and isolation. > > If you want virtio devices behind an SMMU, why not use > the PCI virtio? > > The only SMMU sysbus requirement I'm aware of is that for > RME we will want to have things like the GIC do GPT lookups, > which is most conveniently done by having them route through > the existing for-PCI SMMU, rather than by having an extra > SMMU just for them. There may be several reasons for supporting SMMU on sysbus: Some embedded platforms may not use and don't want to include a full PCI subsystem, but still want IOMMU isolation with virtio-mmio. The other reason is to emulate existing SoC platforms. The model may need to be closer to real-world HW and SMMU is widely used outside the PCI subsystem. One more reason is Remote-Port devices in our case, currently ongoing development here: https://lists.nongnu.org/archive/html/qemu-devel/2025-12/msg02121.html. Those are platform devices which are emulated by external services. These devices need to perform SMMU operations for DMA transactions when they are bus-masters. BR, Ruslan
On Fri, Jan 2, 2026 at 4:36 PM Ruslan Ruslichenko <ruslichenko.r@gmail.com> wrote: > > On Sun, Dec 28, 2025 at 5:59 PM Peter Maydell <peter.maydell@linaro.org> wrote: > > > > On Fri, 19 Dec 2025 at 22:25, <ruslichenko.r@gmail.com> wrote: > > > > > > By SMMUv3 specification it can be attached either to PCIe Root > > > Complex or regular IO bus devices. However, current > > > implementation only allow to associate with PCI bus. > > > > > > This patch series add support to use SMMU for sysbus devices. > > > > > > One usage example implemented for virtio-mmio, which allow > > > devices to perform DMA operations SMMUv3 with address translation > > > and isolation. > > > > If you want virtio devices behind an SMMU, why not use > > the PCI virtio? > > > > The only SMMU sysbus requirement I'm aware of is that for > > RME we will want to have things like the GIC do GPT lookups, > > which is most conveniently done by having them route through > > the existing for-PCI SMMU, rather than by having an extra > > SMMU just for them. > > There may be several reasons for supporting SMMU on sysbus: > > Some embedded platforms may not use and don't want to include a full > PCI subsystem, but still want IOMMU isolation with virtio-mmio. > > The other reason is to emulate existing SoC platforms. The model may > need to be closer to real-world HW and SMMU is widely used outside the > PCI subsystem. > > One more reason is Remote-Port devices in our case, currently ongoing > development here: > https://lists.nongnu.org/archive/html/qemu-devel/2025-12/msg02121.html. > Those are platform devices which are emulated by external services. > These devices need to perform SMMU operations for DMA transactions > when they are bus-masters. > A gentle ping on this series. Hi Peter! Do you think we can continue discussion on this topic? > BR, > Ruslan
On Mon, 19 Jan 2026 at 14:42, Ruslan Ruslichenko <ruslichenko.r@gmail.com> wrote: > > On Fri, Jan 2, 2026 at 4:36 PM Ruslan Ruslichenko > <ruslichenko.r@gmail.com> wrote: > > > > On Sun, Dec 28, 2025 at 5:59 PM Peter Maydell <peter.maydell@linaro.org> wrote: > > > > > > On Fri, 19 Dec 2025 at 22:25, <ruslichenko.r@gmail.com> wrote: > > > > > > > > By SMMUv3 specification it can be attached either to PCIe Root > > > > Complex or regular IO bus devices. However, current > > > > implementation only allow to associate with PCI bus. > > > > > > > > This patch series add support to use SMMU for sysbus devices. > > > > > > > > One usage example implemented for virtio-mmio, which allow > > > > devices to perform DMA operations SMMUv3 with address translation > > > > and isolation. > > > > > > If you want virtio devices behind an SMMU, why not use > > > the PCI virtio? > > > > > > The only SMMU sysbus requirement I'm aware of is that for > > > RME we will want to have things like the GIC do GPT lookups, > > > which is most conveniently done by having them route through > > > the existing for-PCI SMMU, rather than by having an extra > > > SMMU just for them. > > > > There may be several reasons for supporting SMMU on sysbus: > > > > Some embedded platforms may not use and don't want to include a full > > PCI subsystem, but still want IOMMU isolation with virtio-mmio. > > > > The other reason is to emulate existing SoC platforms. The model may > > need to be closer to real-world HW and SMMU is widely used outside the > > PCI subsystem. > > > > One more reason is Remote-Port devices in our case, currently ongoing > > development here: > > https://lists.nongnu.org/archive/html/qemu-devel/2025-12/msg02121.html. > > Those are platform devices which are emulated by external services. > > These devices need to perform SMMU operations for DMA transactions > > when they are bus-masters. > > > > A gentle ping on this series. > > Hi Peter! > > Do you think we can continue discussion on this topic? We would want a reason that applied to upstream QEMU. If you have a platform that uses this that you're modelling upstream, we can think about the SMMU parts of that at that point. At the moment all this patchset does is let you put a virtio-mmio device behind an SMMU, which is something I don't want because it's a pile of extra complexity for a use case that is better handled by using PCI. thanks -- PMM
On Mon, Jan 19, 2026 at 3:57 PM Peter Maydell <peter.maydell@linaro.org> wrote: > On Mon, 19 Jan 2026 at 14:42, Ruslan Ruslichenko > <ruslichenko.r@gmail.com> wrote: > > > > On Fri, Jan 2, 2026 at 4:36 PM Ruslan Ruslichenko > > <ruslichenko.r@gmail.com> wrote: > > > > > > On Sun, Dec 28, 2025 at 5:59 PM Peter Maydell < > peter.maydell@linaro.org> wrote: > > > > > > > > On Fri, 19 Dec 2025 at 22:25, <ruslichenko.r@gmail.com> wrote: > > > > > > > > > > By SMMUv3 specification it can be attached either to PCIe Root > > > > > Complex or regular IO bus devices. However, current > > > > > implementation only allow to associate with PCI bus. > > > > > > > > > > This patch series add support to use SMMU for sysbus devices. > > > > > > > > > > One usage example implemented for virtio-mmio, which allow > > > > > devices to perform DMA operations SMMUv3 with address translation > > > > > and isolation. > > > > > > > > If you want virtio devices behind an SMMU, why not use > > > > the PCI virtio? > > > > > > > > The only SMMU sysbus requirement I'm aware of is that for > > > > RME we will want to have things like the GIC do GPT lookups, > > > > which is most conveniently done by having them route through > > > > the existing for-PCI SMMU, rather than by having an extra > > > > SMMU just for them. > > > > > > There may be several reasons for supporting SMMU on sysbus: > > > > > > Some embedded platforms may not use and don't want to include a full > > > PCI subsystem, but still want IOMMU isolation with virtio-mmio. > > > > > > The other reason is to emulate existing SoC platforms. The model may > > > need to be closer to real-world HW and SMMU is widely used outside the > > > PCI subsystem. > > > > > > One more reason is Remote-Port devices in our case, currently ongoing > > > development here: > > > https://lists.nongnu.org/archive/html/qemu-devel/2025-12/msg02121.html > . > > > Those are platform devices which are emulated by external services. > > > These devices need to perform SMMU operations for DMA transactions > > > when they are bus-masters. > > > > > > > A gentle ping on this series. > > > > Hi Peter! > > > > Do you think we can continue discussion on this topic? > > We would want a reason that applied to upstream QEMU. If you > have a platform that uses this that you're modelling upstream, > we can think about the SMMU parts of that at that point. > At the moment all this patchset does is let you put a > virtio-mmio device behind an SMMU, which is something I > don't want because it's a pile of extra complexity for > a use case that is better handled by using PCI. > > thanks > -- PMM > Hi, Xilinx Versal boards have AMBA platform devices (non-PCI) that sit behind an SMMU, this feature would be useful there. I haven't looked carefully at this series, but the way we implemented it in our Xilinx tree was by changing the SMMU code to use the Memory API rather than use a parallel interface in both IOMMU and DMA devs. Instead, DMA devices stay the same except that they need to be able to set their Transaction ID when issuing memory accesses... Best regards, Edgar
© 2016 - 2026 Red Hat, Inc.