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