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. Regards, Landon (CoreWeave)
