Date: Sat, 16 Oct 2021 18:37:54 +1000 From: Peter Grehan <grehan@freebsd.org> To: =?UTF-8?Q?Corvin_K=c3=b6hne?= <c.koehne@beckhoff.com> Cc: FreeBSD Virtualization <freebsd-virtualization@freebsd.org> Subject: Re: [PATCH] OvmfPkg/Bhyve: install bhyve's ACPI tables Message-ID: <39f6e329-2d8a-2fa7-cd39-5031d6646b9f@freebsd.org> In-Reply-To: <20211014071056.452-1-c.koehne@beckhoff.com> References: <20211014071056.452-1-c.koehne@beckhoff.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Corvin K=C3=B6hne wrote:, > =EF=BB=BFIt'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=20 users since they generally run without the -A option, which will=20 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=20 addressed at some point - the PCI mmio/io windows are created assuming that bhyve has done PCI=20 enumeration. If EFI is doing enumeration, these will be incorrect - the SPCR isn't generated by bhyve, but is by EFI. There are Windows=20 users who rely on having a serial console, so this should be added to=20 bhyve. Fortunately the table is trivial. - the space used by bhyve ACPI tables (the area just below 1MB=20 physical) is quite small and has little room for expansion. Qemu gets=20 around this by providing ACPI tables (or just the DSDT) by a fw_cfg=20 interface, and doesn't place the tables into RAM. There are other more general issues with bhyve ACPI. Fork/exec of iasl=20 is convenient, and guarantees tables are syntactically correct, but is=20 expensive in startup time. It would be preferable for tables to be=20 generated without iasl. This is simple for static tables, but for=20 DSDT/SSDT, something like EDK2's dynamic table generation could be used=20 (https://github.com/tianocore/edk2/tree/master/DynamicTablesPkg) I also feel that table generation in EFI is still a viable approach,=20 though it requires additional information to be pass from the=20 hypervisor, and dynamic table generation, to get to feature parity with=20 bhyve's generated tables. later, Peter.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39f6e329-2d8a-2fa7-cd39-5031d6646b9f>