Say what you like about microslop but you wouldnt be asking this question over on windows
RTX 5090 and M4 MacBook Air: Can It Game?
161–170 of 195 posts
Re: RTX 5090 and M4 MacBook Air: Can It Game?
#162Earlier quoted context omitted.
I experimented with booting Arm macOS 14-26 in QEMU a while back, building on the work of Alexander Graf for macOS 12-13, and reverse-engineered substantial parts of Hypervisor.framework, the in-kernel hypervisor, and a bit of Virtualization.framework. Got newer versions of Sequoia to boot past the log in screen, with GPU acceleration too. Unless there's another method I missed, the internal GPU "pass through" of Vir…
FYI: https://patchew.org/QEMU/20260324204855.29759-1-mohamed@unpr... There's some randomness around Tahoe for FileVault and it crashing because Data is detected as not encrypted (and that's not OK on bare metal). If hitting that case you might need to enable FileVault inside the VM (and remember to sync aux storage afterwards if not done)
Looks like someone beat me to it! Thanks!
I see the author of this patch set has run into a few similar issues as me. Strangely, not all of them: I don't see patches for the new PCI MSI-X device introduced somewhere in Sequoia (IIRC), a source of kernel panics for me; and there's still a bug in the PG MMIO path that casts all writes to 32-bit, this one caused me a lot of headaches (no errors but no video adapter detected). I'm somewhat surprised to hear that this works!
There's two significant problems that we both have came across:
- LLVM now favoring pre-indexed load/stores which trap with ISV=0 for MMIO accesses, and those ending up in the GIC initialization path of the newer macOS kernels (looks like there's a separate patch set for this [0]),
- Hypervisor.framework trapping PAC HVC calls.
It seems like the latter has been worked around here by signing QEMU with an Apple-private entitlement and running with SIP off, but there's actually a different way! While some HVCs are trapped right in the host kernel, the PAC trapping happens within Hypervisor.framework itself (at least in the host OSes I tested). It's possible to patch out this functionality without special privileges or talk to the in-kernel hypervisor directly. I originally tested with the former, and chose to implement the latter as a separate accel in the code I was planning to submit upstream, but the complexity of it exploded and, besides confirming that it would have worked, I haven't managed to finish my implementation.
Does the Tahoe crash you mentioned manifest itself in stage 2 iBoot panics? I must admit 26 was never quite my priority so I haven't looked into it, but if so, it might have been closer to booting than I thought :)
[0] https://lists.nongnu.org/archive/html/qemu-devel/2026-04/msg...
Re: RTX 5090 and M4 MacBook Air: Can It Game?
#163If apple provides native support with enough bandwidth to run an external NVIDIA GPU for Inference and training, I will upgrade to the latest MBP instantly. Raise your hand if you would too.
Re: RTX 5090 and M4 MacBook Air: Can It Game?
#164Earlier quoted context omitted.
FYI: https://patchew.org/QEMU/20260324204855.29759-1-mohamed@unpr... There's some randomness around Tahoe for FileVault and it crashing because Data is detected as not encrypted (and that's not OK on bare metal). If hitting that case you might need to enable FileVault inside the VM (and remember to sync aux storage afterwards if not done)
Looks like someone beat me to it! Thanks! I see the author of this patch set has run into a few similar issues as me. Strangely, not all of them: I don't see patches for the new PCI MSI-X device introduced somewhere in Sequoia (IIRC), a source of kernel panics for me; and there's still a bug in the PG MMIO path that casts all writes to 32-bit, this one caused me a lot of headaches (no errors but no video adapter dete…
It was a kernel panic for Tahoe. Anything between macOS 12 and 26 wasn't tested so releases in-between might have more issues.
The userspace reboot after FileVault password entry acts a bit oddly with QEMU input devices so you might need to attach a new USB tablet or kbd from the monitor.
> looks like there's a separate patch set for this
Yup and it's a bit of a problem to figure out the right thing to do for it on the upstreaming side as normal guests aren't supposed to do that.
> It's possible to patch out this functionality without special privileges or talk to the in-kernel hypervisor directly
Or pre-patch them all to HVC #1 works too. Patching the host Hypervisor.framework sounds quite brittle especially after they moved to a pile of C++
Re: RTX 5090 and M4 MacBook Air: Can It Game?
#165Earlier quoted context omitted.
Looks like someone beat me to it! Thanks! I see the author of this patch set has run into a few similar issues as me. Strangely, not all of them: I don't see patches for the new PCI MSI-X device introduced somewhere in Sequoia (IIRC), a source of kernel panics for me; and there's still a bug in the PG MMIO path that casts all writes to 32-bit, this one caused me a lot of headaches (no errors but no video adapter dete…
It was a kernel panic for Tahoe. Anything between macOS 12 and 26 wasn't tested so releases in-between might have more issues. The userspace reboot after FileVault password entry acts a bit oddly with QEMU input devices so you might need to attach a new USB tablet or kbd from the monitor. > looks like there's a separate patch set for this Yup and it's a bit of a problem to figure out the right thing to do for it on t…
> It was a kernel panic for Tahoe.
Ah, must be something else then.
> normal guests aren't supposed to do that
Oh how I wish Arm didn't let anything like this slip into the architecture spec to begin with! Massive source of pain, especially with protected memory/CCA guests. It's not macOS triggering this in isolation either. Most start up binaries for QNX do this too, somehow also in the GIC init path.
I've looked at how different hypervisors/VMMs handle this and, if this makes that patch set any less hacky, Virtualization.framework, QNX Hypervisor, and (I think) VMware all decode and emulate those instructions in software. Virtualization.framework is a remarkable spaghetti in this regard :)
> Or pre-patch them all to HVC #1 works too. Patching the host Hypervisor.framework sounds quite brittle especially after they moved to a pile of C++
Possibly! IIRC, if HCR_EL2.HCD==1, HVC should trap as undefined instruction. Not sure how much of HCR_EL2 can be set from the user-space, but perhaps this could be the least invasive way.
Simply ignoring the instruction, though, is not enough. I remember in my setup, with HVC handling stubbed out, secondary cores would always fail to start. I suspect this to be the culprit.
The SMP bring-up code would fail to pass pointer authentication on the first indirect branch. It would then immediately pivot into FLEH->SLEH->panic(). panic() shortly would attempt to make an indirect jump itself, hoping to crash the other processors, but instead, getting stuck in a loop of calling itself. This would eventually get caught by a stack overflow guard somewhere in FLEH/SLEH, which would place the core in an infinite loop, and... the system would continue to run with just the boot core. Yo dawg, I heard you like panics :)
Re: RTX 5090 and M4 MacBook Air: Can It Game?
#166[dead]
Re: RTX 5090 and M4 MacBook Air: Can It Game?
#167Earlier quoted context omitted.
It was a kernel panic for Tahoe. Anything between macOS 12 and 26 wasn't tested so releases in-between might have more issues. The userspace reboot after FileVault password entry acts a bit oddly with QEMU input devices so you might need to attach a new USB tablet or kbd from the monitor. > looks like there's a separate patch set for this Yup and it's a bit of a problem to figure out the right thing to do for it on t…
> It was a kernel panic for Tahoe. Ah, must be something else then. > normal guests aren't supposed to do that Oh how I wish Arm didn't let anything like this slip into the architecture spec to begin with! Massive source of pain, especially with protected memory/CCA guests. It's not macOS triggering this in isolation either. Most start up binaries for QNX do this too, somehow also in the GIC init path. I've looked at…
> HCR_EL2.HCD
That's not ideal because of:
> Any resulting exception is taken to the Exception level at which the HVC instruction is executed.
instead of trapping to the hypervisor
> I've looked at how different hypervisors/VMMs handle this and, if this makes that patch set any less hacky, Virtualization.framework, QNX Hypervisor, and (I think) VMware all decode and emulate those instructions in software. Virtualization.framework is a remarkable spaghetti in this regard :)
And so does Hyper-V.
> It's not macOS triggering this in isolation either
There are some nightmare cases that SEPOS specifically triggers, such as doing isv=0 accesses to GICR... when using the Apple vGIC handling _that_ becomes truly bizarre.
> Simply ignoring the instruction, though, is not enough
Yeah that's not a great idea
Re: RTX 5090 and M4 MacBook Air: Can It Game?
#168Earlier quoted context omitted.
No you don't understand, on Apple Silicon my CPU has comparable memory bandwidth to a $400 Pascal-era GPU. With the unified memory architecture, that means my iGPU gets 2016-levels of DDR transfer speed with none of the upsides of CUDA. It's the most cutting-edge hardware ever put in a personal computer, without a doubt.
Please show me on the 2016-era $400 Pascal GPU where you can install the 256 GB of VRAM.
We're quite lucky that Nvidia didn't ship a 256gb system at sub-500gb/s transfer rate, is my point.
Re: RTX 5090 and M4 MacBook Air: Can It Game?
#169Earlier quoted context omitted.
> It was a kernel panic for Tahoe. Ah, must be something else then. > normal guests aren't supposed to do that Oh how I wish Arm didn't let anything like this slip into the architecture spec to begin with! Massive source of pain, especially with protected memory/CCA guests. It's not macOS triggering this in isolation either. Most start up binaries for QNX do this too, somehow also in the GIC init path. I've looked at…
> HCR_EL2.HCD That's not ideal because of: > Any resulting exception is taken to the Exception level at which the HVC instruction is executed. instead of trapping to the hypervisor > I've looked at how different hypervisors/VMMs handle this and, if this makes that patch set any less hacky, Virtualization.framework, QNX Hypervisor, and (I think) VMware all decode and emulate those instructions in software. Virtualizat…
> instead of trapping to the hypervisor
My bad! I mean, ehh, I guess you could maintain a breakpoint in the guest kernel's exception vector table or have QEMU inject its own "zero-level exception handler" whose only purpose would be to capture those HVCs, but that's not as straightforward as I originally thought. And since those PAC calls are expected to set a few Apple-specific registers anyway, using the entitlement or skipping Hypervisor.framework and talking straight to the kernel seem like the only viable options when macOS is the guest.
> There are some nightmare cases that SEPOS specifically triggers, such as doing isv=0 accesses to GICR... when using the Apple vGIC handling _that_ becomes truly bizarre.
Interesting! Are there any resources out there about virtualizing sepOS?