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-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.
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"}'
This is a good idea. I think the override option is probably better, as warnings are easily missed and the resulting behaviour seems to be generally unusable. Do you want me to put this together? If so, what's the most acceptable way to check the target and host architectures respectively from (I guess?) the device instance init function?
> * 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
>