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:
> 20241208191646.64857-1-phil@philjordan.eu/" rel="noreferrer" target="_blank">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 Phil, much appreciated! Enjoy your time off.
I've just posted an updated -v3 of my xhci patch series as v2 suffered from the same breakage as this patch set. I recommend applying that one on top for testing vmapple. It helps when you can use keyboard and mouse properly and don't need to mess around with VNC.
All the best,
Phil