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.
