Compatibility with ArrowLake CPUs

[FMaz008]

Not sure if this is to be considered an issue or not, but I've been struggling to boot the image generated with OSX-Hyper-V's script using my mobile arrow lake CPU. I keep getting tons of shared memory errors until the boot process abort. (I'm not able to screenshot while the VM is running, but there's a thousands of them)

I deactivated Hyper-V's dynamic memory, and matched the available memory from Hyper-V to the -ram parameter I'm passing to the script. No change.

Attached is my config.plist file, which I've modified to the best of my knowledge with informations I could muster as the default one did not seem to work.

config.plist.zip

Note that I've tried several different OSX versions, (and which one doesn't matter to me), but that latest config.plist I attached was made for Catalina v10.15.7

Feel free to close this bug report if this is a skill issue and not a CPU support issue.

Thank you,
Francois :)

[Qonfused]

Support for Arrow Lake CPUs was only added a month after this repo's latest release, but it should work just like any other CPU after Comet Lake (#2).

Catalina 10.15.7 (19H1419 or higher) is compatible with the Comet Lake CPUID you're spoofing, and as far as I'm aware, the CPUID patch you're using is the only step required for Arrow Lake.

I'd try recording the VM window (or whole screen) to get a better idea of where you're getting stuck.

[FMaz008]

Here's a video of what I'm getting.

https://youtu.be/I2TCkz_eFvk

It seems to be starting with vm_shared_region_start_address() failed and followed by preboot: fail to get preboot device: 25.

And then a waterwall of shared memory errors.

[FMaz008]

Actually looking closer I can see an earlier error:
initU32FromEDTProp: /chosen/sepfw-load-at-boot = 0x0 <--- not found.

[Qonfused]

It gets stuck with launchd reporting that it's unable to start the recoveryOS gui, much like the same behavior as in #20 (comment). That was caused by an issue with loading MacHyperVSupport that shouldn't affect your build, though it's also been shown to be spurious on AMD builds, so it may be worth rebooting the VM a few times to confirm that it's persistent.

[FMaz008]

I've been rebooting the VMs (catalina and monterey, from a fresh build of OSX-Hyper-V, with just the CPU masking) multiple times, always with the same results.

Detail of my hardware attached in case it help any.

[Qonfused]

Interesting. It seems like mostly the same issue during GUI initialization; the installer process isn't starting, and neither is the 'desktop' environment indicated by the missing com.apple.dock.fullscreen lookups. I suspect it may be related to MacHyperVSupport's graphics bridge since it also gets stuck briefly during PCI allocation.

When I've encountered this on bare-metal hardware (no MacHyperVSupport), this issue would either disappear after multiple reboots or take anywhere between 15-30 minutes for the installer to boot (though sometimes it would reboot maybe 5 minutes after instead). Usually this was caused by a configuration issue with the graphics card or with USB/bluetooth, but neither of those should be relevant for Hyper-V.

I would try building from the v0.9.8 branch since there's been some changes to the graphics bridge (it's since been replaced with a full synthetic graphics driver). Additionally, if you do re-use VMs in testing, you may also want to clear it's NVRAM with the CleanNVRAM.efi boot option in OpenCore.

[Qonfused]

@FMaz008 Are you still encountering this issue?

I've just merged changes for the MacHyperVSupport v0.9.8 branch into the main branch. I'd try building from this new version and running the post-install script within macOS (instructions to do so have been updated in the README).