Fix ARM64 guest boot under Virtualization.framework on macOS 27

[rgarcia]

Summary

• Remove the unconditional early ARM64 write to Cloud Hypervisor's boot-timing MMIO register at 0x09000f00. Virtualization.framework does not map this register; the write prevents Linux guests from starting on macOS 27.
• Remove the unused assembly helper and document the change. ARM64 loses this first-instruction Cloud Hypervisor timing marker; x86_64 reporting is unchanged.
• This matches the failure described in [Bug]: Cloud Hypervisor kernels fail to start on macOS 27 (VZErrorDomain Code=1) apple/container#2360.

Testing

macOS 27 boot fix: direct Virtualization.framework, not QEMU

Same Apple M4 / 16 GiB / macOS 27.0.1 (26A434) host:

Guest kernel	Result
Released Image (12d676bf3726…)	Failed before source guest boot. VZ reported an internal virtualization start error; the retained VZ service crash report records EXC_BREAKPOINT / SIGTRAP.
PR #5 source build, commit 61d635014ed0b1fe5aa884202bbbd0f83af40a44	Passed three consecutive fresh-boot guest-state tests, each including live fork, guest exec/state assertions, and two additional standby/restore cycles.

• Built with ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make ch_defconfig and make Image. These passing results used the source-built Image, not the earlier diagnostic four-byte binary patch.
• Existing VZ standby/restore, running-source snapshot round trip, and running-network-fork tests also passed.
• Before/after evidence, full Image hashes, and selected original test/crash-report output.

Scope: this validates the specific boot blocker on M4 / macOS 27.0.1, not every Apple Silicon model or macOS 27 build. Host-to-fork HTTP remains a separate known failure and is not counted as fixed.

ARM64 Linux / Cloud Hypervisor validation (2026-10-17)

• Tested both supported Cloud Hypervisor releases: v49.0 (binary reports v49.0.0) and v51.1. The released-kernel baseline passed one fresh boot/exec plus three RAM-preserving restore cycles per version.
• The source-built candidate passed three fresh boot/exec runs and nine RAM-preserving restore cycles per version: six boots and eighteen restore cycles total. Every restore retained the boot ID, tmpfs nonce, workload PID, and disk marker; the workload counter continued and guest exec remained usable.
• Existing Hypeman TestExecConcurrent and TestStandbyAndRestore also passed with the candidate and default Cloud Hypervisor v51.1, including post-restore guest clock correction.
• Environment: ARM64 Linux 6.12.8+ / Ubuntu 26.04 userspace / 4 KiB pages, with working /dev/kvm, running under QEMU 11.1.2 HVF nested virtualization on Apple M4 / macOS 27.0.1. This is Linux/KVM execution, not native macOS Cloud Hypervisor or cross-architecture emulation. The outer Linux host was held constant for the baseline/candidate comparison.
• Candidate Image SHA256: 8e9095bd4a331ba429e3a3ed167afb2241cce3effdebbe6717f450e1cdffeccf; no binary patching. Temporary integration harness, results, and reproduction instructions.

Bare-metal ARM64 Linux validation and the full kernel test suite were not run.

Delivery

This PR changes source only. A new kernel release and a Hypeman kernel-version update are required before users receive the fix.