linux-kernel - [RFC] Simple device assignment with VFIO platform

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAFgf54rCCWjHLsLUxrMspNHaKAa1o8n3Md2_ZNGVtj0cU_dOPg@mail.gmail.com>
Date: Fri, 27 Sep 2024 17:17:02 +0100
From: Mostafa Saleh <smostafa@...gle.com>
To: kvm@...r.kernel.org, open list <linux-kernel@...r.kernel.org>
Cc: Eric Auger <eric.auger@...hat.com>, Alex Williamson <alex.williamson@...hat.com>, 
	kwankhede@...dia.com, Marc Zyngier <maz@...nel.org>, Will Deacon <will@...nel.org>, 
	Quentin Perret <qperret@...gle.com>
Subject: [RFC] Simple device assignment with VFIO platform

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@google.com/
[2] https://lore.kernel.org/kvmarm/20230201125328.2186498-1-jean-philippe@linaro.org/

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)

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.

- 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.

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.

If that makes sense I can work on RFC(I don’t have any code at the moment)

Thanks,
Mostafa