This will be used by bhyve to build a device tree.
Details
Details
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 52587 Build 49478: arc lint + arc unit
Event Timeline
Comment Actions
I'd prefer we pass ACPI tables to the guest. FDT support was only ever a hack to get something working.
Comment Actions
From my reading of QEMU, it always creates an FDT, then optionally creates ACPI tables and exposes them to the guest via fwcfg. I also had a look at EDK2's ArmVirtPkg, which I presume is what we'd want to use as the platform firmware when booting from ACPI (I don't really understand how Ovmf and ArmVirt overlap). From what I can see, ArmVirtPkg assumes that a FDT is present: the first thing that the module entry point is save a pointer to the FDT to copy later. The FDT is exposed to the rest of the firmware using a UEFI protocol, and fwcfg nodes are used to decide whether to pass ACPI tables to the guest.
So, assuming that we want to target edk2 on arm64, I think we probably need to keep the FDT builder even if bhyve is configured to supply ACPI tables to the guest.