OC boot installation mac Tahoe kernel panic

[Follow-Ai]

[Qonfused]

There seems to be a race condition and/or deadlock while macOS's PCI and graphics stack is probing the synthetic graphics bridge:

panic(cpu 2 caller 0xffffff8013eb7f7e): Spinlock(0xffffff8013ef3280) timeout after 134400088647 ticks
... fish.goldfish64.MacHyperVSupport : __ZN20HyperVGraphicsBridge12configRead16E170PCIAddressSpaceh + 0x37

The kernel panic's backtrace shows that this happened while calling HyperVGraphicsBridge::configRead16, which reads from a 256-byte array (_fakePCIDeviceSpace) that essentially mimics the field structure of a real PCI graphics device.

My guess is that this is related to force-loading IOGraphicsFamily (#54), and IOGraphicsFamily is reading from this PCI config area as soon as it loads, i.e. before the array gets initialized in HyperVGraphicsBridge::start. Though accessing either the backing field (_fakePCIDeviceSpace) or its lock (_pciLock) may not fully release the spinlock and cause a deadlock (and hence a spinlock timeout panic).

[Follow-Ai]

This is my EFI configuration.
EFI.zip
Installing Sequoia was completely trouble-free.
I tried method（https://github.com/Qonfused/OSX-Hyper-V/issues/54） and it didn't work. kernel panic. The Mac Tahoe recovery image used for kernel panics is from https://github.com/uncor3/tahoe-recovery.

[heavvvns]

got the same panic issue trying to install Tahoe
compiled this repo today with OCE-Build
Sequoia recovery image boots with no issues on the same configuration

are there any plans on fixing this or a workaround, potentially?

[Qonfused]

There are plans to fix this since the public Tahoe release doesn't work at all with the current build, but any workaround would still require either patching IOGraphicsFamily or MacHyperVSupport to fix the race-condition in #62 (comment). Though the catch here being that any kernel patch for IOGraphicsFamily would require the kext to already be loaded, which is no good in our case.

There's a similar PR with WhateverGreen (acidanthera/WhateverGreen#124) that proposes a fix to resolve this, though it doesn't work since it checks if IOGraphicsFamily is loaded the same time we initialize Lilu's KernelPatcher API. It's still a work in progress on that end, but any fix for WhateverGreen should also work for MacHyperVFramebuffer (as we're both waiting for IOGraphicsFamily to load before doing any patching with Lilu).

Though if the issue is just that IOGraphicsFamily needs to read from _fakePCIDeviceSpace, we could just initialize it more eagerly.