Re: [PATCH v16 00/14] macOS PV Graphics and new vmapple machine type

["Philippe Mathieu-Daudé" <philmd@linaro.org>]

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.