Message ID | 20241223221645.29911-1-phil@philjordan.eu (mailing list archive) |
---|---|
Headers | show |
Series | macOS PV Graphics and new vmapple machine type | expand |
On 23/12/24 23:16, Phil Dennis-Jordan wrote: > This patch set introduces a new ARM and macOS HVF specific machine type > called "vmapple", as well as a family of display devices based on the > ParavirtualizedGraphics.framework in macOS. One of the display adapter > variants, apple-gfx-mmio, is required for the new machine type, while > apple-gfx-pci can be used to enable 3D graphics acceleration with x86-64 > macOS guest OSes. > > Previous versions of this patch set were submitted semi-separately: > the original vmapple patch set by Alexander Graf included a monolithic > implementation of apple-gfx-mmio. I subsequently reviewed and reworked > the latter to support the PCI variant of the device as well and submitted > the result in isolation. As requested in subsequent review, I have now > recombined this with the original vmapple patch set, which I have updated > and improved in a few ways as well. > > The vmapple machine type approximates the configuration in macOS's own > Virtualization.framework when running arm64 macOS guests. In addition to > generic components such as a GICv3 and an XHCI USB controller, it > includes nonstandard extensions to the virtio block device, a special > "hardware" aes engine, a configuration device, a pvpanic variant, a > "backdoor" interface, and of course the apple-gfx paravirtualised display > adapter. > > There are currently a few limitations to this which aren't intrinsic, > just imperfect emulation of the VZF, but it's good enough to be just > about usable for some purposes: > > * macOS 12 guests only. Versions 13+ currently fail during early boot. > * macOS 11+ arm64 hosts only, with hvf accel. (Perhaps some differences > between Apple M series CPUs and TCG's aarch64 implementation? macOS > hosts only because ParavirtualizedGraphics.framework is a black box > implementing most of the logic behind the apple-gfx device.) > * PCI devices use legacy IRQs, not MSI/MSI-X. As far as I can tell, > we'd need to include the GICv3 ITS, but it's unclear to me what > exactly needs wiring up. > * Due to a quirk (bug?) in the macOS XHCI driver when MSI-X is not > available, correct functioning of the USB controller (and thus > keyboard/tablet) requires a small workaround in the XHCI controller > device. This is part of another patch series: > https://patchew.org/QEMU/20241208191646.64857-1-phil@philjordan.eu/ > * The guest OS must first be provisioned using Virtualization.framework; > the disk images can subsequently be used in Qemu. (See docs.) > > The apple-gfx device can be used independently from the vmapple machine > type, at least in the PCI variant. It mainly targets x86-64 macOS guests > from version 11 on, but also includes a UEFI bootrom for basic > framebuffer mode. macOS 11 is also required on the host side, as well > as a GPU that supports the Metal API. On the guest side, this provides > 3D acceleration/GPGPU support with a baseline Metal feature set, > irrespective of the host GPU's feature set. A few limitations in the > current integration: > > * Although it works fine with TCG, it does not work correctly > cross-architecture: x86-64 guests on arm64 hosts appear to make > some boot progress, but rendering is corrupted. I suspect > incompatible texture memory layouts; I have no idea if this is > fixable. > * ParavirtualizedGraphics.framework and the guest driver support > multi-headed configurations. The current Qemu integration always > connects precisely 1 display. > * State serialisation and deserialisation is currently not > implemented, though supported in principle by the framework. > Both apple-gfx variants thus set up a migration blocker. > * Rendering efficiency could be better. The GPU-rendered guest > framebuffer is copied to system memory and uses Qemu's usual > CPU-based drawing. For maximum efficiency, the Metal texture > containing the guest framebuffer could be drawn directly to > a Metal view in the host window, staying on the GPU. (Similar > to the OpenGL/virgl render path on other platforms.) > v15 -> v16 > > * 14 patches now, as patch 8 has already been pulled. (Thanks Philippe!) > * Fixed a bunch of conflicts with upstream code motion: > - DEFINE_PROP_END_OF_LIST removal (4/14 - apple-gfx mode list, 7/14 - > pvpanic-mmio, 10/14 - bdif, 11/14 - cfg device, and > 12/14 - vmapple-virtio-blk) > - sysemu->system move/rename: (1/14 - ui/qemu-main, 2/14 - apple-gfx, > 9/14 - aes, 10/14 - bdif, 14/14 - vmapple machine type) > * 14/14 (vmapple machine type): > - Moved compatibility setting for removing legacy mode from virtio-pci > to proper global property table rather than (ab)using sugar property. > - Removed a few superfluous #includes during sysemu rename cleanup. > - Removed machine type versioning as it's not necessary (yet?) > - Made memory map array const Great. > Alexander Graf (8): > hw: Add vmapple subdir > hw/misc/pvpanic: Add MMIO interface > gpex: Allow more than 4 legacy IRQs > hw/vmapple/aes: Introduce aes engine > hw/vmapple/bdif: Introduce vmapple backdoor interface > hw/vmapple/cfg: Introduce vmapple cfg region > hw/vmapple/virtio-blk: Add support for apple virtio-blk > hw/vmapple/vmapple: Add vmapple machine type > > Phil Dennis-Jordan (6): > ui & main loop: Redesign of system-specific main thread event handling > hw/display/apple-gfx: Introduce ParavirtualizedGraphics.Framework > support > hw/display/apple-gfx: Adds PCI implementation > hw/display/apple-gfx: Adds configurable mode list > MAINTAINERS: Add myself as maintainer for apple-gfx, reviewer for HVF > hw/block/virtio-blk: Replaces request free function with g_free If there are no objection or further comments, I'm taking this series and will post a PR after xmas & testing. Thanks all! Phil.