Hi Alex,
On Fri, Feb 9, 2018 at 4:50 PM, Alex Williamson
<alex.william...@redhat.com> wrote:
> On Fri, 9 Feb 2018 16:17:35 +0100
> Geert Uytterhoeven <geert+rene...@glider.be> wrote:
>> From: Xiao Feng Ren <renxi...@linux.vnet.ibm.com>
>>
>> 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 <renxi...@linux.vnet.ibm.com>
>> [geert: Rebase]
>> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
>> ---
>> 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
What if the device cannot do DMA?
There are other devices that cannot do DMA, but that can be useful to
access from a guest in an embedded system.
E.g. smart ADC monitor blocks that monitor and average several ADCs in an
automotive environment (drivers/iio/adc/rcar-gyroadc.c).
Should all such devices be paravirtualized?
> of corrupting vfio support in order to blink some LEDs. Thanks,
This GPIO+LED prototype is just a proof-of-concept. There's no plan to
upstream it.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
