On 2024/9/28 00:17, Mostafa Saleh wrote:
Hi All, Background ========== I have been looking into assigning simple devices which are not DMA capable to VMs on Android using VFIO platform. I have been mainly looking with respect to Protected KVM (pKVM), which would need some extra modifications mostly to KVM-VFIO, that is quite early under prototyping at the moment, which have core pending pKVM dependencies upstream as guest memfd[1] and IOMMUs support[2]. However, this problem is not pKVM(or KVM) specific, and about the design of VFIO. [1] https://lore.kernel.org/kvm/20240801090117.3841080-1-tabba@xxxxxxxxxx/ [2] https://lore.kernel.org/kvmarm/20230201125328.2186498-1-jean-philippe@xxxxxxxxxx/ Problem ======= At the moment, VFIO platform will deny a device from probing (through vfio_group_find_or_alloc()), if it’s not part of an IOMMU group, unless (CONFIG_VFIO_NOIOMMU is configured)
so your device does not have an IOMMU and also it does not do DMA at all?
As far as I understand the current solutions to pass through platform devices that are not DMA capable are: - Use VFIO platform + (CONFIG_VFIO_NOIOMMU): The problem with that, it taints the kernel and this doesn’t actually fit the device description as the device doesn’t only have an IOMMU, but it’s not DMA capable at all, so the kernel should be safe with assigning the device without DMA isolation.
you need to set the vfio_noiommu parameter as well. yes, this would give your device a fake iommu group. But the kernel would say this taints it.
- Use VFIO mdev with an emulated IOMMU, this seems it could work. But many of the code would be duplicate with the VFIO platform code as the device is a platform device. - Use UIO: Can map MMIO to userspace which seems to be focused for userspace drivers rather than VM passthrough and I can’t find its support in Qemu.
QEMU is for device passthrough, it makes sense it needs to use the VFIO without noiommu instead of UIO. The below link has more explanations. https://wiki.qemu.org/Features/VT-d As the introduction of vfio cdev, you may compile the vfio group out by CONFIG_VFIO_GROUP==n. Supposedly, you will not be blocked by the vfio_group_find_or_alloc(). But you might be blocked due to no present iommu. You may have a try though.
One other benefit from supporting this in VFIO platform, that we can use the existing UAPI for platform devices (and support in VMMs) Proposal ======== Extend VFIO platform to allow assigning devices without an IOMMU, this can be possibly done by - Checking device capability from the platform bus (would be something ACPI/OF specific similar to how it configures DMA from platform_dma_configure(), we can add a new function something like platfrom_dma_capable()) - Using emulated IOMMU for such devices (vfio_register_emulated_iommu_dev()), instead of having intrusive changes about IOMMUs existence.
is it the mdev approach listed in the above? -- Regards, Yi Liu
