[PATCH 12/19] bhyve: build MCFG table by basl

[corvink]

Summary

Building the MCFG table by basl will allow it to be loaded by qemu's
ACPI table loader.

This is the 12. patch required to merge D36983

[jhb]

usr.sbin/bhyve/basl.h

27

I wonder if we want #define's for these values that are only used once vs just using them inline in the one place they are used? Shared values like BASL_OEM_ID make sense to be shared. It also looks like so far the OEM table ID is following the pattern "BV" + <ACPI SIG> + " " which could perhaps be hardcoded in the build table header function avoiding the need for specifying it at all.

[corvink]

usr.sbin/bhyve/basl.h

27

I've created the defines to have a place where you can find a short overview of our tables and revisions etc. I can inline them if you want.

Regarding OEM table ID: The only usecase for different id's that I'm aware of are multiple SSDT tables (https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/05_ACPI_Software_Programming_Model/ACPI_Software_Programming_Model.html#secondary-system-description-table-ssdt). Not sure if it could make sense for bhyve to use SSDT tables.

[jhb]

usr.sbin/bhyve/basl.h

27

We aren't likely to need SSDTs, no. I do think generating the table ID's using a pattern in the helper function might be nice as it would shrink the code slightly in all the functions building tables.

[corvink]

usr.sbin/bhyve/basl.h

27

I'm going to remove it. What do you think about the oem revision field? We could hard code it to 1 to remove another parameter from basl_table_append_header but it might be helpful to bump the version for debugging purposes when we fix a table (e.g. https://reviews.freebsd.org/D36998#inline-228535)

[corvink]

• inline defines

[jhb]

usr.sbin/bhyve/basl.h

27

I think keeping the revision as an argument to basl_table_append_header makes sense.

[corvink]

• use ACPI_TABLE_* structs for building

[jhb]

Thanks, I find this much more readable.