You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm trying to make OpenCore work in a VM using Apple's Virtualization Framework, but I've hit a large roadblock there. That environment only provides VirtIO-based devices to the VM, including the GPU and Serial devices. That means XNU is unable to start a video or serial console in that environment, leaving no options to debug the boot process there.
I did some research and I think it would be technically possible to implement an SMM Driver that would intercept reads and writes to those addresses and emulate a compatible serial device. But if I got that right, an SMM Driver needs to be embedded into the firmware and cannot be dynamically loaded like a DXE Driver. That would be a problem since I cannot replace the UEFI firmware used by Virtualization Framework.
I wonder if there is another mechanism that be used to implement a virtual serial device that XNU can talk to at early boot.
As an extra note, after #571 got merged, I was able to cause a kernel panic by injecting a bad KEXT via OpenCore. And that is fortunately written to NVRAM and OpenCore is able to retrieve it in a subsequent boot. That means that the boot process is at least going as far as loading the KEXTs and is probably hanging somewhere later in the boot sequence.
So that also opens another path for redirecting the XNU logs somewhere other than the supported serial devices, but I don't know if that's a feasible thing to do with a KEXT or some OpenCore Patch.
The text was updated successfully, but these errors were encountered:
I'm trying to make OpenCore work in a VM using Apple's Virtualization Framework, but I've hit a large roadblock there. That environment only provides VirtIO-based devices to the VM, including the GPU and Serial devices. That means XNU is unable to start a video or serial console in that environment, leaving no options to debug the boot process there.
I see that XNU supports 3 kinds of UART devices for the serial console (https://github.com/apple-oss-distributions/xnu/blob/8d741a5de7ff4191bf97d57b9f54c2f6d4a15585/pexpert/i386/pe_serial.c#L604-L620):
I did some research and I think it would be technically possible to implement an SMM Driver that would intercept reads and writes to those addresses and emulate a compatible serial device. But if I got that right, an SMM Driver needs to be embedded into the firmware and cannot be dynamically loaded like a DXE Driver. That would be a problem since I cannot replace the UEFI firmware used by Virtualization Framework.
I wonder if there is another mechanism that be used to implement a virtual serial device that XNU can talk to at early boot.
As an extra note, after #571 got merged, I was able to cause a kernel panic by injecting a bad KEXT via OpenCore. And that is fortunately written to NVRAM and OpenCore is able to retrieve it in a subsequent boot. That means that the boot process is at least going as far as loading the KEXTs and is probably hanging somewhere later in the boot sequence.
So that also opens another path for redirecting the XNU logs somewhere other than the supported serial devices, but I don't know if that's a feasible thing to do with a KEXT or some OpenCore Patch.
The text was updated successfully, but these errors were encountered: