qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v12 02/15] hw/display/apple-gfx: Introduce ParavirtualizedGra


From: Akihiko Odaki
Subject: Re: [PATCH v12 02/15] hw/display/apple-gfx: Introduce ParavirtualizedGraphics.Framework support
Date: Sat, 30 Nov 2024 15:13:16 +0900
User-agent: Mozilla Thunderbird

On 2024/11/30 0:24, Phil Dennis-Jordan wrote:
MacOS provides a framework (library) that allows any vmm to implement a
paravirtualized 3d graphics passthrough to the host metal stack called
ParavirtualizedGraphics.Framework (PVG). The library abstracts away
almost every aspect of the paravirtualized device model and only provides
and receives callbacks on MMIO access as well as to share memory address
space between the VM and PVG.

This patch implements a QEMU device that drives PVG for the VMApple
variant of it.

Signed-off-by: Alexander Graf <graf@amazon.com>
Co-authored-by: Alexander Graf <graf@amazon.com>

Subsequent changes:

  * Cherry-pick/rebase conflict fixes, API use updates.
  * Moved from hw/vmapple/ (useful outside that machine type)
  * Overhaul of threading model, many thread safety improvements.
  * Asynchronous rendering.
  * Memory and object lifetime fixes.
  * Refactoring to split generic and (vmapple) MMIO variant specific
    code.

Implementation wise, most of the complexity lies in the differing threading
models of ParavirtualizedGraphics.framework, which uses libdispatch and
internal locks, versus QEMU, which heavily uses the BQL, especially during
memory-mapped device I/O. Great care has therefore been taken to prevent
deadlocks by never calling into PVG methods while holding the BQL, and
similarly never acquiring the BQL in a callback from PVG. Different strategies
have been used (libdispatch, blocking and non-blocking BHs, RCU, etc.)
depending on the specific requirements at each framework entry and exit point.

Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu>

Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Tested-by: Akihiko Odaki <akihiko.odaki@daynix.com>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]