Re: [PATCH] OvmfPkg/Bhyve: install bhyve's ACPI tables

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.