Help would be much appreciated with binpatching the AppleIntelBDWGraphics kernel panic. This time should be no different, and patching the Catalina kext would allow us to move on to trying Qemu 4.0's EDID functionality! ^^^ Last time, u/TheRacerMaster was able to use Hopper disassembler to provide a binpatch to skip over the panicking code, and it was enough to load AppleIntelBDWGraphics.
The kernel panic log is at the bottom of this post. A patch was developed to enable EDIDs for GVT-g several weeks later, and this was merged into mainline Qemu.Ĭurrent status: 10.15 Catalina DP1 is booting, but enabling GVT-g results in a similar kernel panic to the High Sierra attempt. For the mac mini scenario, the most common solution to regain acceleration is a dummy display plug.
#Hopper disassembler 10.15 drivers#
> Some background: In this case, no EDID was provided by GVT-g (exactly like the mac mini headless scenario), and this was the "blocker" for reaching the goal of an accelerated GUI, even though the graphics drivers *were* loaded. At the driver level, this corresponds to whether or not an EDID was read from a display output. However, as is infamously known from headless Mac Mini servers, the GUI's OpenGL (or now Metal) acceleration is disabled when a display is not physically connected to the GPU's outputs. With the help of u/TheRacerMaster, we got quite far: past an AppleIntelBDWGraphics kernel panic with a binpatch to the kext binary, and making it into the macOS GUI with the Broadwell graphics drivers loaded. I'm now trying this again with 10.15 Catalina DP1 with the same goal: a macOS VM with graphics acceleration using a virtual GPU. Hello everyone! A year ago, I tried running High Sierra with GVT-g (technology to share a slice of an intel iGPU with a guest OS, using the native intel drivers) in Qemu.
0 kommentar(er)
