RyzenHV 0.7.5: VMware Fusion gets past its BIOS

0.7.5: VMware Fusion 26 gets past its BIOS (a fix in the kext's run trap)

VMware Fusion 26 used to show a black screen with no error. The cause was in the kext: when a client switches on NMI-window exiting, the run trap answers at once without running the guest, and it dropped the registers (RIP, RSP, RFLAGS, GPRs) of that batch while it kept the VMCS fields. Fusion enters SMM exactly like this (its BIOS sends itself an SMI through the local APIC, then Fusion sets the NMI window and writes CS=0x3000, RIP and the rest in one batch), so its guest ended up with the new code segment and the old RIP and ran off into zeros. The registers are now applied before that early return.

With 0.7.5 Fusion's BIOS finishes and Windows starts: the boot logo appears. It then stays there: the guest sits in a loop in the Windows kernel and the installer does not go on. So Fusion is not usable yet (details and what is known in docs/ROADMAP.md, item 12). The change does not touch the other programs' paths.

Tested on this build (the kext in the archive has the same code as the one tested), Ryzen 7 5800H, macOS 15.8.1: Docker Desktop hello-world and alpine (16 vCPUs); hvf-smoke and selftest pass; Parallels Desktop in native mode: Windows 10 cold boot in 16 s, keyboard, suspend and resume (the Parallels Desktop app open); VirtualBox 7.2: a Windows 10 VM runs to its first-start setup screen; Fusion as above. Not tested: other machines.

Also in the repository since 0.7.4: the reason Parallels' 3D acceleration crashes with the third-party NVIDIA Metal driver (docs/PARALLELS.md; it is the driver, not RyzenHV).

Install: unpack, ./rhv kext --native, reboot, ./rhv doctor, ./rhv autostart install, then ./rhv parallels native. Keep a working EFI without the kext.