For backward compatibility, the ACPI tables are loaded into the guest
memory. Windows scans the memory, finds the ACPI tables and uses them.
It ignores the ACPI tables provided by the UEFI. We are patching the
ACPI tables in the guest memory, so that's mostly fine. However, Windows
will break when the ACPI tables become to large or when we add entries
which can't be patched by bhyve. One example of an unpatchable entry, is
a TPM log. The TPM log has to be allocated by the guest firmware. As the
address of the TPM log is unpredictable, bhyve can't assign it in the
memory version of the ACPI tables. Additionally, this makes it
impossible for bhyve to calculate a correct checksum of the table.
By default ACPI tables are still loaded into guest memory for backward
compatibility. The new acpi_tables_in_memory config value can be set to
false to avoid this behaviour.
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D39979
In a subsquent commit the TPM emulation will build it's own TPM2 table.
This needs to be registered to the RSDT and XSDT. Instead of making the
rsdt and xsdt variables global, we can simply add a helper to basl.
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D40559
A TPM has an event log. Therefore, qemu adds a FwCfg item and adds it to
an ACPI table. We like to use the same OVMF driver as qemu, so we should
do the same. This commit adds the ability to basl to do it.
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D40451
Add all acpi tables to qemus acpi table loader. This passes the acpi
tables by fwcfg to the guest.
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D38439
Now that all ACPI tables are build by basl, basl can dynamically
calculate the offset for each table.
Reviewed by: jhb, markj (older version)
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D37002
The common style for build an ACPI table will be:
1. basl_table_create
2. basl_table_append_header
3. setup an ACPI_TABLE_* struct
4. basl_table_append_bytes (without header)
Add a helper for the last step.
Reviewed by: jhb, markj
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D37406
The code will be more readable if we use struct definitions from ACPI-CA
to build ACPI tables. We can fill out the struct and append it to the
basl_table by using basl_table_append_bytes. After that, we have to
declare which checksums, length and pointers should be patched by basl.
That's done by the add_* functions.
Reviewed by: jhb, markj
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D37405
- Make basl_dump() as unused.
- Avoid arithmetic on a void pointer.
- Avoid a signed/unsigned comparison with
BASL_TABLE_CHECKSUM_LEN_FULL_TABLE.
- Ignore warnings about unused parameters from stuff pulled in by
acpi.h. In particular, any prototype wrapped by
ACPI_DBG_DEPENDENT_RETURN_VOID() will raise such parameters unless
ACPI_DEBUG_OUTPUT is defined.
Reviewed by: corvink, jhb
Differential Revision: https://reviews.freebsd.org/D37397
Most ACPI tables are using the same header. Make it easy to create this
header by creating a function for it.
Reviewed by: jhb, markj (older version)
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D36992
Some ACPI tables like XSDT contain pointers to other ACPI tables. When
an ACPI table is loaded by qemu's loader, the address in the guest
memory is unknown. For that reason, the qemu loader supports patching
those pointers. Basl keeps track of all pointers and causes the qemu
loader to patch all pointers.
The qemu ACPI table loader is unsupport yet. However, in a future commit
bhyve will use dynamic ACPI table offsets based on the size and
alignment requirements of each ACPI table. Therefore, tracking ACPI
table pointer is required too.
Reviewed by: jhb
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D36991
The qemu ACPI table loader patches the ACPI tables. After patching them,
checksums aren't correct any more. It has to calculate a new checksum
for the ACPI table. For that reason, basl has to keep track of checksums
and has to cause the qemu loader to create new checksums for the tables.
The qemu ACPI table loader isn't supported yet. However, the address of
all tables is unknown as long as bhyve hasn't finished ACPI table
creation. So, the checksum of tables which include pointer to other
tables are unknown too. This requires tracking of checksums too.
Reviewed by: jhb
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D36990
ACPI tables have different layouts. So, there's no common position for
the length field. When tables are build by basl, the length is unknown
at the beginning. It has to be set after building the table.
Reviewed by: jhb
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D36989
In upcoming commits, bhyve will build some ACPI tables by it's own.
Therefore, it should be capable of appending GENERIC_ADDRESS structs to
ACPI tables.
Reviewed by: jhb, markj
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D36988
In upcoming commits, bhyve will build some ACPI tables by it's own.
Therefore, it should be capable of appending int values to ACPI tables.
Reviewed by: jhb, markj (older version)
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D36987
Developing an ACPI table compiler isn't quite easy. It's helpful if you
can take a look at the ACPI tables created by the compiler.
The dump functions can either dump a ACPI table which was copied into
guest memory or a ACPI table provided for qemu's ACPI table loader.
Reviewed by: jhb, markj
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D36985
Basl is the bhyve ASL compiler. At the moment, it's just a small wrapper
to call iasl, the Intel ASL compiler. As bhyve will gain support for
qemu's ACPI table loader in the future, it has to create ACPI tables on
it's own. Therefore, it makes sense to create a new file which keeps the
code for basl.
This first implementation of basl supports creating an ACPI table by
appending raw bytes to it. It's also capable of loading all tables into
guest memory.
Reviewed by: jhb, markj (older version)
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D36984
