Page MenuHomeFreeBSD

[PATCH 15/19] bhyve: build FADT table by basl
ClosedPublic

Authored by corvink on Oct 14 2022, 9:27 AM.
Tags
Referenced Files
Unknown Object (File)
Mon, Nov 11, 7:00 PM
Unknown Object (File)
Mon, Nov 11, 6:43 PM
Unknown Object (File)
Thu, Nov 7, 7:57 AM
Unknown Object (File)
Mon, Nov 4, 2:30 PM
Unknown Object (File)
Sat, Oct 26, 8:13 PM
Unknown Object (File)
Oct 3 2024, 4:20 AM
Unknown Object (File)
Sep 25 2024, 1:24 AM
Unknown Object (File)
Sep 20 2024, 6:37 AM
Subscribers

Details

Summary

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

This is the 15. patch required to merge D36983

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

corvink retitled this revision from [acpi-table part 15] bhyve: build FADT table by basl to [PATCH 15/19] bhyve: build FADT table by basl.Oct 14 2022, 9:45 AM
markj added inline comments.
usr.sbin/bhyve/acpi.c
595
659
718

Hmm, this was simply missing before? I think this is correct given that the field is present in version 6.1 of the acpi spec.

This revision is now accepted and ready to land.Nov 2 2022, 1:43 PM
  • I've compared the ACPI output before and after this commit and fixed all entries
This revision now requires review to proceed.Nov 8 2022, 9:44 AM

It would be nice to be able to use ACPI_TABLE_FADT, but there are some risks: 1) when ACPI-CA is updated this file would also have to be updated since it may now have new fields (though maybe an initial memset of the table to 0 would be good enough in practice for future proofing) and 2) you'd need a way to deal with storing references to pointers like basl_table_add_pointer but based on an offset instead (though you could use offsetof, something like basl_table_add_pointer(fadt, offsetof(ACPI_TABLE_FADT, FACS), sizeof(fadt_table.FACS)). OTOH, I think it would be more readable and you could avoid having to set unneeded fields and only focus on setting the non-zero fields that matter. You might also then need variants of things like building the table header or GAS structures that write to a caller-provided buffer instead of appending bytes to a table.

usr.sbin/bhyve/acpi.c
799
In D36998#850181, @jhb wrote:

It would be nice to be able to use ACPI_TABLE_FADT, but there are some risks: 1) when ACPI-CA is updated this file would also have to be updated since it may now have new fields (though maybe an initial memset of the table to 0 would be good enough in practice for future proofing) and 2) you'd need a way to deal with storing references to pointers like basl_table_add_pointer but based on an offset instead (though you could use offsetof, something like basl_table_add_pointer(fadt, offsetof(ACPI_TABLE_FADT, FACS), sizeof(fadt_table.FACS)). OTOH, I think it would be more readable and you could avoid having to set unneeded fields and only focus on setting the non-zero fields that matter. You might also then need variants of things like building the table header or GAS structures that write to a caller-provided buffer instead of appending bytes to a table.

Hmmm, looks like you already use the basl_table_add_* variant for checksums and lengths, so that might not be all that awkward to do for pointers. Also, another way to handle the common header would be to still use the existing function for the common header, but when you append a filled-out FADT table do something like basl_table_append_bytes(&fadt_table->FACS, sizeof(fadt_table) - offsetof(ACPI_FADT_TABLE, FACS)).

ACPI-CA contains struct definitions for most tables. I thought about making use of them. This would required to make add_checksum, add_lengths and add_pointer public available. It also requires that you build the table by using the struct, then adding it by append_bytes and at the end you have to add patches for checksums, lengths and pointer. So, building a table would be similar to my basl_table_append_header function. If you prefer that style, I can change it.

  • use ACPI_TABLE_* structs for building
This revision is now accepted and ready to land.Nov 17 2022, 5:59 PM
This revision was automatically updated to reflect the committed changes.