[{"id":3673564,"web_url":"http://patchwork.ozlabs.org/comment/3673564/","msgid":"","list_archive_url":null,"date":"2026-04-05T08:01:09","subject":"Re: [RFC PATCH 00/10] vfio: PCI device passthrough on Apple Silicon\n Macs","submitter":{"id":91318,"url":"http://patchwork.ozlabs.org/api/people/91318/","name":"Mohamed Mediouni","email":"mohamed@unpredictable.fr"},"content":"> On 5. Apr 2026, at 09:28, Scott J. Goldman wrote:\n> \n> This series adds VFIO PCI device passthrough support for Apple Silicon\n> Macs running macOS, using a DriverKit extension (dext) as the host\n> backend instead of the Linux VFIO kernel driver.\n> \n> I'm sending this as an RFC because I'd like feedback before investing\n> further in upstreaming. The code is functional. I've tested it with\n> an NVIDIA RTX 5090 in a Thunderbolt dock on an M4 MacBook Air. GPU\n> gaming works but is slow (~30 fps on high settings in Cyberpunk 2077\n> [1]), likely due to the BAR access penalty described below. AI\n> inference workloads appear less affected. Ollama with Qwen 3.5\n> generates around 140 tok/sec on the same setup [2].\n> \n> How it works:\n> \n> On Linux, VFIO relies on kernel-managed IOMMU groups and /dev/vfio\n> for device access and DMA mapping. On macOS, there is no equivalent\n> kernel interface. Instead, a userspace DriverKit extension\n> (VFIOUserPCIDriver) mediates access to the physical PCI device through\n> IOKit's IOUserClient and PCIDriverKit APIs.\n> \n> The series keeps the existing VFIOPCIDevice model and reuses QEMU's\n> passthrough infrastructure. A few ioctl callsites are refactored into\n> io_ops callbacks, the build system is extended for Darwin, and the\n> Apple-specific backend plugs in behind those abstractions.\n> \n> The guest sees two PCI devices: the passthrough device itself\n> (vfio-apple-pci, which subclasses VFIOPCIDevice) and a companion\n> DMA mapping device (apple-dma-pci). On the QEMU side, an\n> AppleVFIOContainer implements the IOMMU backend, and a C client\n> library wraps the IOUserClient calls to the dext for config space,\n> BAR MMIO, interrupts, reset, and DMA.\n> \n> DMA limitations:\n> \n> This is the biggest platform constraint. Unlike a typical IOMMU\n> mapping operation where the caller specifies the IOVA, the\n> PCIDriverKit API (IODMACommand::PrepareForDMA) returns a\n> system-assigned IOVA. There is no way to request a specific address.\n> This means the guest's requested DMA addresses cannot be used\n> directly. The guest kernel module must intercept DMA mapping calls\n> and forward them through the companion device to get the actual\n> hardware IOVA.\n\nHello,\n\nUgh this one is not great. By the way, Apple has a private PCIe passthrough\nAPI used by Virtualization.framework but that’s a different design.\n\nWould bounce buffering using something akin the confidential compute path and \na pre-defined chunk of host memory accessible from the device, and then managing\nthe guest address map work? (see swiotlb).\n\nIf the last part isn’t possible, something minimal to export an swiotlb window\nthrough device tree with giving the IOVA there would be good too.\n\nAnd that will get rid of a need for a apple-dma-pci device.\n\n> There are also hard platform limits: approximately 1.5 GB total\n> mapped memory and roughly 64k concurrent mappings. Not all\n> workloads will fit within these limits, though GPU gaming and LLM\n> inference have worked in practice.\n\nThat’s not too dissimilar from the confidential compute limitations.\n\n> \n> BAR access has performance issues as well. HVF does not expose\n> controls to map device memory as cacheable in the guest, creating a\n> significant performance penalty on BAR MMIO. Uncached mappings work\n> correctly but slowly compared to what the hardware could do.\n\nThat’s not a macOS limitation and not an Apple hardware limitation, but\nit’s more fundamental to how PCIe works.\n\nUnlike CXL, PCIe doesn’t have a coherency protocol story, and the alternative\nof uncached and doing manual software-managed flushes isn’t really tenable.\n\n> \n> What works:\n> - PCI config space passthrough\n> - BAR MMIO via direct-mapped device memory\n> - MSI/MSI-X interrupts via async notification from the dext\n> - Device reset (FLR with hot-reset fallback)\n> - DMA mapping for guest device drivers\n> \nThis is very interesting to see :)\n\n> What doesn't work:\n> - Expansion ROM / VBIOS passthrough\n> - PCI BAR quirks\n> - VGA region passthrough\n> - Migration and dirty page tracking\n> - Hot-unplug\n> \n\n\n\n> Questions for reviewers:\n> \n> 1. Is this something the VFIO maintainers would consider carrying\n> upstream? The refactoring patches (3-6) are benign, but the Apple\n> backend is a new platform with real limitations. That said, if Apple\n> lifts some of the DART/HVF restrictions in a future macOS release, the\n> code changes to take advantage would likely be minor. I'd like to\n> understand whether this is in scope before doing the work to\n> address review feedback on the full series.\n> \n> 2. The apple-dma-pci companion device: should this be a virtio device\n> instead? I went with a simple custom PCI device because the virtio\n> infrastructure didn't buy much for what is essentially a {map, unmap}\n> register interface, but if virtio is preferred, what is the process\n> for allocating a device ID? If a custom PCI device is the right\n> approach, I've tentatively allocated 1b36:0015. Is there a process\n> for reserving a device ID under the Red Hat PCI vendor, or is\n> claiming it in pci-ids.rst sufficient? The guest-side kernel module\n> hooks all DMA mapping functions for passed-through devices, which is\n> unusual enough that I'm not sure it's upstreamable in the Linux\n> kernel. I can maintain it out of tree if needed.\n\nI’d recommend using bounce buffers like the CoCo case if possible. I don’t\nthink that the apple-dma-pci definitely-not-an-IOMMU is a good idea.\n\n> \n> 3. Should the macOS host-side DriverKit extension live in the QEMU\n> tree? It's not included in this series and requires Apple code\n> signing. I'm happy to keep it out of tree if that's preferred,\n> or include the source if reviewers want it co-located.\n\nBoth are fine I think. Could you share compatibility with the tinygrad\none at https://github.com/tinygrad/tinygrad/tree/7e54992bf600789dbe5d37b99fe12a19c32e36a1/extra/usbgpu/tbgpu/installer and prebuilt at https://raw.githubusercontent.com/tinygrad/tinygpu_releases/refs/heads/main/TinyGPU.zip?\n\n> \n> 4. The existing VFIO code includes from the\n> linux-headers/ tree, which is intended to track upstream Linux\n> UAPI headers. To make this compile on macOS, I added minimal\n> stub headers (include/compat/linux/types.h and linux/ioctl.h)\n> so the existing vfio.h parses on macOS without modification. An\n> alternative would be to move an approximation of vfio.h into\n> standard-headers/, but that felt against the spirit of tracking\n> the latest upstream headers, and the standard-headers import\n> process strips ioctls which the VFIO code relies on. I felt\n> the stub approach was the least invasive, but I'm open to\n> changing it if there's a preferred way to handle this.\n> \n> [1] https://imgur.com/a/xoRS9kT\n> [2] https://imgur.com/a/ui4pYF0\n> \n> Scott J. Goldman (10):\n> vfio/pci: Use the write side of EventNotifier for IRQ signaling\n> accel/hvf: avoid executable mappings for RAM-device memory\n> vfio: Allow building on Darwin hosts\n> vfio: Prepare existing code for Apple VFIO backend\n> vfio: Add region_map and region_unmap callbacks to VFIODeviceIOOps\n> vfio: Add device_reset callback to VFIODeviceIOOps\n> vfio/apple: Add DriverKit dext client library\n> vfio/apple: Add IOMMU container and PCI device\n> vfio/apple: Add apple-dma-pci companion device\n> docs: Add vfio-apple documentation and MAINTAINERS entry\n> \n> Kconfig.host | 3 +\n> MAINTAINERS | 11 +\n> accel/hvf/hvf-all.c | 10 +-\n> backends/Kconfig | 2 +-\n> docs/specs/pci-ids.rst | 3 +\n> docs/system/device-emulation.rst | 1 +\n> docs/system/devices/vfio-apple.rst | 160 +++++\n> hw/vfio-user/device.c | 16 +-\n> hw/vfio/Kconfig | 4 +-\n> hw/vfio/ap.c | 4 +-\n> hw/vfio/apple-device.c | 945 +++++++++++++++++++++++++++++\n> hw/vfio/apple-dext-client.c | 681 +++++++++++++++++++++\n> hw/vfio/apple-dext-client.h | 253 ++++++++\n> hw/vfio/apple-dma.c | 540 +++++++++++++++++\n> hw/vfio/apple.h | 74 +++\n> hw/vfio/ccw.c | 2 +-\n> hw/vfio/container-apple.c | 241 ++++++++\n> hw/vfio/device.c | 42 ++\n> hw/vfio/meson.build | 12 +-\n> hw/vfio/migration.c | 5 +-\n> hw/vfio/pci.c | 50 +-\n> hw/vfio/pci.h | 1 +\n> hw/vfio/region.c | 108 ++--\n> hw/vfio/types.h | 2 +\n> hw/vfio/vfio-helpers.h | 2 +-\n> hw/vfio/vfio-migration-internal.h | 4 +-\n> hw/vfio/vfio-region.h | 4 +\n> include/compat/linux/ioctl.h | 2 +\n> include/compat/linux/types.h | 26 +\n> include/hw/pci/pci.h | 1 +\n> include/hw/vfio/vfio-container.h | 1 +\n> include/hw/vfio/vfio-device.h | 40 +-\n> meson.build | 10 +-\n> util/event_notifier-posix.c | 5 +-\n> 34 files changed, 3197 insertions(+), 68 deletions(-)\n> create mode 100644 docs/system/devices/vfio-apple.rst\n> create mode 100644 hw/vfio/apple-device.c\n> create mode 100644 hw/vfio/apple-dext-client.c\n> create mode 100644 hw/vfio/apple-dext-client.h\n> create mode 100644 hw/vfio/apple-dma.c\n> create mode 100644 hw/vfio/apple.h\n> create mode 100644 hw/vfio/container-apple.c\n> create mode 100644 include/compat/linux/ioctl.h\n> create mode 100644 include/compat/linux/types.h\n> \n> -- \n> 2.50.1 (Apple Git-155)\n> \n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=unpredictable.fr header.i=@unpredictable.fr\n header.a=rsa-sha256 header.s=sig1 header.b=fMqAssiM;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists.gnu.org (lists.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fpXL21F59z1yG6\n\tfor ; Sun, 05 Apr 2026 22:47:36 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1w9Msc-0007JE-PQ; Sun, 05 Apr 2026 08:47:06 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1w9IQF-0003rh-Qt\n for qemu-devel@nongnu.org; Sun, 05 Apr 2026 04:01:31 -0400","from qs-2002k-snip4-11.eps.apple.com ([57.103.87.241]\n helo=outbound.qs.icloud.com)\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1w9IQC-0002JR-8q\n for qemu-devel@nongnu.org; Sun, 05 Apr 2026 04:01:31 -0400","from outbound.qs.icloud.com (unknown [127.0.0.2])\n by p00-icloudmta-asmtp-us-east-2d-60-percent-3 (Postfix) with ESMTPS id\n 46F8E180010D; Sun, 05 Apr 2026 08:01:23 +0000 (UTC)","from smtpclient.apple (unknown [17.57.155.37])\n by p00-icloudmta-asmtp-us-east-2d-60-percent-3 (Postfix) with ESMTPSA id\n 7AFF0180011F; Sun, 05 Apr 2026 08:01:21 +0000 (UTC)"],"Dkim-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=unpredictable.fr;\n s=sig1; t=1775376084; x=1777968084;\n bh=8Es/6+9gPDXLN3UzmgVQJF9Dhaeemfti9MTE7BPrtuo=;\n h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To:x-icloud-hme;\n b=fMqAssiMa2zUQp8UNNiOKpS2wcSJuvXLRXyET3R7alzKCIy0yTOCrL+BaTlzrxFJe6sp9Cqm0uvy4/4N/mp5fFk+9ZCyJBoeP4H5Aaxl4dFqAJV75j6MkuiXlRx9r4K/9dWEobX97Ppj9zTG1xWCpsB1UJw/qCaXECva91hiGJDWGArC9Z0O70tFysnv4a84RZ94gPP9V2d4B3WJKjmjoqfgulyPgqos23hDEnFN1Sdg9B2RegpdfeBxDOkTcnw3rRTW7xcEtObNmVAnA541RxYsU7VZ4hQJk56yvMrXDFvhlCQvJrIK80R/SHCvi1/vCjSlKEic9X69///axd5hyQ==","mail-alias-created-date":"1752046281608","Content-Type":"text/plain;\n\tcharset=utf-8","Mime-Version":"1.0 (Mac OS X Mail 16.0 \\(3864.500.181\\))","Subject":"Re: [RFC PATCH 00/10] vfio: PCI device passthrough on Apple Silicon\n Macs","From":"Mohamed Mediouni ","In-Reply-To":"<20260405072857.66484-1-scottjgo@gmail.com>","Date":"Sun, 5 Apr 2026 10:01:09 +0200","Cc":"qemu-devel@nongnu.org, alex@shazbot.org, clg@redhat.com,\n pbonzini@redhat.com, rbolshakov@ddn.com, phil@philjordan.eu,\n mst@redhat.com, john.levon@nutanix.com, thanos.makatos@nutanix.com,\n qemu-s390x@nongnu.org","Content-Transfer-Encoding":"quoted-printable","Message-Id":"","References":"<20260405072857.66484-1-scottjgo@gmail.com>","To":"\"Scott J. Goldman\" ","X-Mailer":"Apple Mail (2.3864.500.181)","X-Proofpoint-Spam-Details-Enc":"AW1haW4tMjYwNDA1MDA3OSBTYWx0ZWRfX8FWYZH+ehtm3\n 9PyPR1kLlR2MOIG1ljySnHAC2Mrr3zGP1Huyjcqy1co7H58p/tVxXCPROz3dS6SDjoVIjvvQmHr\n kcib/FZG/isvL6CAtudmgPAZcdWjBL3tyfvqYzaHQ2fr+p6z792AmS136oYX1JtcwAp9CZz31w1\n +Ik8LgN9Vdq0UTloxG9jSH1i4B5y6bKtvoXOlm20tJucdS2e2FgPIXlEyF05q22S836sVr6J0id\n pCQWYLCctKAHAj+lFzFl4/ETONV4E6adMLVoOiuLKBi+nWsLHug0qL1vn8EvXxWXHCDGuaco3eL\n Mz21k2Qj5WKNpU9UZRQi655PI0Ch79R29+Ar/vvsA+RKthag83RXCr1EKmv6y4=","X-Authority-Info-Out":"v=2.4 cv=RvHI7SmK c=1 sm=1 tr=0 ts=69d216d3\n cx=c_apl:c_pps:t_out a=bsP7O+dXZ5uKcj+dsLqiMw==:117\n a=bsP7O+dXZ5uKcj+dsLqiMw==:17 a=IkcTkHD0fZMA:10 a=A5OVakUREuEA:10\n a=VkNPw1HP01LnGYTKEx00:22 a=NEAV23lmAAAA:8 a=aA-33HkQAAAA:20\n a=TkNuIPFPAAAA:20 a=WVbz653JAAAA:20 a=pGLkceISAAAA:8 a=fBi0ZN_dAYJaTxULY8EA:9\n a=QEXdDO2ut3YA:10 a=bA3UWDv6hWIuX7UZL3qL:22 a=gGywIldwKSjjSr1hpRws:22","X-Proofpoint-GUID":"ICjKYS-jLeD6pXPEgbUe0XlSGd8IoG4z","X-Proofpoint-ORIG-GUID":"ICjKYS-jLeD6pXPEgbUe0XlSGd8IoG4z","X-Proofpoint-Virus-Version":"vendor=baseguard\n engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49\n definitions=2026-04-05_03,2026-04-03_01,2025-10-01_01","X-Proofpoint-Spam-Details":"rule=notspam policy=default score=0 phishscore=0\n lowpriorityscore=0 adultscore=0 malwarescore=0 mlxscore=0 bulkscore=0\n mlxlogscore=999 spamscore=0 clxscore=1030 suspectscore=0 classifier=spam\n authscore=0 adjust=0 reason=mlx scancount=1 engine=8.22.0-2601150000\n definitions=main-2604050079","Received-SPF":"pass client-ip=57.103.87.241;\n envelope-from=mohamed@unpredictable.fr; helo=outbound.qs.icloud.com","X-Spam_score_int":"-14","X-Spam_score":"-1.5","X-Spam_bar":"-","X-Spam_report":"(-1.5 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,\n DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,\n RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_LOW=-0.7,\n RCVD_IN_MSPIKE_H5=0.001,\n RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001,\n RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001,\n SPF_PASS=-0.001 autolearn=no autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"qemu development ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}},{"id":3673565,"web_url":"http://patchwork.ozlabs.org/comment/3673565/","msgid":"","list_archive_url":null,"date":"2026-04-05T08:14:04","subject":"Re: [RFC PATCH 00/10] vfio: PCI device passthrough on Apple Silicon\n Macs","submitter":{"id":91318,"url":"http://patchwork.ozlabs.org/api/people/91318/","name":"Mohamed Mediouni","email":"mohamed@unpredictable.fr"},"content":"> On 5. Apr 2026, at 10:01, Mohamed Mediouni wrote:\n> \n>> \n>> On 5. Apr 2026, at 09:28, Scott J. Goldman wrote:\n>> \n>> This series adds VFIO PCI device passthrough support for Apple Silicon\n>> Macs running macOS, using a DriverKit extension (dext) as the host\n>> backend instead of the Linux VFIO kernel driver.\n>> \n>> I'm sending this as an RFC because I'd like feedback before investing\n>> further in upstreaming. The code is functional. I've tested it with\n>> an NVIDIA RTX 5090 in a Thunderbolt dock on an M4 MacBook Air. GPU\n>> gaming works but is slow (~30 fps on high settings in Cyberpunk 2077\n>> [1]), likely due to the BAR access penalty described below. AI\n>> inference workloads appear less affected. Ollama with Qwen 3.5\n>> generates around 140 tok/sec on the same setup [2].\n>> \n>> How it works:\n>> \n>> On Linux, VFIO relies on kernel-managed IOMMU groups and /dev/vfio\n>> for device access and DMA mapping. On macOS, there is no equivalent\n>> kernel interface. Instead, a userspace DriverKit extension\n>> (VFIOUserPCIDriver) mediates access to the physical PCI device through\n>> IOKit's IOUserClient and PCIDriverKit APIs.\n>> \n>> The series keeps the existing VFIOPCIDevice model and reuses QEMU's\n>> passthrough infrastructure. A few ioctl callsites are refactored into\n>> io_ops callbacks, the build system is extended for Darwin, and the\n>> Apple-specific backend plugs in behind those abstractions.\n>> \n>> The guest sees two PCI devices: the passthrough device itself\n>> (vfio-apple-pci, which subclasses VFIOPCIDevice) and a companion\n>> DMA mapping device (apple-dma-pci). On the QEMU side, an\n>> AppleVFIOContainer implements the IOMMU backend, and a C client\n>> library wraps the IOUserClient calls to the dext for config space,\n>> BAR MMIO, interrupts, reset, and DMA.\n>> \n>> DMA limitations:\n>> \n>> This is the biggest platform constraint. Unlike a typical IOMMU\n>> mapping operation where the caller specifies the IOVA, the\n>> PCIDriverKit API (IODMACommand::PrepareForDMA) returns a\n>> system-assigned IOVA. There is no way to request a specific address.\n>> This means the guest's requested DMA addresses cannot be used\n>> directly. The guest kernel module must intercept DMA mapping calls\n>> and forward them through the companion device to get the actual\n>> hardware IOVA.\n> \n> Hello,\n> \n> Ugh this one is not great. By the way, Apple has a private PCIe passthrough\n> API used by Virtualization.framework but that’s a different design.\n> \n> Would bounce buffering using something akin the confidential compute path and \n> a pre-defined chunk of host memory accessible from the device, and then managing\n> the guest address map work? (see swiotlb).\n\nsee restricted-dma-pool\n\nI think in this specific case that ACPI support isn’t worth it and that FDT\nwill be good enough.\n\nThe limitation that I can see there if if you can’t match IOVA and GPA for that\nrestricted DMA pool, then you’ll need a small (and hopefully easy to merge) kernel\nchange.\n\n> \n> If the last part isn’t possible, something minimal to export an swiotlb window\n> through device tree with giving the IOVA there would be good too.\n> \n> And that will get rid of a need for a apple-dma-pci device.\n\n\n> \n>> There are also hard platform limits: approximately 1.5 GB total\n>> mapped memory and roughly 64k concurrent mappings. Not all\n>> workloads will fit within these limits, though GPU gaming and LLM\n>> inference have worked in practice.\n> \n> That’s not too dissimilar from the confidential compute limitations.\n> \n>> \n>> BAR access has performance issues as well. HVF does not expose\n>> controls to map device memory as cacheable in the guest, creating a\n>> significant performance penalty on BAR MMIO. Uncached mappings work\n>> correctly but slowly compared to what the hardware could do.\n> \n> That’s not a macOS limitation and not an Apple hardware limitation, but\n> it’s more fundamental to how PCIe works.\n> \n> Unlike CXL, PCIe doesn’t have a coherency protocol story, and the alternative\n> of uncached and doing manual software-managed flushes isn’t really tenable.\n> \n>> \n>> What works:\n>> - PCI config space passthrough\n>> - BAR MMIO via direct-mapped device memory\n>> - MSI/MSI-X interrupts via async notification from the dext\n>> - Device reset (FLR with hot-reset fallback)\n>> - DMA mapping for guest device drivers\n>> \n> This is very interesting to see :)\n> \n>> What doesn't work:\n>> - Expansion ROM / VBIOS passthrough\n>> - PCI BAR quirks\n>> - VGA region passthrough\n>> - Migration and dirty page tracking\n>> - Hot-unplug\n>> \n> \n> \n> \n>> Questions for reviewers:\n>> \n>> 1. Is this something the VFIO maintainers would consider carrying\n>> upstream? The refactoring patches (3-6) are benign, but the Apple\n>> backend is a new platform with real limitations. That said, if Apple\n>> lifts some of the DART/HVF restrictions in a future macOS release, the\n>> code changes to take advantage would likely be minor. I'd like to\n>> understand whether this is in scope before doing the work to\n>> address review feedback on the full series.\n>> \n>> 2. The apple-dma-pci companion device: should this be a virtio device\n>> instead? I went with a simple custom PCI device because the virtio\n>> infrastructure didn't buy much for what is essentially a {map, unmap}\n>> register interface, but if virtio is preferred, what is the process\n>> for allocating a device ID? If a custom PCI device is the right\n>> approach, I've tentatively allocated 1b36:0015. Is there a process\n>> for reserving a device ID under the Red Hat PCI vendor, or is\n>> claiming it in pci-ids.rst sufficient? The guest-side kernel module\n>> hooks all DMA mapping functions for passed-through devices, which is\n>> unusual enough that I'm not sure it's upstreamable in the Linux\n>> kernel. I can maintain it out of tree if needed.\n> \n> I’d recommend using bounce buffers like the CoCo case if possible. I don’t\n> think that the apple-dma-pci definitely-not-an-IOMMU is a good idea.\n> \n>> \n>> 3. Should the macOS host-side DriverKit extension live in the QEMU\n>> tree? It's not included in this series and requires Apple code\n>> signing. I'm happy to keep it out of tree if that's preferred,\n>> or include the source if reviewers want it co-located.\n> \n> Both are fine I think. Could you share compatibility with the tinygrad\n> one at https://github.com/tinygrad/tinygrad/tree/7e54992bf600789dbe5d37b99fe12a19c32e36a1/extra/usbgpu/tbgpu/installer and prebuilt at https://raw.githubusercontent.com/tinygrad/tinygpu_releases/refs/heads/main/TinyGPU.zip?\n> \n>> \n>> 4. The existing VFIO code includes from the\n>> linux-headers/ tree, which is intended to track upstream Linux\n>> UAPI headers. To make this compile on macOS, I added minimal\n>> stub headers (include/compat/linux/types.h and linux/ioctl.h)\n>> so the existing vfio.h parses on macOS without modification. An\n>> alternative would be to move an approximation of vfio.h into\n>> standard-headers/, but that felt against the spirit of tracking\n>> the latest upstream headers, and the standard-headers import\n>> process strips ioctls which the VFIO code relies on. I felt\n>> the stub approach was the least invasive, but I'm open to\n>> changing it if there's a preferred way to handle this.\n>> \n>> [1] https://imgur.com/a/xoRS9kT\n>> [2] https://imgur.com/a/ui4pYF0\n>> \n>> Scott J. Goldman (10):\n>> vfio/pci: Use the write side of EventNotifier for IRQ signaling\n>> accel/hvf: avoid executable mappings for RAM-device memory\n>> vfio: Allow building on Darwin hosts\n>> vfio: Prepare existing code for Apple VFIO backend\n>> vfio: Add region_map and region_unmap callbacks to VFIODeviceIOOps\n>> vfio: Add device_reset callback to VFIODeviceIOOps\n>> vfio/apple: Add DriverKit dext client library\n>> vfio/apple: Add IOMMU container and PCI device\n>> vfio/apple: Add apple-dma-pci companion device\n>> docs: Add vfio-apple documentation and MAINTAINERS entry\n>> \n>> Kconfig.host | 3 +\n>> MAINTAINERS | 11 +\n>> accel/hvf/hvf-all.c | 10 +-\n>> backends/Kconfig | 2 +-\n>> docs/specs/pci-ids.rst | 3 +\n>> docs/system/device-emulation.rst | 1 +\n>> docs/system/devices/vfio-apple.rst | 160 +++++\n>> hw/vfio-user/device.c | 16 +-\n>> hw/vfio/Kconfig | 4 +-\n>> hw/vfio/ap.c | 4 +-\n>> hw/vfio/apple-device.c | 945 +++++++++++++++++++++++++++++\n>> hw/vfio/apple-dext-client.c | 681 +++++++++++++++++++++\n>> hw/vfio/apple-dext-client.h | 253 ++++++++\n>> hw/vfio/apple-dma.c | 540 +++++++++++++++++\n>> hw/vfio/apple.h | 74 +++\n>> hw/vfio/ccw.c | 2 +-\n>> hw/vfio/container-apple.c | 241 ++++++++\n>> hw/vfio/device.c | 42 ++\n>> hw/vfio/meson.build | 12 +-\n>> hw/vfio/migration.c | 5 +-\n>> hw/vfio/pci.c | 50 +-\n>> hw/vfio/pci.h | 1 +\n>> hw/vfio/region.c | 108 ++--\n>> hw/vfio/types.h | 2 +\n>> hw/vfio/vfio-helpers.h | 2 +-\n>> hw/vfio/vfio-migration-internal.h | 4 +-\n>> hw/vfio/vfio-region.h | 4 +\n>> include/compat/linux/ioctl.h | 2 +\n>> include/compat/linux/types.h | 26 +\n>> include/hw/pci/pci.h | 1 +\n>> include/hw/vfio/vfio-container.h | 1 +\n>> include/hw/vfio/vfio-device.h | 40 +-\n>> meson.build | 10 +-\n>> util/event_notifier-posix.c | 5 +-\n>> 34 files changed, 3197 insertions(+), 68 deletions(-)\n>> create mode 100644 docs/system/devices/vfio-apple.rst\n>> create mode 100644 hw/vfio/apple-device.c\n>> create mode 100644 hw/vfio/apple-dext-client.c\n>> create mode 100644 hw/vfio/apple-dext-client.h\n>> create mode 100644 hw/vfio/apple-dma.c\n>> create mode 100644 hw/vfio/apple.h\n>> create mode 100644 hw/vfio/container-apple.c\n>> create mode 100644 include/compat/linux/ioctl.h\n>> create mode 100644 include/compat/linux/types.h\n>> \n>> -- \n>> 2.50.1 (Apple Git-155)","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=unpredictable.fr header.i=@unpredictable.fr\n header.a=rsa-sha256 header.s=sig1 header.b=WgXVkbTM;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists.gnu.org (lists.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fpXL217Bqz1y2d\n\tfor ; Sun, 05 Apr 2026 22:47:36 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1w9Msb-0007Hp-8m; Sun, 05 Apr 2026 08:47:05 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1w9Icl-0000Ke-Oo\n for qemu-devel@nongnu.org; Sun, 05 Apr 2026 04:14:27 -0400","from p-east2-cluster2-host5-snip4-6.eps.apple.com ([57.103.78.29]\n helo=outbound.st.icloud.com)\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1w9Ici-0003ox-Dm\n for qemu-devel@nongnu.org; Sun, 05 Apr 2026 04:14:27 -0400","from outbound.st.icloud.com (unknown [127.0.0.2])\n by p00-icloudmta-asmtp-us-east-1a-100-percent-11 (Postfix) with ESMTPS id\n D449618000B3; Sun, 05 Apr 2026 08:14:18 +0000 (UTC)","from smtpclient.apple (unknown [17.42.251.67])\n by p00-icloudmta-asmtp-us-east-1a-100-percent-11 (Postfix) with ESMTPSA id\n 6CCDD1800132; Sun, 05 Apr 2026 08:14:16 +0000 (UTC)"],"Dkim-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=unpredictable.fr;\n s=sig1; t=1775376862; x=1777968862;\n bh=t5etCBDR7EazSSH0eWPCNxNxGBcZZBPfuPCbddhssJc=;\n h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To:x-icloud-hme;\n b=WgXVkbTMbVVxCuMjL/LVF98VkmrbOI4fQSKN+RoMG5Fp+RntmA2AZtJxbye72SXlFCGRHB5ktBkgBrNPQJyeGgHb/rqf7F9+cmr4W8o4Dbyta+nkRlW9yQYENUrkhkVnAWXWmV4XDOOznVMcigvGT4ZgqH/x2PiSV/kvltNeBtsO/UHQGwRROAz3IdmxLsdkb+kAi4kryE8SR89jPz0CFEQatRrjjY1kqF2lMfWC/O4mPAQrDkO0FQKYk4IEZVpY5DXbkP51jBclD/GiQic1s5H8Lq69LnBTGjiblxmnLKGSuNNBlsrkSN+lWB7kOUnwwnxJE+SwTTjY/fwEdABlmQ==","mail-alias-created-date":"1752046281608","Content-Type":"text/plain;\n\tcharset=utf-8","Mime-Version":"1.0 (Mac OS X Mail 16.0 \\(3864.500.181\\))","Subject":"Re: [RFC PATCH 00/10] vfio: PCI device passthrough on Apple Silicon\n Macs","From":"Mohamed Mediouni ","In-Reply-To":"","Date":"Sun, 5 Apr 2026 10:14:04 +0200","Cc":"qemu-devel@nongnu.org, alex@shazbot.org, clg@redhat.com,\n pbonzini@redhat.com, rbolshakov@ddn.com, phil@philjordan.eu,\n mst@redhat.com, john.levon@nutanix.com, thanos.makatos@nutanix.com,\n qemu-s390x@nongnu.org","Content-Transfer-Encoding":"quoted-printable","Message-Id":"","References":"<20260405072857.66484-1-scottjgo@gmail.com>\n ","To":"\"Scott J. Goldman\" ","X-Mailer":"Apple Mail (2.3864.500.181)","X-Proofpoint-Spam-Details-Enc":"AW1haW4tMjYwNDA1MDA4MSBTYWx0ZWRfXzrrOHq/EHvep\n SlGkUtR7nV5WL9Ss7nr90JAKDdNhKbKAf+0mohzzkiAjbxnLJdlgU2xIIYIuMrSB8AkUN2RVHSB\n aueq048BXa5FC//ykR6iuiRsiaMCsf6ZO2/A1dqgNr8pE4E9/MIl4tfKN/bu1jBkBHsccTbUkS7\n VULHWciBRWs9yfKSZNkVG0WAO0wMIIg45P2wlaGE75QYgqJ/YT7ZMqr8shRkiw/BQ8ZBpsX69dZ\n UlQXo/QE7VH5BZoH3PxLnHvPHCf7QROk0+L/1nXMkJFoBaSAnUZa2gNcdU1whgQrzK9e6kbjQ+u\n CyzevJajDaxYNYxmEhrlDH6pv/iO9YG+vtfZQUNbTHnaT4Tnx/ArL13blPhHS8=","X-Proofpoint-ORIG-GUID":"Od60q3nDY_hGaJy05yU4o1RDVo3AjYgt","X-Proofpoint-GUID":"Od60q3nDY_hGaJy05yU4o1RDVo3AjYgt","X-Authority-Info-Out":"v=2.4 cv=BefVE7t2 c=1 sm=1 tr=0 ts=69d219dc\n cx=c_apl:c_pps:t_out a=YrL12D//S6tul8v/L+6tKg==:117\n a=YrL12D//S6tul8v/L+6tKg==:17 a=IkcTkHD0fZMA:10 a=A5OVakUREuEA:10\n a=VkNPw1HP01LnGYTKEx00:22 a=NEAV23lmAAAA:8 a=aA-33HkQAAAA:20\n a=TkNuIPFPAAAA:20 a=WVbz653JAAAA:20 a=pGLkceISAAAA:8 a=mZfonHcMw-UIrJ9WzQwA:9\n a=QEXdDO2ut3YA:10 a=bA3UWDv6hWIuX7UZL3qL:22 a=gGywIldwKSjjSr1hpRws:22","X-Proofpoint-Virus-Version":"vendor=baseguard\n engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49\n definitions=2026-04-05_03,2026-04-03_01,2025-10-01_01","X-Proofpoint-Spam-Details":"rule=notspam policy=default score=0 malwarescore=0\n mlxscore=0 phishscore=0 bulkscore=0 clxscore=1030\n spamscore=0 mlxlogscore=999\n adultscore=0 suspectscore=0 lowpriorityscore=0 classifier=spam authscore=0\n adjust=0 reason=mlx scancount=1 engine=8.22.0-2601150000\n definitions=main-2604050081","Received-SPF":"pass client-ip=57.103.78.29;\n envelope-from=mohamed@unpredictable.fr; helo=outbound.st.icloud.com","X-Spam_score_int":"-20","X-Spam_score":"-2.1","X-Spam_bar":"--","X-Spam_report":"(-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,\n DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,\n RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001,\n SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"qemu development ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}},{"id":3673566,"web_url":"http://patchwork.ozlabs.org/comment/3673566/","msgid":"","list_archive_url":null,"date":"2026-04-05T10:36:50","subject":"Re: [RFC PATCH 00/10] vfio: PCI device passthrough on Apple Silicon\n Macs","submitter":{"id":16148,"url":"http://patchwork.ozlabs.org/api/people/16148/","name":"BALATON Zoltan","email":"balaton@eik.bme.hu"},"content":"On Sun, 5 Apr 2026, Scott J. Goldman wrote:\n> This series adds VFIO PCI device passthrough support for Apple Silicon\n> Macs running macOS, using a DriverKit extension (dext) as the host\n> backend instead of the Linux VFIO kernel driver.\n>\n> I'm sending this as an RFC because I'd like feedback before investing\n> further in upstreaming. The code is functional. I've tested it with\n> an NVIDIA RTX 5090 in a Thunderbolt dock on an M4 MacBook Air. GPU\n> gaming works but is slow (~30 fps on high settings in Cyberpunk 2077\n> [1]), likely due to the BAR access penalty described below. AI\n> inference workloads appear less affected. Ollama with Qwen 3.5\n> generates around 140 tok/sec on the same setup [2].\n>\n> How it works:\n>\n> On Linux, VFIO relies on kernel-managed IOMMU groups and /dev/vfio\n> for device access and DMA mapping. On macOS, there is no equivalent\n> kernel interface. Instead, a userspace DriverKit extension\n> (VFIOUserPCIDriver) mediates access to the physical PCI device through\n> IOKit's IOUserClient and PCIDriverKit APIs.\n>\n> The series keeps the existing VFIOPCIDevice model and reuses QEMU's\n> passthrough infrastructure. A few ioctl callsites are refactored into\n> io_ops callbacks, the build system is extended for Darwin, and the\n> Apple-specific backend plugs in behind those abstractions.\n>\n> The guest sees two PCI devices: the passthrough device itself\n> (vfio-apple-pci, which subclasses VFIOPCIDevice) and a companion\n> DMA mapping device (apple-dma-pci). On the QEMU side, an\n> AppleVFIOContainer implements the IOMMU backend, and a C client\n> library wraps the IOUserClient calls to the dext for config space,\n> BAR MMIO, interrupts, reset, and DMA.\n>\n> DMA limitations:\n>\n> This is the biggest platform constraint. Unlike a typical IOMMU\n> mapping operation where the caller specifies the IOVA, the\n> PCIDriverKit API (IODMACommand::PrepareForDMA) returns a\n> system-assigned IOVA. There is no way to request a specific address.\n> This means the guest's requested DMA addresses cannot be used\n> directly. The guest kernel module must intercept DMA mapping calls\n> and forward them through the companion device to get the actual\n> hardware IOVA.\n\nI don't know this so what I say might not make sense but I think there is \niommu emulation in QEMU so could that be used to do this in QEMU and avoid \nneeding a kernel module for it in the guest?\n\nRegards,\nBALATON Zoltan","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":"legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)","Received":["from lists.gnu.org (lists.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fpXLt5gVnz1y2d\n\tfor ; Sun, 05 Apr 2026 22:48:22 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1w9Msd-0007JC-9P; Sun, 05 Apr 2026 08:47:07 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1w9Kqj-00088v-IH; Sun, 05 Apr 2026 06:37:01 -0400","from zero.eik.bme.hu ([2001:738:2001:2001::2001])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1w9Kqh-0001rp-7q; Sun, 05 Apr 2026 06:37:01 -0400","from localhost (localhost [127.0.0.1])\n by zero.eik.bme.hu (Postfix) with ESMTP id 8DCD85969F9;\n Sun, 05 Apr 2026 12:36:52 +0200 (CEST)","from zero.eik.bme.hu ([127.0.0.1])\n by localhost (zero.eik.bme.hu [127.0.0.1]) (amavis, port 10028) with ESMTP\n id TU9sGq3toNMD; Sun, 5 Apr 2026 12:36:50 +0200 (CEST)","by zero.eik.bme.hu (Postfix, from userid 432)\n id 757485969F6; Sun, 05 Apr 2026 12:36:50 +0200 (CEST)","from localhost (localhost [127.0.0.1])\n by zero.eik.bme.hu (Postfix) with ESMTP id 736F95968DE;\n Sun, 05 Apr 2026 12:36:50 +0200 (CEST)"],"X-Virus-Scanned":"amavis at eik.bme.hu","Date":"Sun, 5 Apr 2026 12:36:50 +0200 (CEST)","From":"BALATON Zoltan ","To":"\"Scott J. Goldman\" ","cc":"qemu-devel@nongnu.org, alex@shazbot.org, clg@redhat.com,\n pbonzini@redhat.com, rbolshakov@ddn.com, phil@philjordan.eu,\n mst@redhat.com, john.levon@nutanix.com, thanos.makatos@nutanix.com,\n qemu-s390x@nongnu.org","Subject":"Re: [RFC PATCH 00/10] vfio: PCI device passthrough on Apple Silicon\n Macs","In-Reply-To":"<20260405072857.66484-1-scottjgo@gmail.com>","Message-ID":"","References":"<20260405072857.66484-1-scottjgo@gmail.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII; format=flowed","Received-SPF":"pass client-ip=2001:738:2001:2001::2001;\n envelope-from=balaton@eik.bme.hu; helo=zero.eik.bme.hu","X-Spam_score_int":"-18","X-Spam_score":"-1.9","X-Spam_bar":"-","X-Spam_report":"(-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001,\n SPF_PASS=-0.001 autolearn=ham autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"qemu development ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}},{"id":3673588,"web_url":"http://patchwork.ozlabs.org/comment/3673588/","msgid":"","list_archive_url":null,"date":"2026-04-05T18:16:34","subject":"Re: [RFC PATCH 00/10] vfio: PCI device passthrough on Apple Silicon\n Macs","submitter":{"id":93060,"url":"http://patchwork.ozlabs.org/api/people/93060/","name":"Scott J. Goldman","email":"scottjgo@gmail.com"},"content":"On Sun Apr 5, 2026 at 3:36 AM PDT, BALATON Zoltan wrote:\n> On Sun, 5 Apr 2026, Scott J. Goldman wrote:\n>> This series adds VFIO PCI device passthrough support for Apple Silicon\n>> Macs running macOS, using a DriverKit extension (dext) as the host\n>> backend instead of the Linux VFIO kernel driver.\n>>\n>> I'm sending this as an RFC because I'd like feedback before investing\n>> further in upstreaming. The code is functional. I've tested it with\n>> an NVIDIA RTX 5090 in a Thunderbolt dock on an M4 MacBook Air. GPU\n>> gaming works but is slow (~30 fps on high settings in Cyberpunk 2077\n>> [1]), likely due to the BAR access penalty described below. AI\n>> inference workloads appear less affected. Ollama with Qwen 3.5\n>> generates around 140 tok/sec on the same setup [2].\n>>\n>> How it works:\n>>\n>> On Linux, VFIO relies on kernel-managed IOMMU groups and /dev/vfio\n>> for device access and DMA mapping. On macOS, there is no equivalent\n>> kernel interface. Instead, a userspace DriverKit extension\n>> (VFIOUserPCIDriver) mediates access to the physical PCI device through\n>> IOKit's IOUserClient and PCIDriverKit APIs.\n>>\n>> The series keeps the existing VFIOPCIDevice model and reuses QEMU's\n>> passthrough infrastructure. A few ioctl callsites are refactored into\n>> io_ops callbacks, the build system is extended for Darwin, and the\n>> Apple-specific backend plugs in behind those abstractions.\n>>\n>> The guest sees two PCI devices: the passthrough device itself\n>> (vfio-apple-pci, which subclasses VFIOPCIDevice) and a companion\n>> DMA mapping device (apple-dma-pci). On the QEMU side, an\n>> AppleVFIOContainer implements the IOMMU backend, and a C client\n>> library wraps the IOUserClient calls to the dext for config space,\n>> BAR MMIO, interrupts, reset, and DMA.\n>>\n>> DMA limitations:\n>>\n>> This is the biggest platform constraint. Unlike a typical IOMMU\n>> mapping operation where the caller specifies the IOVA, the\n>> PCIDriverKit API (IODMACommand::PrepareForDMA) returns a\n>> system-assigned IOVA. There is no way to request a specific address.\n>> This means the guest's requested DMA addresses cannot be used\n>> directly. The guest kernel module must intercept DMA mapping calls\n>> and forward them through the companion device to get the actual\n>> hardware IOVA.\n>\n> I don't know this so what I say might not make sense but I think there is \n> iommu emulation in QEMU so could that be used to do this in QEMU and avoid \n> needing a kernel module for it in the guest?\n>\n> Regards,\n> BALATON Zoltan\n\nI think the challenge is that this is a passthrough device doing\nDMA directly on the physical PCIe bus. The device's DMA\ntransactions go through the real hardware IOMMU (DART), not\nthrough QEMU.\n\nIf the guest programs the device with IOVA 0x1000 (assigned by\na virtual IOMMU), the device will issue a DMA read for 0x1000 on\nthe physical bus. But DART only knows about the IOVAs that\nPrepareForDMA assigned, so the transaction would fault.\n\nMy understanding is that on other platforms, this is handled in\na simpler way because the host IOMMU can be programmed directly:\n\n1. Guest boots with 2 GB of RAM. QEMU maps guest physical\n address (GPA) 0x10000000-0x90000000 to host physical memory\n at, say, 0x110000000-0x190000000.\n2. QEMU programs the host IOMMU so the device's view of\n 0x10000000-0x90000000 translates to the real host addresses.\n3. Guest programs the PCI device to DMA to GPA 0x20000000.\n4. The device issues the transaction, the IOMMU translates it\n to 0x120000000, and it hits the right physical memory.\n\nOn macOS, step 2 is missing. The DriverKit APIs don't provide\na way to program arbitrary IOVA-to-HPA translations into DART.\nYou can only hand a buffer to PrepareForDMA and get back whatever\nIOVA the system assigns.\n\nOn top of that, the platform limits the total amount of DMA-mapped\nmemory to roughly 1.5 GB across ~64k mappings, so you can't even\nmap all of a 2 GB guest's RAM. I believe this limit comes from\nthe host device tree and isn't modifiable by users, though it\ncould potentially be changed by Apple in firmware.\n\nA vIOMMU could reduce the amount of memory that needs to be\nmapped (only what the guest actually uses for DMA, not all of\nguest RAM), but fundamentally you still need something akin to\nstep 2 to make the device's physical DMA transactions land at\nthe right addresses, and we don't have that on this platform.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=XLEl8Phs;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists.gnu.org (lists.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fpgfJ2Vqpz1xtJ\n\tfor ; Mon, 06 Apr 2026 04:17:12 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1w9S1f-0003vZ-Gz; Sun, 05 Apr 2026 14:16:47 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1w9S1X-0003uF-T3\n for qemu-devel@nongnu.org; Sun, 05 Apr 2026 14:16:40 -0400","from mail-dy1-x1336.google.com ([2607:f8b0:4864:20::1336])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)\n (Exim 4.90_1) (envelope-from )\n id 1w9S1W-0004TY-2w\n for qemu-devel@nongnu.org; Sun, 05 Apr 2026 14:16:39 -0400","by mail-dy1-x1336.google.com with SMTP id\n 5a478bee46e88-2ce7d6fd2c5so193818eec.0\n for ; Sun, 05 Apr 2026 11:16:37 -0700 (PDT)","from localhost ([2601:645:8200:47:d85c:429c:5cc7:1e52])\n by smtp.gmail.com with ESMTPSA id\n 5a478bee46e88-2ca760b0518sm11397906eec.0.2026.04.05.11.16.35\n (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n Sun, 05 Apr 2026 11:16:35 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=gmail.com; s=20251104; t=1775412996; x=1776017796; darn=nongnu.org;\n h=in-reply-to:references:cc:to:from:subject:message-id:date\n :content-transfer-encoding:mime-version:from:to:cc:subject:date\n :message-id:reply-to;\n bh=3m1Z4UTUM6w2aqa7uxC+K1wnAqGBXUYvLkMEl2uyZKo=;\n b=XLEl8Phs8eevmKPZh+RBc5+7eq8b9N2BFAEI2v6gwPQsk81nT1TfcO5DLcrkQDpYEM\n aRqALBq4azYVfi1G5Ily8scqYNH8KrinsNgaRQYTmX/tCwgPRGkyd2CLNCmBi/6W00qx\n p+/l9DOioV4zAs5LTieT/1EZjq2eIvRpvI3FDoH0yrXjQlXrllTNgJaP1xZSlJAtpYm1\n 9L7mOuvlf7wdmbOB9vy4gsMvC2gqnBr2A6cKEkUDW1rXj6QOC/l8J8nsn+0T/vNXoVw6\n 0+Qdb8V0EHNHhb/awCDkkU6wTZnNxsyA8uHWXIgoxLJBPZg1TZ0GWMefo8UgrBOJA3+c\n fswA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1775412996; x=1776017796;\n h=in-reply-to:references:cc:to:from:subject:message-id:date\n :content-transfer-encoding:mime-version:x-gm-gg:x-gm-message-state\n :from:to:cc:subject:date:message-id:reply-to;\n bh=3m1Z4UTUM6w2aqa7uxC+K1wnAqGBXUYvLkMEl2uyZKo=;\n b=SUN+Z76fCq9nUPDP7QLVo8jKhE77IT9SfPk+92zdOo+MrzeP6sWABDMV4ZSv+OHvCD\n GQ0U5/DsHLo4uamqXDPLJwFQnqD6+hMznGELy1PIWdJcKoskIyUKhQkqPaIeWMAOoD8e\n PL3w+8AhzHVghO5x0tT3fdN6V5OR1adss10BjeR1IDKy663RQqGQ+JWrrXNp0yF65JcR\n kd1vx8S0pFvLMAK0UxPHz0E6xBdJuftfyM3ypa/vAAHvHDdBMilrQ/aUcXTQKrohtN4l\n AV4ZEgfskrxZ8DuewccuptgEBKr3DRNBC/V0LWvvePUfZC/t3SYZwVl8XEG10a0gN+Fz\n FTYg==","X-Gm-Message-State":"AOJu0YyKl/01xQCSgLCC555Fr2nIiHiGKeTw8Yuu3apMfutn+qzRBFGB\n XRoviQIyyVy4YRy5JsT3Spvfyc8HZWiy0HVZi7DnQKd2jRbR2pOTFyyP","X-Gm-Gg":"AeBDietJpaMTsm8ARpyEHuvNSAoa7SKeILkRaKY7D7mVI+y5STozeRD+Eqz1BZqn82X\n Zqm9yZVbVas77Io3Wxkn3KFwKDlZ+oVxcJ58z64gX/xOJbTxuYp5YauWQfMuYOl098RyCJB1Za7\n LZJaNPVEAeigi0FVMw4sffcS2Ls6+mQEGJPTe/v2ernyGXaXrxGTKJpZ2Y3taD+fw0ya9Ai3L2I\n QB+H9akIWYTdIpWxDlMm2Lk41igRIcfs/wACrZRzsJkQhb6Uw5yIX16As2VnGjBwdxclZy2ybPU\n xP+PWafp1Jjic9I4qibSq15X+DdGrBc8a8oJ14Fo9LcZfRligrt3B51iFHt//AwqWAARTI0Fhlr\n mXLQmpB5Vq0rXiltqLZ1w+VkQ5rC8+UpM9Fq6p5ykJg89jxftZ02Cwd+0CtIdPlWAe9zCtkYkxh\n v63E1gIg9upSLNrjCcNQ6EytSMszL5nDecwRDKl0ZYmSlMjqpxpb+3knqwub4FNnXpwoogQHtBF\n BbfXGxwdyU=","X-Received":"by 2002:a05:693c:2b14:b0:2a4:701a:b9ba with SMTP id\n 5a478bee46e88-2cbfbe7c7damr3348809eec.14.1775412996343;\n Sun, 05 Apr 2026 11:16:36 -0700 (PDT)","Mime-Version":"1.0","Content-Transfer-Encoding":"quoted-printable","Content-Type":"text/plain; charset=UTF-8","Date":"Sun, 05 Apr 2026 11:16:34 -0700","Message-Id":"","Subject":"Re: [RFC PATCH 00/10] vfio: PCI device passthrough on Apple Silicon\n Macs","From":"\"Scott J. Goldman\" ","To":"\"BALATON Zoltan\" , \"Scott J. Goldman\"\n ","Cc":", , ,\n , , ,\n , , ,\n ","X-Mailer":"aerc 0.21.0","References":"<20260405072857.66484-1-scottjgo@gmail.com>\n ","In-Reply-To":"","Received-SPF":"pass client-ip=2607:f8b0:4864:20::1336;\n envelope-from=scottjgo@gmail.com; helo=mail-dy1-x1336.google.com","X-Spam_score_int":"-20","X-Spam_score":"-2.1","X-Spam_bar":"--","X-Spam_report":"(-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,\n DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,\n RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,\n SPF_PASS=-0.001 autolearn=ham autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"qemu development ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}}]