Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alternative XNU Logs Output #2468

Open
t0rr3sp3dr0 opened this issue Jan 3, 2025 · 0 comments
Open

Alternative XNU Logs Output #2468

t0rr3sp3dr0 opened this issue Jan 3, 2025 · 0 comments

Comments

@t0rr3sp3dr0
Copy link

t0rr3sp3dr0 commented Jan 3, 2025

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):

  1. COM1 at base address 0x03F8
  2. MMIO at base address 0xFE034000 or 0xFE036000
  3. PCIe MMIO at base address 0xFE410000

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant