You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Introduce ACPI table generation to Propolis and load them into guests
using QEMU's Firmware Configuration (`fw_cfg`) protocol.
This initial implementation of the tables produce the exact same AML
bytecode as the one provided by EDKII OVMF firmware, that is why it
still contains some elements that do not make sense in Propolis. Future
work will modernize and make these tables more specific to Propolis.
To avoid unexpected changes on reboot, the ACPI tables that are
generated and loaded into guests is versioned using the `AcpiVariant`
enum.
The `acpi` module contains the table generation logic and uses the
`acpi_tables` crate to generate the AML bytecode for the tables.
Devices can generate their own AML code by implementing the
`DsdtGenerator` trait and returning themselves in the method
`as_dsdt_generator` of the `Lifecyle` trait.
```
impl Lifecycle for ... {
fn as_dsdt_generator(&self) -> Option<&dyn acpi::DsdtGenerator> {
Some(self)
}
// ...
}
```
The `to_aml_bytes()` method of `DsdtGenerator` provides a metadata
storage that can be populated during VM initialization with information
needed for the AML code. Devices also need to implement the
`DeviceMetadata` trait to store and retrieve metadata from this storage.
Currently only the PS2 controller and UART serial ports generate their
own AML because they are the only ones that can be generated to be
identical to the original EDKII tables. Future ACPI table variants may
be able to generate AML code directly from other devices.
Co-authored-by: Luiz Aoqui <luiz@oxidecomputer.com>
Co-authored-by: iximeow <git@iximeow.net>
0 commit comments