Alternative XNU Logs Output #2468
Comments
|
Is the OpenCore AppleDebug setting able to get you any of the logging you need? |
|
I have that enabled, but unfortunately it doesn’t help. The only log that gets saved to the disk is the UEFI log, and that I can already see in the display output of the VM. The XNU video console requires a VGA-compatible GPU, and Virtualization Framework has zero support for that. The only option available is a VirtIO GPU. Btw, if I only use VirtIO devices on QEMU, I can pretty much reproduce the environment of Virtualization Framework and the limitations that come with it. Except that macOS boots in QEMU, but not in Virtualization Framework. The only scenario where AppleDebug helps is when there is a kernel panic. I’m unable to see that in the video output of the VM, but OpenCore extracts the dump from NVRAM and saves that on disk. That’s how I now that something is still going when XNU starts and I loose display output. The KEXTs injected by OpenCore are being loaded and I can cause a kernel panic by injecting a bad KEXT. But when I don’t do that, there is no kernel panic and VM does not restart. OpenCore is also unable to find a panic report in NVRAM if I restart the VM manually, so macOS should be halting somewhere later in the boot process. |
|
Small correction, AppleDebug only saves the UEFI logs to disk. ApplePanic is the one saving the kernel panics to disk. I have both enabled. |
|
XNU video console requires a framebuffer. I would expect Virtio-GPU to be able to provide a framebuffer. Are you sure no I do not believe Virtualization Framework supports SMM. Even if it does, intercepting ports should not be standard, so it is unlikely to work. Your best choice to get serial running is likely to patch XNU. |
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: