On Fri, Mar 20, 2026, at 5:38 PM, Landon Clipp wrote: > On Fri Feb 9, 2018 at 9:50 AM CST, Alex Williamson wrote: >> On Fri, 9 Feb 2018 16:17:35 +0100 >> Geert Uytterhoeven <[email protected]> wrote: >> >>> From: Xiao Feng Ren <[email protected]> >>> >>> Add qemu support for the newly introduced VFIO No-IOMMU driver. >>> >>> We need to add special handling for: >>> - Group character device is /dev/vfio/noiommu-$GROUP. >>> - No-IOMMU does not rely on a memory listener. >>> - No IOMMU will be set for its group, so no need to call >>> vfio_kvm_device_add_group. >>> >>> Signed-off-by: Xiao Feng Ren <[email protected]> >>> [geert: Rebase] >>> Signed-off-by: Geert Uytterhoeven <[email protected]> >>> --- >>> hw/vfio/common.c | 61 >>> ++++++++++++++++++++++++++++++++++--------- >>> include/hw/vfio/vfio-common.h | 2 ++ >>> 2 files changed, 50 insertions(+), 13 deletions(-) >> >> NAK. I'm opposed to no-iommu support in QEMU in general, but accepting >> vfio devices with no-iommu (which provide no DMA translation!!!) >> transparently as if they might actually work like a regular vfio device >> is absolutely unacceptable. Without DMA translation and isolation, you >> might want to think about another interface, I'm not keen on the idea >> of corrupting vfio support in order to blink some LEDs. Thanks, >> >> Alex >> > > 8 years later, I was wondering if we could revisit this. I found myself in a > need to use enable_unsafe_noiommu_mode due to some systems I'm using not > having > a usable IOMMU. QEMU is being used as part of a single-tenant workload > sandboxing environment, and given the specific circumstances, both the users > and > the administrators understand that enabling the noiommu mode is unsafe and > cannot be used where security matters. Regardless, it's still something we > want. > > As the administrator of my system, it's under my control whether VFIO is put > into this mode, and if it is, I would expect the remaning software components > to respect that decision. As is, the system is unusable because of a lack of > support in QEMU. > > I'm happy to elucidate more of my use-case if it is helpful, but I > first wanted to > gauge your willingness to reconsider this under a different context.
I'm not aware of anything that's improved the chances of accepting something like this. In fact, a vfio-platform motivated feature is arguably on worse footing now. More importantly, QEMU now has support for vfio-user, so I believe you can already do this. The model would be a vfio-noiommu userspace driver that exposes a vfio-user interface for QEMU. All of the previous issues with security and virtualization still remain with implementing this support directly in QEMU. Providing a DMA capable no-iommu device to a QEMU sandbox negates any isolation it might otherwise provide. With the vfio-user no-iommu driver model, you take on the security burden to use only non-DMA capable devices, or mediate the access, rather than asking the QEMU community to assume that risk. Thanks, Alex
