bhyve: introduce acpi_device_emul struct

[corvink]

Summary

It'll be easier to add new properties to the ACPI device emulation if we
have a struct which holds all device specific properties. In some future
commits the acpi_device_emul struct will be expanded to include some
device specific functions to build ACPI tables.

[rew]

so I assume some ACPI devices will have different emulation than others?

and that the different types of emulation will have emulation specific functions? as opposed to device specific?

usr.sbin/bhyve/acpi_device.c

51–54

should these be asserts?

63–64

does this code compile? looks like deadcode

88–89

also looks like deadcode

usr.sbin/bhyve/qemu_fwcfg.c

386

did fwcfg_sc actually get renamed to sc?

[corvink]

• remove dead code
• make use of asserts
• fix compiling errors

[corvink]

In D39319#895908, @rew wrote:

so I assume some ACPI devices will have different emulation than others?

and that the different types of emulation will have emulation specific functions? as opposed to device specific?

This commit prepares the acpi_device struct to hold some device specific functions. E.g. bhyve has to build a TPM2 table if a TPM is present. IMHO, it's cleaner if we have a device specific function in the acpi_device struct (see D39320) than code like if (vm_has_tpm()) { build_tpm2(); } if (vm_has_xy()) { build_xy(); }. Especially, the content of the ACPI table depends on the TPM interface (like CRB of FIFO). The creating of emulation dependent ACPI tables will be easier with this solution.

[markj]

usr.sbin/bhyve/acpi_device.c

41

This comment needs to be updated.