bhyve hostbridge should feign PAM0 emulation
While testing the initial patch for #13835, we found that old CSM bootroms succumbed to the issue which prompted that memory zeroing in the first place: broken behavior when an instance reboots. After adding some debug logic to zero a selected range during boot, I narrowed it down to
0xf0000-0xfffff (physical) which, if zeroed during reboot, would allow the CSM bootrom to make process like normal. Some research lead me to Intel docs which describe that as "Programmable Attribute Map (PAM)":
PAM is a legacy BIOS ROM area in MMIO. It is overlaid with DRAM and used as a faster ROM storage area. It has a fixed base address (
000C_0000h) and fixed size of 256 KB. The 13 sections from 768 KB to 1 MB comprise what is also known as the PAM Memory Area. Each section has Read enable and Write enable attributes.
The i440FX datasheet had more detail about PAM, and qemu appears to emulate the changes in behavior for those address ranges when their configuration registers are modified. The registers bear the default value of zero which implies that accesses would bypass DRAM:
Disabled. DRAM is disabled and all accesses are directed to PCI. PMC does not respond as a PCI target for any read or write access to this area.
The hostbridge emulation in bhyve does none of this, so it's not surprising that the bootrom acted strangely when those physical addresses were backed with DRAM, persisting values across reboot.
A short term solution to this problem would be to have the hostbridge emulation zero that PAM0 (
0xf0000-0xfffff) region of physical guest memory on boot, allowing #13835 to proceed while preserving CSM bootrom functionality with C-bhyve.