Re: [RFC PATCH 00/10] vfio: PCI device passthrough on Apple Silicon Macs

["Scott J. Goldman" <scottjgo@gmail.com>]

On Sun Apr 5, 2026 at 3:36 AM PDT, BALATON Zoltan wrote:
> On Sun, 5 Apr 2026, Scott J. Goldman wrote:
>> This series adds VFIO PCI device passthrough support for Apple Silicon
>> Macs running macOS, using a DriverKit extension (dext) as the host
>> backend instead of the Linux VFIO kernel driver.
>>
>> I'm sending this as an RFC because I'd like feedback before investing
>> further in upstreaming.  The code is functional.  I've tested it with
>> an NVIDIA RTX 5090 in a Thunderbolt dock on an M4 MacBook Air.  GPU
>> gaming works but is slow (~30 fps on high settings in Cyberpunk 2077
>> [1]), likely due to the BAR access penalty described below.  AI
>> inference workloads appear less affected.  Ollama with Qwen 3.5
>> generates around 140 tok/sec on the same setup [2].
>>
>> How it works:
>>
>> On Linux, VFIO relies on kernel-managed IOMMU groups and /dev/vfio
>> for device access and DMA mapping.  On macOS, there is no equivalent
>> kernel interface.  Instead, a userspace DriverKit extension
>> (VFIOUserPCIDriver) mediates access to the physical PCI device through
>> IOKit's IOUserClient and PCIDriverKit APIs.
>>
>> The series keeps the existing VFIOPCIDevice model and reuses QEMU's
>> passthrough infrastructure.  A few ioctl callsites are refactored into
>> io_ops callbacks, the build system is extended for Darwin, and the
>> Apple-specific backend plugs in behind those abstractions.
>>
>> The guest sees two PCI devices: the passthrough device itself
>> (vfio-apple-pci, which subclasses VFIOPCIDevice) and a companion
>> DMA mapping device (apple-dma-pci).  On the QEMU side, an
>> AppleVFIOContainer implements the IOMMU backend, and a C client
>> library wraps the IOUserClient calls to the dext for config space,
>> BAR MMIO, interrupts, reset, and DMA.
>>
>> DMA limitations:
>>
>> This is the biggest platform constraint.  Unlike a typical IOMMU
>> mapping operation where the caller specifies the IOVA, the
>> PCIDriverKit API (IODMACommand::PrepareForDMA) returns a
>> system-assigned IOVA.  There is no way to request a specific address.
>> This means the guest's requested DMA addresses cannot be used
>> directly.  The guest kernel module must intercept DMA mapping calls
>> and forward them through the companion device to get the actual
>> hardware IOVA.
>
> I don't know this so what I say might not make sense but I think there is 
> iommu emulation in QEMU so could that be used to do this in QEMU and avoid 
> needing a kernel module for it in the guest?
>
> Regards,
> BALATON Zoltan

I think the challenge is that this is a passthrough device doing
DMA directly on the physical PCIe bus.  The device's DMA
transactions go through the real hardware IOMMU (DART), not
through QEMU.

If the guest programs the device with IOVA 0x1000 (assigned by
a virtual IOMMU), the device will issue a DMA read for 0x1000 on
the physical bus.  But DART only knows about the IOVAs that
PrepareForDMA assigned, so the transaction would fault.

My understanding is that on other platforms, this is handled in
a simpler way because the host IOMMU can be programmed directly:

1. Guest boots with 2 GB of RAM.  QEMU maps guest physical
   address (GPA) 0x10000000-0x90000000 to host physical memory
   at, say, 0x110000000-0x190000000.
2. QEMU programs the host IOMMU so the device's view of
   0x10000000-0x90000000 translates to the real host addresses.
3. Guest programs the PCI device to DMA to GPA 0x20000000.
4. The device issues the transaction, the IOMMU translates it
   to 0x120000000, and it hits the right physical memory.

On macOS, step 2 is missing.  The DriverKit APIs don't provide
a way to program arbitrary IOVA-to-HPA translations into DART.
You can only hand a buffer to PrepareForDMA and get back whatever
IOVA the system assigns.

On top of that, the platform limits the total amount of DMA-mapped
memory to roughly 1.5 GB across ~64k mappings, so you can't even
map all of a 2 GB guest's RAM.  I believe this limit comes from
the host device tree and isn't modifiable by users, though it
could potentially be changed by Apple in firmware.

A vIOMMU could reduce the amount of memory that needs to be
mapped (only what the guest actually uses for DMA, not all of
guest RAM), but fundamentally you still need something akin to
step 2 to make the device's physical DMA transactions land at
the right addresses, and we don't have that on this platform.