Cc'ing Joelle (FYI https://github.com/utmapp/UTM/issues/3491)
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-p...@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.
Zoltan, does that ring a bell?
Phil, should we display a warning in this configuration case? Or only
allow it with some developper option, like:
-device '{"driver":"apple-gfx-pci", \
"display-modes":["3840x2160@60"], \
"x-force-cross-rendering":"true"}'
* 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.)
Some of my part of this work has been sponsored by Sauce Labs Inc.
---
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
MAINTAINERS | 15 +
contrib/vmapple/uuid.sh | 9 +
docs/system/arm/vmapple.rst | 63 ++
docs/system/target-arm.rst | 1 +
hw/Kconfig | 1 +
hw/arm/sbsa-ref.c | 2 +-
hw/arm/virt.c | 2 +-
hw/block/virtio-blk.c | 58 +-
hw/core/qdev-properties-system.c | 8 +
hw/display/Kconfig | 13 +
hw/display/apple-gfx-mmio.m | 288 +++++++++
hw/display/apple-gfx-pci.m | 156 +++++
hw/display/apple-gfx.h | 77 +++
hw/display/apple-gfx.m | 880 ++++++++++++++++++++++++++++
hw/display/meson.build | 7 +
hw/display/trace-events | 30 +
hw/i386/microvm.c | 2 +-
hw/loongarch/virt.c | 12 +-
hw/meson.build | 1 +
hw/mips/loongson3_virt.c | 2 +-
hw/misc/Kconfig | 4 +
hw/misc/meson.build | 1 +
hw/misc/pvpanic-mmio.c | 60 ++
hw/openrisc/virt.c | 12 +-
hw/pci-host/gpex.c | 43 +-
hw/riscv/virt.c | 12 +-
hw/vmapple/Kconfig | 32 +
hw/vmapple/aes.c | 581 ++++++++++++++++++
hw/vmapple/bdif.c | 274 +++++++++
hw/vmapple/cfg.c | 195 ++++++
hw/vmapple/meson.build | 5 +
hw/vmapple/trace-events | 21 +
hw/vmapple/trace.h | 1 +
hw/vmapple/virtio-blk.c | 204 +++++++
hw/vmapple/vmapple.c | 612 +++++++++++++++++++
hw/xen/xen-pvh-common.c | 2 +-
hw/xtensa/virt.c | 2 +-
include/hw/misc/pvpanic.h | 1 +
include/hw/pci-host/gpex.h | 7 +-
include/hw/pci/pci_ids.h | 1 +
include/hw/qdev-properties-system.h | 5 +
include/hw/virtio/virtio-blk.h | 11 +-
include/hw/vmapple/vmapple.h | 23 +
include/qemu-main.h | 14 +-
include/qemu/cutils.h | 15 +
meson.build | 5 +
qapi/virtio.json | 14 +
system/main.c | 37 +-
ui/cocoa.m | 54 +-
ui/gtk.c | 4 +
ui/sdl2.c | 4 +
util/hexdump.c | 18 +
52 files changed, 3791 insertions(+), 110 deletions(-)
create mode 100755 contrib/vmapple/uuid.sh
create mode 100644 docs/system/arm/vmapple.rst
create mode 100644 hw/display/apple-gfx-mmio.m
create mode 100644 hw/display/apple-gfx-pci.m
create mode 100644 hw/display/apple-gfx.h
create mode 100644 hw/display/apple-gfx.m
create mode 100644 hw/misc/pvpanic-mmio.c
create mode 100644 hw/vmapple/Kconfig
create mode 100644 hw/vmapple/aes.c
create mode 100644 hw/vmapple/bdif.c
create mode 100644 hw/vmapple/cfg.c
create mode 100644 hw/vmapple/meson.build
create mode 100644 hw/vmapple/trace-events
create mode 100644 hw/vmapple/trace.h
create mode 100644 hw/vmapple/virtio-blk.c
create mode 100644 hw/vmapple/vmapple.c
create mode 100644 include/hw/vmapple/vmapple.h
