Date: Sat, 16 Oct 2021 08:37:54 UTC
Hi Corvin Köhne wrote:, > It's much easier to create configuration dependend ACPI tables for > bhyve than for OVMF. For this reason, don't use the statically > created ACPI tables provided by OVMF. Instead use the dynamically > created ACPI tables of bhyve. If bhyve provides no ACPI tables or > we are unable to detect those, fall back to OVMF tables. Thanks for forwarding this to the list. I think it's an interesting change - fortunately it is opt-in for EFI users since they generally run without the -A option, which will continue to allow ACPI tables to be created from within EFI. There will be some issues with the use of this that may have to be addressed at some point - the PCI mmio/io windows are created assuming that bhyve has done PCI enumeration. If EFI is doing enumeration, these will be incorrect - the SPCR isn't generated by bhyve, but is by EFI. There are Windows users who rely on having a serial console, so this should be added to bhyve. Fortunately the table is trivial. - the space used by bhyve ACPI tables (the area just below 1MB physical) is quite small and has little room for expansion. Qemu gets around this by providing ACPI tables (or just the DSDT) by a fw_cfg interface, and doesn't place the tables into RAM. There are other more general issues with bhyve ACPI. Fork/exec of iasl is convenient, and guarantees tables are syntactically correct, but is expensive in startup time. It would be preferable for tables to be generated without iasl. This is simple for static tables, but for DSDT/SSDT, something like EDK2's dynamic table generation could be used (https://github.com/tianocore/edk2/tree/master/DynamicTablesPkg) I also feel that table generation in EFI is still a viable approach, though it requires additional information to be pass from the hypervisor, and dynamic table generation, to get to feature parity with bhyve's generated tables. later, Peter.