RyzenHV 0.7.3: the TPR shadow in native mode, VirtualBox 7.x, a keyboard fix for restored VMs

0.7.3: the TPR shadow in native mode, VirtualBox 7.x, a keyboard fix for restored Parallels VMs

The kext now offers the TPR shadow by default (to every client except HyperKit). Windows changes its interrupt priority through CR8 all the time, and without the VMX "use TPR shadow" control every such access is a VM exit: most of the exits of a Windows boot. With it, on a Ryzen 7 5800H and macOS 15.8.1:

• Parallels Desktop 26.5.0 in native mode (./rhv parallels native): a cold boot of Windows 10 (4 vCPUs) reaches the point where the guest tools answer in about 20 s, was about 90 s.
• VirtualBox 7.x (new, experimental): VirtualBox 7 has no kernel driver on macOS and runs through Hypervisor.framework, so it now runs on the kext's native mode. With 7.2.22 an EFI VM with 2 vCPUs boots the Windows 10 installer and reaches its disk page in about a minute; without the shadow it did not get past the first screen in minutes. Its log says Turtle execution mode (hv_vm_space_* are not implemented yet), so it is below full speed. No full installation onto a disk has been run yet.

Turn the shadow off with the boot-arg rhv_tpr_shadow=0, or for the VMs created from then on with rhv-info hv tpr 0 (rhv-info hv shows whether it is on). Also in the kext: the task priority round-trips as the 8-bit HV_X86_TPR for every client but HyperKit (it was Parallels only), hv_vmx_vcpu_set_apic_address answers success, and for VMX control words a client is told the real limits (bits that must or may be 1) like hv_vmx_read_capability does; HyperKit keeps its old answer.

Keyboard in a native Parallels VM restored from a saved state now works: the monitor's "armed" flag is saved with the VM, while its second flag is per process, so the stand-in library arms the monitor until both are set.

Tested on this build (the kext in the archive is the one that was tested): Docker Desktop hello-world and alpine (16 vCPUs); Parallels Windows 10: cold boot, keyboard (Ctrl+Esc through prlctl send-key-event), suspend and resume; VirtualBox as above; hvf-smoke (public API, passes; its stage 3 now tolerates the external-interrupt exits that Hypervisor.framework may return at any time).

Known problem: prlctl suspend hung twice when the Parallels Desktop app was not running (only its background service): the state files were written, the VM stayed "suspending" and its process could not exit until a reboot. With the app open, suspend and resume worked every time. The cause is not known; keep the app open or shut the VM down. See docs/NATIVE.md.

VirtualBox 6.x is a different story: it loads its own driver, which wants to switch AMD-V on itself and stops with VERR_SVM_IN_USE while the kext keeps EFER.SVME on every core (issue #2). Use 7.x.

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