Change Details

u-boot appears to ignore existing BAR mappings and creates its own based on its view of the memory map (hard-coded in the bhyve-arm64 u-boot config). This can cause problems when it creates mappings on top of the ones created by bhyve, since the MMIO implementation in bhyve doesn't expect to handle that scenario. See https://lists.freebsd.org/archives/freebsd-virtualization/2024-April/002103.html for a detailed example. Rather than making bhyve more complex to handle this case, simply add a mode which lets bhyve avoid creating mappings at all. This might be a bit simplistic: we could conceivably want different behaviour for passthrough devices (not supported on arm64) vs emulated devices, or perhaps the default should depend on the firmware. However, this works for now and doesn't introduce much complexity.

Let the boot ROM handle BAR initialization. This fixes a problem where u-boot's BAR remapping conflicts with some limitations in bhyve. See https://lists.freebsd.org/archives/freebsd-virtualization/2024-April/002103.html for a description of what goes wrong. The old behaviour can be restored by setting the pci.enable_bars configuration variable.

u-boot appears to ignore existing BAR mappings and creates its own basedLet the boot ROM handle BAR initialization. This fixes a problem where on its view of the memory map (hard-coded in the bhyve-arm64 u-bootu-boot's BAR remapping conflicts with some limitations in bhyve. See config). This can cause problems when it creates mappings on top of the ones created by bhyve, since the MMIO implementation in bhyve doesn't expect to handle that scenario. See https://lists.freebsd.org/archives/freebsd-virtualization/2024-April/002103.html for a detailed example. Rather than making bhyve more complex to handle this case, simply add ascription of what goes wrong. mode which lets bhyve avoid creating mappings at all. This might be a The old behaviour can be restored by setting the pci.enable_bars bit simplistic: we could conceivably want different behaviour forconfiguration variable. passthrough devices (not supported on arm64) vs emulated devices, or perhaps the default should depend on the firmware. However, this works for now and doesn't introduce much complexity.