Hello all, I'm currently writing an application that makes use of Qemu's ivshmem shared memory mechanism, which exposes shared memory regions from the host via PCI-E BARs. MSI-X interrupts that are tied to host eventfds are also exposed.
Since ivshmem doesn't have an in-tree kernel driver, I have been using VFIO's NOIOMMU mode to interface with the device. This works wonderfully for both BAR mapping and MSI-X interrupts. Unfortunately though, binding the ivshmem device to vfio_pci to use it in this way results in a kernel taint. I understand that this is because without an IOMMU, VFIO/Linux has no way of preventing devices from performing malicious access to other system memory. In the case of ivshmem though, the device does not have any DMA capabilities. This has created a situation in which the safest possible way to access the device (a kernel driver would be inherently less safe, UIO can't access the MSI-X functionality of the device) results in a kernel taint, when other, less safe methods don't. In light of this, I propose a change to the VFIO framework that would allow use cases such as this without a kernel taint. One solution I see is only tainting when PCI devices with DMA capabilities are bound to VFIO. It is my understanding that a device's DMA capability can be determined by checking the Bus Mastering flag in the device's PCI configuration space, so something like this should be feasible. Perhaps an additional NOIOMMU mode could be introduced which only allows devices which meet this criteria, too (VFIO_NOIOMMU_NODMA_IOMMU?). Along with a separate Kconfig option, this would allow users to enable this safe usage at kernel build time, while still preventing the possibility of an unsafe DMA capable device from being used. I'm curious to hear feedback on this. If this is something that can be merged, I'd be more than happy to write a patch. - Shawn _______________________________________________ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users
