Crate acpi

A library for parsing ACPI tables. This crate can be used by bootloaders and kernels for architectures that support ACPI. This crate is not feature-complete, but can parse lots of the more common tables. Parsing the ACPI tables is required for correctly setting up the APICs, HPET, and provides useful information about power management and many other platform capabilities.

This crate is designed to find and parse the static tables ACPI provides. It should be used in conjunction with the aml crate, which is the (much less complete) AML parser used to parse the DSDT and SSDTs. These crates are separate because some kernels may want to detect the static tables, but delay AML parsing to a later stage.

This crate requires alloc to make heap allocations. If you are trying to find the RSDP in an environment that does not have a heap (e.g. a bootloader), you can use the rsdp crate. The types from that crate are compatible with acpi.

Usage

To use the library, you will need to provide an implementation of the AcpiHandler trait, which allows the library to make requests such as mapping a particular region of physical memory into the virtual address space.

You then need to construct an instance of AcpiTables, which can be done in a few ways depending on how much information you have:

• Use AcpiTables::from_rsdp if you have the physical address of the RSDP
• Use AcpiTables::from_rsdt if you have the physical address of the RSDT/XSDT
• Use AcpiTables::search_for_rsdp_bios if you don’t have the address of either, but you know you are running on BIOS, not UEFI
• Use AcpiTables::from_tables_direct if you are using the library in an unusual setting, such as in usermode, and have a custom method to enumerate and access the tables.

AcpiTables stores the addresses of all of the tables detected on a platform. The SDTs are parsed by this library, or can be accessed directly with from_sdt, while the DSDT and any SSDTs should be parsed with aml.

To gather information out of the static tables, a few of the types you should take a look at are:

• PlatformInfo parses the FADT and MADT to create a nice view of the processor topology and interrupt controllers on x86_64, and the interrupt controllers on other platforms. AcpiTables::platform_info is a convenience method for constructing a PlatformInfo.
• HpetInfo parses the HPET table and tells you how to configure the High Precision Event Timer.
• PciConfigRegions parses the MCFG and tells you how PCIe configuration space is mapped into physical memory.

Re-exports

pub use crate::fadt::PowerProfile;

pub use crate::hpet::HpetInfo;

pub use crate::madt::MadtError;

pub use crate::mcfg::PciConfigRegions;

pub use crate::platform::InterruptModel;

pub use crate::platform::PlatformInfo;

Modules

fadt
hpet
madt
mcfg
platform
sdt

Structs

AcpiTables
AmlTable
PhysicalMapping	Describes a physical mapping created by AcpiHandler::map_physical_region and unmapped by AcpiHandler::unmap_physical_region. The region mapped must be at least size_of::<T>() bytes, but may be bigger.
Sdt

Enums

AcpiError
RsdpError

Traits

AcpiHandler

An implementation of this trait must be provided to allow acpi to access platform-specific functionality, such as mapping regions of physical memory. You are free to implement these however you please, as long as they conform to the documentation of each function. The handler is stored in every PhysicalMapping so it’s able to unmap itself when dropped, so this type needs to be something you can clone/move about freely (e.g. a reference, wrapper over Rc, marker struct, etc.).

AcpiTable

All types representing ACPI tables should implement this trait.