Enable propolis to generate ACPI tables#999
Enable propolis to generate ACPI tables#999glitzflitz wants to merge 28 commits intooxidecomputer:masterfrom
Conversation
glitzflitz
force-pushed
the
acpi_fwcfg_reord
branch
9 times, most recently
from
5fed974 to
b234998
Compare
Add a TableLoader builder that can be used to generate the etc/table-loader file to be passed to guest firmware via fw_cfg. The etc/table-loader file in fw_cfg contains the sequence of fixed size linker/loader commands that can be used to instruct guest to allcoate memory for set of fw_cfg files(e.g. ACPI tables), link allocated memory by patching pointers and calculate the ACPI checksum. Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com>
glitzflitz
force-pushed
the
acpi_fwcfg_reord
branch
from
b234998 to
d05da54
Compare
|
Thanks for taking a swing at this. It'll be nice to have ACPI table generation wired up. Some initial high-level feedback, which you can take with as much salt as you want, since I'm ex-Oxide now: You're defining quite a few ACPI-specific structs in When it comes to DSDT generation, I think this is probably something we'll want to farm out to the various piece of specific device emulation? They could own the specific knowledge required, rather than defining all those constants in acpi/dsdt.rs. Maybe think about a trait they could opt into for appending bits to a DSDT we build while assembling the machine? |
|
That makes sense. I'll create a trait for Dsdt and implment for each device that is being exposed. |
Add builders to generate basic ACPI tables RSDP(ACPI 2.0+) that points to XSDT, XSDT with 64-bit table pointers and RSDT with 32-bit table pointers that would work with the table-loader mechanism in fw_cfg. These tables are used to describe the ACPI table hierarchy to guest firmware. The builders produce raw table data bytes with placeholder addresses and checksums that are fixed up by firmware using table-loader commands. Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com>
FADT describes fixed hardware features and points to the DSDT. The builder supports both standard and HW-reduced ACPI modes. DSDT contains AML bytecode describing system hardware. The builder provides methods to append AML data which could be populated by an AML generation mechanism in subsequent commits. Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com>
Add a builder for the Multiple APIC Description Table (MADT) that describes the system's interrupt controllers. Supports adding local APIC, I/O APIC and interrupt source overrides for describing processor and interrupt controller topology. Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com>
Add builders for MCFG and HPET ACPI tables. MCFG describes the PCIe ECAM base address, PCIe segment group and bus number range for firmware to locate PCI Express configuration space. HPET describes the HPET hardware to the guest. The table uses the bhyve HPET hardware ID (0x80860701) and maps to the standard HPET MMIO address at 0xfed00000. Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com>
Add the FACS table that provides a memory region for firmware/OS handshaking. The table includes the GlobalLock field for OS/firmware mutual exclusion during ACPI operations. We don't yet have support for GBL_EN handling[1], but expose the table to match OVMF's behaviour. [1]: oxidecomputer#837 Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com>
Define bytecode opcodes for AML generation per ACPI Specification Chapter 20 [1]. Includes namespace modifiers, named objects, data object prefixes, name path prefixes, local/argument references, control flow and logical/arithmetic operators. These constants will be used in subsequent commits to generate AML bytecode which would enable us to generate ACPI tables ourselves. [1]: https://uefi.org/specs/ACPI/6.5/20_AML_Specification.html Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com>
Implement NameSeg and NameString encoding per ACPI Specification Section 20.2.2 [1]. Single segments encode as 4 bytes padded with underscores, dual segments use DualNamePrefix and three or more use MultiNamePrefix with a count byte. Also implement EISA ID compression for hardware identification strings like "PNP0A08". [1]: https://uefi.org/specs/ACPI/6.4_A/20_AML_Specification.html#name-objects-encoding Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com>
Add AML bytecode generation to mainly support dynamically generating ACPI tables and control methods. The bytecode is built in a single pass by directly writing to the output buffer. AML scopes encode their length in a 1-4 byte PkgLength field at the start[1]. Since we don't know the final size until the scope's content is fully written, reserve 4 bytes when opening a scope upfront and splice in the actual encoded length when the scope closes. This avoids complexity of having to build an in memory tree and then walk it twice to measure and serialize. The RAII guards automatically close scopes and finalize the PkgLength on drop. Those guards hold a mutable borrow on the builder so the borrow checker won't let us close a parent while a child scope is still open. The limitation of this approach is that the content has to be written in output order but that is not a big issue for the use case of VM device descriptions. [1]: ACPI Specification Section 20.2.4 https://uefi.org/specs/ACPI/6.4_A/20_AML_Specification.html#package-length-encoding Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com>
Implement ResourceTemplateBuilder for constructing resource descriptors used in methods like _CRS. Supports QWord/DWord memory and I/O ranges, Word bus numbers and IRQ descriptors per ACPI Specification Section 6.4 [1]. [1]: https://uefi.org/specs/ACPI/6.4_A/06_Device_Configuration.html#resource-data-types-for-acpi Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com> Signed-off-by: glitzflitz <ameynarkhede03@gmail.com>
Export public API for AML generation AmlBuilder, AmlWriter trait, guard types (ScopeGuard, DeviceGuard, MethodGuard), EisaId and ResourceTemplateBuilder. This would enable generating the dynamic bytecode used in tables like DSDT. Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com>
glitzflitz
force-pushed
the
acpi_fwcfg_reord
branch
from
d05da54 to
0bf945c
Compare
Add DSDT generation that provides the guest OS with device information via AML. The DSDT contains _SB.PCI0 describing the PCIe host bridge with bus number and MMIO resources. The ECAM is reserved via a separate PNP0C02 motherboard resources device (_SB.MRES) rather than in the PCI host bridge's _CRS. This is required by PCI Firmware Spec 3.2, sec 4.1.2. Also add the DsdtGenerator trait that will be implemented by each device in DSDT to expose its ACPI description. Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com>
Since we can generation our own ACPI tables, implement DsdtGenerator trait for serial console device to expose it in generated DSDT. Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com>
Add AT keyboard controller resources to allow guest to enumerate the i8042 controller. Only keyboard is added to match the OVMF's existing behaviour for now. Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com>
Implement DsdtGenerator for QemuPvPanic to export it via new DSDT. Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com>
The OS calls _OSC on the PCIe host bridge to negotiate control of native PCIe features like hotplug, AER and PME. Without _OSC, Linux logs warning about missing capability negotiation(_OSC: platform retains control of PCIe features (AE_NOT_FOUND). Since as of now we don't have support for any PCIe handling, no capabilities are exposed. In future when PCIe handling is implemented the supported bits can be simply unmasked to expose them to the guest. Also to simplify the aml generation of _OSC itself introduce some high level wrappers around aml generation. [1]: https://learn.microsoft.com/en-us/windows-hardware/drivers/pci/enabling-pci-express-native-control Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com>
Combine all ACPI tables into the format expected by firmware(OVMF) by using fw_cfg's table-loader commands for address patching and checksum computation. Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com>
glitzflitz
force-pushed
the
acpi_fwcfg_reord
branch
from
0bf945c to
2e51b62
Compare
|
I pushed the new changes to move table structs out of |
|
Oops I missed the case of base -> new -> base Currently we have The "unset" state is being lost once a VM touches new propolis in this scenario
All tests should pass now |
Integrate the new ACPI table generation into propolis-standalone and propolis-server. Also replace hardcoded memory region addresses with constants that align with ACPI table definitions. The PCIe ECAM base is kept same as before at 0xe000_0000 (3.5GB) to match existing i440fx chipset ECAM placement. ECAM is no longer added to the E820 map as reserved memory since it is MMIO space properly described in the MCFG ACPI table. Guest physical memory map: 0x0000_0000 - 0xbfff_ffff Low RAM (up to 3 GiB) 0xc000_0000 - 0xffff_ffff PCI hole (1 GiB MMIO region) 0xc000_0000 - 0xdfff_ffff 32-bit PCI MMIO 0xe000_0000 - 0xefff_ffff PCIe ECAM (256 MiB, 256 buses) 0xfec0_0000 IOAPIC 0xfed0_0000 HPET 0xffe0_0000 - 0xffff_ffff Bootrom (2 MiB) 0x1_0000_0000+ High RAM + 64-bit PCI MMIO e820 map as seen by guest: 0x0000_0000 - 0x0009_ffff Usable (640 KiB low memory) 0x0010_0000 - 0xbeaf_ffff Usable (~3 GiB main RAM) 0xbeb0_0000 - 0xbfb6_cfff Reserved (UEFI runtime/data) 0xbfb6_d000 - 0xbfbf_efff ACPI Tables + NVS 0xbfbf_f000 - 0xbffd_ffff Usable (top of low memory) 0xbffe_0000 - 0xffff_ffff Reserved (PCI hole) 0x1_0000_0000 - highmem Usable (high RAM above 4 GiB) To stay on safe side only enable using new ACPI tables for newly launched VMs. Old VMs using OVMF tables would keep using the same OVMF tables throughout multiple migrations. To verify this add the phd test as well for new VM launched with native tables, native tables preserved through migration and VM launched from old propolis without native tables stays with OVMF through multiple future migrations. Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com> Signed-off-by: glitzflitz <ameynarkhede03@gmail.com>
glitzflitz
force-pushed
the
acpi_fwcfg_reord
branch
from
2e51b62 to
61f0ed4
Compare
|
Hi @glitzflitz 👋 Apologies for the long wait to getting back to you here, but thank you very much for all the work you put in this PR! I'm starting to work on PCI hotplug, so this PR will be very useful 😄 As you mentioned, the ACPI tables generated here are different from the ones we currently pull from EDKII. The API flag you added does help us control when the new tables are released, but it also means that we're blocked in using the new table generation until we're confident that they will not cause issues in production environments, which could take a while. Chatting with @iximeow, we think that a more cautious approach would be to adjust this PR so the it generates tables that are identical to the ones we use today (or as close as possible at least), and then we modernize them little by little, and probably gate specific changes behind flags that users can opt-in/out of. Another point to consider is using the So for next steps, if you don't mind, I will take over this PR and make the following changes:
I will then do a more through review and fix things here and there as necessary. Let me know if you have any thoughts on this, and thank you again for the contribution! |
|
@lgfa29 the approach of matching new tables with old EDKII tables sounds totally reasonable to me. Feel free to take over the PR! |
Use the acpi_tables crate to generate the ACPI tables. The crate was missing some elements we needed, so it was forked for now. If changes are accepted and merged upstream we can stop using the fork. The ACPI tables were also kept identical to the current static EDK2 tables to allow us to move forward with table generation while minimizing risk.
lgfa29
force-pushed
the
acpi_fwcfg_reord
branch
from
4673ea1 to
a6b3ae3
Compare
4 participants
Background
As per #695, currently Propolis relies on
edk2-stable202105version of EDK2 OVMF to provide the ACPI tables to the guest as it was the last version that has included static tables.Another limitation is the guest only sees whatever OVMF decided to generate rather than what the hypervisor knows about the virtual/emulated hardware.
In newer versions, OVMF expects the VMM to generate a set of ACPI tables and expose them via the
fw_cfgtable-loader interface. Being able to generate ACPI tables also unlocks other opportunities for features like being able to chose which tables and control methods to expose, PCIe host bridge and switch emulation, supporting native PCIe hotplug etc.This PR addresses that limitation and adds mechanism to let propolis generate its own ACPI tables.
Implementation
Oveview
The series starts with implementing fw_cfg's table-loader mechanism to enable passing static tables to guest firmware(OVMF). Then the basic static tables like
RSDT,XSDTandRSDPetc are added.The AML bytecode for the tables are generated using the
acpi_tablescrate. To reduce the scope of changes introduced in this PR, the generated tables are as written as close as possible to the original OVMF tables. The only differences are:acpi_tables. This should have no functional difference and can help us determine if an instance is using the original OVMF tables or the new ones generated by Propolis.X_Firmware_Waking_Vector, which is kept unset.The
acpi_tablescrate is currently missing some functionalities needed to build the tables, and so we're currently using a fork. Where possible, the changes will be upstreamed and we'll hopefully be able to stop using the fork.In order to minimize changes to the DSDT table, the
FWDTmechanism for passing data from the guest to the firmware had to ported to Propolis as well. The original OVMF tables use an ACPIMethodto determine the 32-bit and 64-bit MMIO windows for the PCI bridge. The window ranges are read from anOperationRegiondefined in an SSDT table.The process to determine the actual values to set in
FWDTis a little more obscure. After laying out the memory space map, OVMF iterates over it and extracts the values for the 32-bit MMIO window as going from the end of the instance lowmemory region to the last MMIO region abovePcdOvmfFdBaseAddress.PcdOvmfFdBaseAddressis set asFW_BASE_ADDRESS, and its value depends onFD_SIZE_IN_KB, the firmware flash size. I haven't seen this value being modified anywhere, so I believe Propolis uses the default value of 4096, meaning thatPcdOvmfFdBaseAddressis defined as0xFFC00000.And so the end address of the PCI 32-bit MMIO window set in
FWDTis the highest MMIO address in the memory map lower than0xFFC00000. Enabling the OVMFDEBUG_GCDflag, we can retrieve the final memory map for a 2GB VM:The resulting 32-bit MMIO region set in
FWDTfor this example is0x80000000-0xFEF00000.Another curious aspect of this process is that the 64-bit MMIO region seems to always be set to 0, resulting in the DSDT table never declaring any 64-MMIO region for the PCI root. The commit that introduced the
FWDTregion values mention that only the 32-bits are populated.Since the generated tables are functionally identical to the original OVMF ones, they are introduced to Propolis withot any additional opt-[in/out] mechanism.
Details
The
fw_cfgInterfaceQEMU's
fw_cfginterface provides a mechanism for the hypervisor to expose files to guest firmware. Propolis already had basicfw_cfgsupport for the e820 memory map and bootrom. The ACPI implementation builds on that foundation.OVMF expects three specific
fw_cfgfiles for ACPI tables:The table-loader file contains a sequence of fixed-size commands that instruct OVMF to allocate memory, patch pointer fields and compute checksums. This is necessary because the tables contain absolute addresses that are only known after OVMF allocates memory for them.
In the proposed implementation in Add fw_cfg table-loader helpers for ACPI table generation ,
TableLoadergenerates three command types:fw_cfgfile with specified alignment in a given zoneThe commands are used when building the ACPI tables.
One thing to note is that OVMF actually ignores
etc/acpi/rsdpand the RSDP and XSDT tables. It opens all three files and processes the commands inetc/acpi/table-loaderon top ofetc/acpi/tables. But it processes theAddPointercommands one final time and only actually loads the tables have pointers to them, intentionally excluding the RSDP and XSDT tables.In practice this means that the RSDP and XSDT tables are always generated by OVMF and the
etc/acpi/rsdpis never read. This PR does generate these tables for completeness, but any changes to them will not be reflected in the guest when using OVMF.Note
The next sections discuss the original work for generating the tables and AML bytecode. Since the final approach was modified to follow the suggestions described in #999 (comment), the content no longer reflects the actual changes in this PR, so I ommitted them, but kept them hidden for reference.
Original discussion about AML and table generation
Static Table Generation
The simpler static tables that don't require AML bytecode are implemented first.
There are some minor differences between tables generated here and old tables from https://github.com/oxidecomputer/edk2.
In new _DSDT, the PCIe host bridge(PNPA08) is exposed(with _CID PNPA03 to support PCI) instead of just PCI one in https://github.com/oxidecomputer/edk2. _OSC method is also provided but since as of now propolis doesn't handle PCIe, no capability is advertised to the guest.
_PRT
The edk2 from https://github.com/oxidecomputer/edk2 uses legacy interrupts https://github.com/oxidecomputer/edk2/blob/907a5fd1763ce5ddd74001261e5b52cd200a25f9/OvmfPkg/AcpiTables/Dsdt.asl#L196
while the generated _PRT uses direct GSI based routing.
Legacy LPC bridge is skipped in generated tables so no LPC bridge, IRQ link devices and PIRQ register are present in new tables.
For ISA, PIC(PNP0000), DMA(PNP0200), Timer(PNP0100), RTC(PNP0B00), Speaker(PNP0800), FPU(PNP0C04), XTRA(PNP0C02) are skipped in new tables.
Since propolis does not have hotplug support yet SSDT is also skipped at the moment.
AML generation and usage
The DSDT contains AML bytecode for describing devices, methods and resources. AML has a hierarchical structure with scopes containing devices which contain named objects and methods. The encoding uses variable length packages.
Possible approaches
QEMU uses a C based approach with GArray buffers. Each AML construct is a function returning an Aml pointer that must be explicitly appended to its parent. The design is flexible but also has caveats for example, forgetting manual
aml_appendcall silently drops content and there is no type safety around what can be nested. Since we are not bound my limitations of C and have borrow checker with us, we can do better.crosvm defines a single
Amltrait with many implementing types. Each construct is a separate struct collecting children in a Vec. The usage pattern is usually a macro followed byto_aml_bytes()which recursively serializes the tree. Although this provides strong typing, its bit more complex and requires constructing the entire tree in memory before serialization. Package lengths use a two pass approach of first measuring then writing.Firecracker also follows a same pattern to crosvm with trait methods along with some additional error handling.
acpi_tables crate used by cloud-hypervisor: uses a dual trait design to split the problem into two traits:
Amlfor things that can be serialized andAmlSinkas the destination. The sink abstraction is nice because the same tree can write to a Vec or feed a checksum calculator without changing the serialization code. Its structurally similar to crosvm and the same two pass length encoding which gets bit complex when building nested hierarchies.Approach in this series
Introduce AML bytecode generation adds RAII guards that automatically finalize package lengths when dropped.
The core abstraction is an
AmlBuilderthat owns a single byte buffer plus guard types for Scope, Device and Method. Each guard holds a mutable borrow on the builder so we have compile time scope safety through the borrow checker. This way its impossible to miss closing any scope.Also using single buffer from
AmlBuilderavoids the overhead of dynamic dispatch as in crosvm and acpi_tables approach.Guards borrow the builder mutably and write content directly to its buffer. When a guard is created it writes the opcode, reserves 4 bytes for the package length (the maximum encoding size) and writes the name. When the guard drops it calculates the actual package length, encodes it in 1-4 bytes and splices out the unused reserved bytes.
Usage looks like
which looks structurally similar to ASL code that is compiled to AML bytecode.
The conditional content is simply an if statement due to RAII guards which avoids complexity of Option wrappers as needed in other cases mentioned above. The limitation in this design is that its less composable. There is no easy way to return a "partial device tree" from a function or store AML fragments for later use.
Note about Package Length Encoding
The ACPI specification Section 20.2.4 defines a variable length encoding for package sizes. A package length includes itself in the count which creates a circular dependency: the length must be known to encode it but the encoding affects the length. That is why two pass approach is often used as done by others.
The implementation in Introduce AML bytecode generation, simply reserves max 4 bytes when opening any scope and splices in the actual encoded length when the scope closes. This produces minimal output with a single pass through the data.
I'd be open to new ideas or going with another approach mentioned above as well :)
DsdtGenerator Trait
The
DsdtGeneratortrait enables device emulators to implement their ACPI descriptions to the DSDT. Devices can expose themselves in the DSDT by implementing theDsdtGeneratorandAmltrait and wiring it up throughLifecycle::as_dsdt_generator().The
DsdtGeneratortrait has one method:dsdt_scope()- returnsSystemBus,PciRoot, orLpcdepending on where the device belongs in the ACPI namespace.During DSDT construction, the registered generators are invoked within the appropriate scope.
See
LpcUartandPS2Ctrlfor examples.This keeps ACPI bits of device co-located with the device implementation rather than requiring a central place that knows about every device's resources and lets device own its ACPI description.
This approach should be expanded to other devices, pusing the DSDT table to be built primarily by generators. This would make the DSDT table structure more closely match the Propolis internal representation of these devices. Currently it's not possible to generate the exact same DSDT table as OVMF using the existing code structure. For example, the
LPCdevice is declared inside thePCI0namespace. In Propolis, this would require theI440FxHostBridgeto have a reference toPiix3Lpc. Both structs also lack some of the necessary information to generate the full table.Note
Another section omitted due to the change in approach.
Original discussion API changes
Wiring up new tables
The new table generation is controlled by a
native_acpi_tablesflag in the Board spec. Newly launched VMs have this set totrueand get new generated tables viafw_cfg. VMs migrating from older propolis versions won't have this field in their spec so it defaults tofalseand they keep using OVMF tables.So existing VMs can safely migrate to propolis generated tables without any guest visible changes to their ACPI tables. Only VMs launched with new version of propolis will use the new tables.
Future scope
Being able to generate ACPI tables now opens up several opportunities
CPU hotplug
The MADT generation could be extended to support processor hotplug by including Processor Local APIC entries for potential CPUs along with corresponding _MAT methods and processor container devices in the DSDT.
Memory hotplug
Memory hotplug requires adding memory device objects under _SB scope with _HID of PNP0C80. Each memory region would need _CRS , _STA and _EJ0 methods. Propolis could signal memory add/remove via ACPI notifications. This would enable dynamic memory ballooning and live resizing of guest RAM.
PCIe Native Hotplug
The _OSC method added in this series can be easily extended to report support for PCIe capabilities to the guest. Once propolis implements the hotplug controller logic, native PCIe hotplug can be enabled by updating the _OSC return value and adding the necessary _EJ0 and notification methods.
PCIe topology emulation
With DSDT generation, PCIe topologies with multiple host birdges and PCIe swicthes can be properly described to the guest. This would involve adding additional _BBN methods and extending the PCI routing tables for downstream ports.This would increase the number of devices that can be attached to guest.
Note
Propolis currently have limited PCIe support, and actually lack the ACPI constructs necessary to support it. The original PR made some changes to improve things, but these changes were reverted to keep the tables the same.
NUMA topology
For guests that benefit from memory locality awareness, SRAT and SLIT tables can be added following the same pattern as other static tables.
Testing
The process to validate that the generated ACPI tables match the original OVMF tables followed these steps:
acpidumpto dump the tables AML byte code.iaslto disassamble the tables.dmesgto capture the instante boot log (when applicable).fwtsto run ACPI tests (when applicable)./proc/iomemordevinfo -umatch the expected memory layout.These steps were completed in Propolis instances using the followint operating systems:
The tables were collected from an instance running unmodified Propolis code and then compared to Propolis built on this PR. To ensure minimal change the results were compared at the binary bytecode level using
xxdandwdiff.The results in indicate minimal changes to the table headers because of the different Compiler ID and revision, which result in changes to the table checksum. The original tables used
INTLorOVMFand the generated tables useRVAT. The other change, as mentioned earlier, is the FACS table revision (from 0 to 1).Tip
Pipe the content below to
colordiff --difftype=wdifffor coloured output.=== ./ssdt.dat === 00000000: 5353 4454 5700 0000 [-0112-] {+017d+} 5245 4448 4154 [-SSDTW.....REDHAT-] {+SSDTW....}REDHAT+} 00000010: 4f56 4d46 2020 2020 0100 0000 [-494e 544c-] {+5256 4154+} OVMF [-....INTL-] {+....RVAT+} 00000020: [-2906 1820-] {+0000 0001+} 5b80 4657 4454 000c [-18c0 b67f ).. [.FWDT......-] {+d6ee bf7f ....[.FWDT......+} 00000030: 0c30 0000 0008 5c5f 5333 5f12 0a04 0a01 .0....\_S3_..... 00000040: 0a00 0a00 0a00 085c 5f53 345f 120a 040a .......\_S4_.... 00000050: 020a 000a 000a 00 ....... === ./apic.dat === 00000000: 4150 4943 8000 0000 [-0103-] {+0196+} 4f56 4d46 2020 APIC......OVMF 00000010: 4f56 4d46 4544 4b32 2102 1320 [-4f56 4d46-] {+5256 4154+} OVMFEDK2!.. [-OVMF-] {+RVAT+} 00000020: [-9900-] 0000 {+0001+} 0000 e0fe 0100 0000 0008 0000 ................ 00000030: 0100 0000 0008 0101 0100 0000 010c 0200 ................ 00000040: 0000 c0fe 0000 0000 020a 0000 0200 0000 ................ 00000050: 0000 020a 0005 0500 0000 0d00 020a 0009 ................ 00000060: 0900 0000 0d00 020a 000a 0a00 0000 0d00 ................ 00000070: 020a 000b 0b00 0000 0d00 0406 ff00 0001 ................ === ./facs.dat === 00000000: 4641 4353 4000 0000 0000 0000 0000 0000 FACS@........... 00000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000020: {+0100+} 0000 0000 0000 0000 0000 0000 0000 [-0000-] ................ 00000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................ === ./facp.dat === 00000000: 4641 4350 f400 0000 [-03c5-] {+0338+} 4f56 4d46 2020 [-FACP......OVMF-] {+FACP.....8OVMF+} 00000010: 4f56 4d46 4544 4b32 2102 1320 [-4f56 4d46-] {+5256 4154+} OVMFEDK2!.. [-OVMF-] {+RVAT+} 00000020: [-9900-] 0000 [-00e0-] {+0001 00c0+} bf7f [-00a0-] {+00c0+} b77f 0000 0900 ................ 00000030: b200 0000 f1f0 0000 00b0 0000 0000 0000 ................ 00000040: 04b0 0000 0000 0000 0000 0000 08b0 0000 ................ 00000050: e0af 0000 0000 0000 0402 0004 0400 0000 ................ 00000060: 6500 e903 0000 0000 0000 0000 0000 0000 e............... 00000070: a505 0000 0108 0000 f90c 0000 0000 0000 ................ 00000080: 0600 0000 0000 0000 0000 0000 [-00a0-] {+00c0+} b77f ................ 00000090: 0000 0000 0120 0000 00b0 0000 0000 0000 ..... .......... 000000a0: 0000 0000 0000 0000 0000 0000 0110 0000 ................ 000000b0: 04b0 0000 0000 0000 0000 0000 0000 0000 ................ 000000c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000000d0: 0120 0000 08b0 0000 0000 0000 0120 0000 . ........... .. 000000e0: e0af 0000 0000 0000 0000 0000 0000 0000 ................ 000000f0: 0000 0000 .... === ./dsdt.dat === 00000000: 4453 4454 220d 0000 [-016a-] {+01ca+} 494e 5445 4c20 [-DSDT"....jINTEL-] {+DSDT".....INTEL+} 00000010: 4f56 4d46 2020 2020 0400 0000 [-494e 544c-] {+5256 4154+} OVMF [-....INTL-] {+....RVAT+} 00000020: [-2906 1820-] {+0000 0001+} a018 0015 5c2f 045f 5342 5f50 [-).. ....\/._SB_P-] {+........\/._SB_P+} 00000030: 4349 305f 4352 5346 5744 540a 0008 5f53 CI0_CRSFWDT..._S 00000040: 305f 1207 040a 0500 0000 085f 5335 5f12 0_........._S5_. 00000050: 0604 0000 0000 104b cc5f 5342 5f5b 8243 .......K._SB_[.C 00000060: cc50 4349 3008 5f48 4944 0c41 d00a 0308 .PCI0._HID.A.... 00000070: 5f41 4452 0008 5f42 424e 0008 5f55 4944 _ADR.._BBN.._UID 00000080: 0008 4352 4553 1142 070a 6e88 0d00 020c ..CRES.B..n..... 00000090: 0000 0000 00ff 0000 0000 0147 01f8 0cf8 ...........G.... 000000a0: 0c01 0888 0d00 010c 0300 0000 00f7 0c00 ................ 000000b0: 00f8 0c88 0d00 010c 0300 0000 0dff ff00 ................ 000000c0: 0000 f387 1700 000c 0300 0000 0000 000a ................ 000000d0: 00ff ff0b 0000 0000 0000 0002 0087 1700 ................ 000000e0: 000c 0100 0000 0000 0000 f8ff fffb ff00 ................ 000000f0: 0000 0000 00fc 0779 0008 4352 3634 1133 .......y..CR64.3 00000100: 0a30 8a2b 0000 0c03 0000 0000 0000 0000 .0.+............ 00000110: 0000 0000 8000 0000 ffff ffff ff0f 0000 ................ 00000120: 0000 0000 0000 0000 0000 0000 800f 0000 ................ 00000130: 7900 1443 115f 4352 5308 5b81 2a46 5744 y..C._CRS.[.*FWD 00000140: 5404 5030 535f 4004 5030 455f 4004 5030 T.P0S_@.P0E_@.P0 00000150: 4c5f 4004 5031 535f 4004 5031 455f 4004 L_@.P1S_@.P1E_@. 00000160: 5031 4c5f 4004 5b81 4304 4657 4454 0350 P1L_@.[.C.FWDT.P 00000170: 3053 4c20 5030 5348 2050 3045 4c20 5030 0SL P0SH P0EL P0 00000180: 4548 2050 304c 4c20 5030 4c48 2050 3153 EH P0LL P0LH P1S 00000190: 4c20 5031 5348 2050 3145 4c20 5031 4548 L P1SH P1EL P1EH 000001a0: 2050 314c 4c20 5031 4c48 208a 4352 4553 P1LL P1LH .CRES 000001b0: 0a5c 5053 3332 8a43 5245 530a 6050 4533 .\PS32.CRES.`PE3 000001c0: 328a 4352 4553 0a68 504c 3332 7050 3053 2.CRES.hPL32pP0S 000001d0: 4c50 5333 3270 5030 454c 5045 3332 7050 LPS32pP0ELPE32pP 000001e0: 304c 4c50 4c33 32a0 1390 9350 3153 4c00 0LLPL32....P1SL. 000001f0: 9350 3153 4800 a443 5245 53a1 4a04 8f43 .P1SH..CRES.J..C 00000200: 5236 340a 0e50 5336 348f 4352 3634 0a16 R64..PS64.CR64.. 00000210: 5045 3634 8f43 5236 340a 2650 4c36 3470 PE64.CR64.&PL64p 00000220: 5031 535f 5053 3634 7050 3145 5f50 4536 P1S_PS64pP1E_PE6 00000230: 3470 5031 4c5f 504c 3634 8443 5245 5343 4pP1L_PL64.CRESC 00000240: 5236 3460 a460 1444 525f 5052 5400 a412 R64`.`.DR_PRT... 00000250: 4b51 4012 1104 0bff ff00 5e2e 4c50 435f KQ@.......^.LPC_ 00000260: 4c4e 4b44 0012 1104 0bff ff01 5e2e 4c50 LNKD........^.LP 00000270: 435f 4c4e 4b41 0012 1204 0bff ff0a 025e C_LNKA.........^ 00000280: 2e4c 5043 5f4c 4e4b 4200 1212 040b ffff .LPC_LNKB....... 00000290: 0a03 5e2e 4c50 435f 4c4e 4b43 0012 1304 ..^.LPC_LNKC.... 000002a0: 0cff ff01 0000 5e2e 4c50 435f 4c4e 4b53 ......^.LPC_LNKS 000002b0: 0012 1304 0cff ff01 0001 5e2e 4c50 435f ..........^.LPC_ 000002c0: 4c4e 4b42 0012 1404 0cff ff01 000a 025e LNKB...........^ 000002d0: 2e4c 5043 5f4c 4e4b 4300 1214 040c ffff .LPC_LNKC....... 000002e0: 0100 0a03 5e2e 4c50 435f 4c4e 4b44 0012 ....^.LPC_LNKD.. 000002f0: 1304 0cff ff02 0000 5e2e 4c50 435f 4c4e ........^.LPC_LN 00000300: 4b42 0012 1304 0cff ff02 0001 5e2e 4c50 KB..........^.LP 00000310: 435f 4c4e 4b43 0012 1404 0cff ff02 000a C_LNKC.......... 00000320: 025e 2e4c 5043 5f4c 4e4b 4400 1214 040c .^.LPC_LNKD..... 00000330: ffff 0200 0a03 5e2e 4c50 435f 4c4e 4b41 ......^.LPC_LNKA 00000340: 0012 1304 0cff ff03 0000 5e2e 4c50 435f ..........^.LPC_ 00000350: 4c4e 4b43 0012 1304 0cff ff03 0001 5e2e LNKC..........^. 00000360: 4c50 435f 4c4e 4b44 0012 1404 0cff ff03 LPC_LNKD........ 00000370: 000a 025e 2e4c 5043 5f4c 4e4b 4100 1214 ...^.LPC_LNKA... 00000380: 040c ffff 0300 0a03 5e2e 4c50 435f 4c4e ........^.LPC_LN 00000390: 4b42 0012 1304 0cff ff04 0000 5e2e 4c50 KB..........^.LP 000003a0: 435f 4c4e 4b44 0012 1304 0cff ff04 0001 C_LNKD.......... 000003b0: 5e2e 4c50 435f 4c4e 4b41 0012 1404 0cff ^.LPC_LNKA...... 000003c0: ff04 000a 025e 2e4c 5043 5f4c 4e4b 4200 .....^.LPC_LNKB. 000003d0: 1214 040c ffff 0400 0a03 5e2e 4c50 435f ..........^.LPC_ 000003e0: 4c4e 4b43 0012 1304 0cff ff05 0000 5e2e LNKC..........^. 000003f0: 4c50 435f 4c4e 4b41 0012 1304 0cff ff05 LPC_LNKA........ 00000400: 0001 5e2e 4c50 435f 4c4e 4b42 0012 1404 ..^.LPC_LNKB.... 00000410: 0cff ff05 000a 025e 2e4c 5043 5f4c 4e4b .......^.LPC_LNK 00000420: 4300 1214 040c ffff 0500 0a03 5e2e 4c50 C...........^.LP 00000430: 435f 4c4e 4b44 0012 1304 0cff ff06 0000 C_LNKD.......... 00000440: 5e2e 4c50 435f 4c4e 4b42 0012 1304 0cff ^.LPC_LNKB...... 00000450: ff06 0001 5e2e 4c50 435f 4c4e 4b43 0012 ....^.LPC_LNKC.. 00000460: 1404 0cff ff06 000a 025e 2e4c 5043 5f4c .........^.LPC_L 00000470: 4e4b 4400 1214 040c ffff 0600 0a03 5e2e NKD...........^. 00000480: 4c50 435f 4c4e 4b41 0012 1304 0cff ff07 LPC_LNKA........ 00000490: 0000 5e2e 4c50 435f 4c4e 4b43 0012 1304 ..^.LPC_LNKC.... 000004a0: 0cff ff07 0001 5e2e 4c50 435f 4c4e 4b44 ......^.LPC_LNKD 000004b0: 0012 1404 0cff ff07 000a 025e 2e4c 5043 ...........^.LPC 000004c0: 5f4c 4e4b 4100 1214 040c ffff 0700 0a03 _LNKA........... 000004d0: 5e2e 4c50 435f 4c4e 4b42 0012 1304 0cff ^.LPC_LNKB...... 000004e0: ff08 0000 5e2e 4c50 435f 4c4e 4b44 0012 ....^.LPC_LNKD.. 000004f0: 1304 0cff ff08 0001 5e2e 4c50 435f 4c4e ........^.LPC_LN 00000500: 4b41 0012 1404 0cff ff08 000a 025e 2e4c KA...........^.L 00000510: 5043 5f4c 4e4b 4200 1214 040c ffff 0800 PC_LNKB......... 00000520: 0a03 5e2e 4c50 435f 4c4e 4b43 0012 1304 ..^.LPC_LNKC.... 00000530: 0cff ff09 0000 5e2e 4c50 435f 4c4e 4b41 ......^.LPC_LNKA 00000540: 0012 1304 0cff ff09 0001 5e2e 4c50 435f ..........^.LPC_ 00000550: 4c4e 4b42 0012 1404 0cff ff09 000a 025e LNKB...........^ 00000560: 2e4c 5043 5f4c 4e4b 4300 1214 040c ffff .LPC_LNKC....... 00000570: 0900 0a03 5e2e 4c50 435f 4c4e 4b44 0012 ....^.LPC_LNKD.. 00000580: 1304 0cff ff0a 0000 5e2e 4c50 435f 4c4e ........^.LPC_LN 00000590: 4b42 0012 1304 0cff ff0a 0001 5e2e 4c50 KB..........^.LP 000005a0: 435f 4c4e 4b43 0012 1404 0cff ff0a 000a C_LNKC.......... 000005b0: 025e 2e4c 5043 5f4c 4e4b 4400 1214 040c .^.LPC_LNKD..... 000005c0: ffff 0a00 0a03 5e2e 4c50 435f 4c4e 4b41 ......^.LPC_LNKA 000005d0: 0012 1304 0cff ff0b 0000 5e2e 4c50 435f ..........^.LPC_ 000005e0: 4c4e 4b43 0012 1304 0cff ff0b 0001 5e2e LNKC..........^. 000005f0: 4c50 435f 4c4e 4b44 0012 1404 0cff ff0b LPC_LNKD........ 00000600: 000a 025e 2e4c 5043 5f4c 4e4b 4100 1214 ...^.LPC_LNKA... 00000610: 040c ffff 0b00 0a03 5e2e 4c50 435f 4c4e ........^.LPC_LN 00000620: 4b42 0012 1304 0cff ff0c 0000 5e2e 4c50 KB..........^.LP 00000630: 435f 4c4e 4b44 0012 1304 0cff ff0c 0001 C_LNKD.......... 00000640: 5e2e 4c50 435f 4c4e 4b41 0012 1404 0cff ^.LPC_LNKA...... 00000650: ff0c 000a 025e 2e4c 5043 5f4c 4e4b 4200 .....^.LPC_LNKB. 00000660: 1214 040c ffff 0c00 0a03 5e2e 4c50 435f ..........^.LPC_ 00000670: 4c4e 4b43 0012 1304 0cff ff0d 0000 5e2e LNKC..........^. 00000680: 4c50 435f 4c4e 4b41 0012 1304 0cff ff0d LPC_LNKA........ 00000690: 0001 5e2e 4c50 435f 4c4e 4b42 0012 1404 ..^.LPC_LNKB.... 000006a0: 0cff ff0d 000a 025e 2e4c 5043 5f4c 4e4b .......^.LPC_LNK 000006b0: 4300 1214 040c ffff 0d00 0a03 5e2e 4c50 C...........^.LP 000006c0: 435f 4c4e 4b44 0012 1304 0cff ff0e 0000 C_LNKD.......... 000006d0: 5e2e 4c50 435f 4c4e 4b42 0012 1304 0cff ^.LPC_LNKB...... 000006e0: ff0e 0001 5e2e 4c50 435f 4c4e 4b43 0012 ....^.LPC_LNKC.. 000006f0: 1404 0cff ff0e 000a 025e 2e4c 5043 5f4c .........^.LPC_L 00000700: 4e4b 4400 1214 040c ffff 0e00 0a03 5e2e NKD...........^. 00000710: 4c50 435f 4c4e 4b41 0012 1304 0cff ff0f LPC_LNKA........ 00000720: 0000 5e2e 4c50 435f 4c4e 4b43 0012 1304 ..^.LPC_LNKC.... 00000730: 0cff ff0f 0001 5e2e 4c50 435f 4c4e 4b44 ......^.LPC_LNKD 00000740: 0012 1404 0cff ff0f 000a 025e 2e4c 5043 ...........^.LPC 00000750: 5f4c 4e4b 4100 1214 040c ffff 0f00 0a03 _LNKA........... 00000760: 5e2e 4c50 435f 4c4e 4b42 005b 8245 5b4c ^.LPC_LNKB.[.E[L 00000770: 5043 5f08 5f41 4452 0c00 0001 005b 824b PC_._ADR.....[.K 00000780: 044c 4e4b 5308 5f48 4944 0c41 d00c 0f08 .LNKS._HID.A.... 00000790: 5f55 4944 0008 5f53 5441 0a0b 1406 5f53 _UID.._STA...._S 000007a0: 5253 0114 065f 4449 5300 085f 5052 5311 RS..._DIS.._PRS. 000007b0: 0e0a 0b89 0600 0901 0900 0000 7900 140b ............y... 000007c0: 5f43 5253 00a4 5f50 5253 5b80 5052 5230 _CRS.._PRS[.PRR0 000007d0: 020a 600a 045b 811a 5052 5230 0050 4952 ..`..[..PRR0.PIR 000007e0: 4108 5049 5242 0850 4952 4308 5049 5244 A.PIRB.PIRC.PIRD 000007f0: 0814 1550 5354 4101 a009 7b68 0a80 00a4 ...PSTA...{h.... 00000800: 0a09 a104 a40a 0b14 3850 4352 5309 0842 ........8PCRS..B 00000810: 5546 3011 0e0a 0b89 0600 0901 0000 0000 UF0............. 00000820: 7900 8a42 5546 300a 0549 5251 57a0 0d92 y..BUF0..IRQW... 00000830: 7b68 0a80 0070 6849 5251 57a4 4255 4630 {h...phIRQW.BUF0 00000840: 0850 5052 5311 160a 1389 0e00 0903 0500 .PPRS........... 00000850: 0000 0a00 0000 0b00 0000 7900 5b82 4c06 ..........y.[.L. 00000860: 4c4e 4b41 085f 4849 440c 41d0 0c0f 085f LNKA._HID.A...._ 00000870: 5549 4401 140f 5f53 5441 00a4 5053 5441 UID..._STA..PSTA 00000880: 5049 5241 1411 5f44 4953 007d 5049 5241 PIRA.._DIS.}PIRA 00000890: 0a80 5049 5241 140f 5f43 5253 00a4 5043 ..PIRA.._CRS..PC 000008a0: 5253 5049 5241 140b 5f50 5253 00a4 5050 RSPIRA.._PRS..PP 000008b0: 5253 1417 5f53 5253 018a 680a 0549 5251 RS.._SRS..h..IRQ 000008c0: 5770 4952 5157 5049 5241 5b82 4d06 4c4e WpIRQWPIRA[.M.LN 000008d0: 4b42 085f 4849 440c 41d0 0c0f 085f 5549 KB._HID.A...._UI 000008e0: 440a 0214 0f5f 5354 4100 a450 5354 4150 D...._STA..PSTAP 000008f0: 4952 4214 115f 4449 5300 7d50 4952 420a IRB.._DIS.}PIRB. 00000900: 8050 4952 4214 0f5f 4352 5300 a450 4352 .PIRB.._CRS..PCR 00000910: 5350 4952 4214 0b5f 5052 5300 a450 5052 SPIRB.._PRS..PPR 00000920: 5314 175f 5352 5301 8a68 0a05 4952 5157 S.._SRS..h..IRQW 00000930: 7049 5251 5750 4952 425b 824d 064c 4e4b pIRQWPIRB[.M.LNK 00000940: 4308 5f48 4944 0c41 d00c 0f08 5f55 4944 C._HID.A...._UID 00000950: 0a03 140f 5f53 5441 00a4 5053 5441 5049 ...._STA..PSTAPI 00000960: 5243 1411 5f44 4953 007d 5049 5243 0a80 RC.._DIS.}PIRC.. 00000970: 5049 5243 140f 5f43 5253 00a4 5043 5253 PIRC.._CRS..PCRS 00000980: 5049 5243 140b 5f50 5253 00a4 5050 5253 PIRC.._PRS..PPRS 00000990: 1417 5f53 5253 018a 680a 0549 5251 5770 .._SRS..h..IRQWp 000009a0: 4952 5157 5049 5243 5b82 4d06 4c4e 4b44 IRQWPIRC[.M.LNKD 000009b0: 085f 4849 440c 41d0 0c0f 085f 5549 440a ._HID.A...._UID. 000009c0: 0414 0f5f 5354 4100 a450 5354 4150 4952 ..._STA..PSTAPIR 000009d0: 4414 115f 4449 5300 7d50 4952 440a 8050 D.._DIS.}PIRD..P 000009e0: 4952 4414 0f5f 4352 5300 a450 4352 5350 IRD.._CRS..PCRSP 000009f0: 4952 4414 0b5f 5052 5300 a450 5052 5314 IRD.._PRS..PPRS. 00000a00: 175f 5352 5301 8a68 0a05 4952 5157 7049 ._SRS..h..IRQWpI 00000a10: 5251 5750 4952 445b 8233 5049 435f 085f RQWPIRD[.3PIC_._ 00000a20: 4849 440b 41d0 085f 4352 5311 200a 1d47 HID.A.._CRS. ..G 00000a30: 0120 0020 0000 0247 01a0 00a0 0000 0247 . . ...G.......G 00000a40: 01d0 04d0 0400 0222 0400 7900 5b82 4e04 ......."..y.[.N. 00000a50: 444d 4143 085f 4849 440c 41d0 0200 085f DMAC._HID.A...._ 00000a60: 4352 5311 380a 3547 0100 0000 0000 1047 CRS.8.5G.......G 00000a70: 0181 0081 0000 0347 0187 0087 0000 0147 .......G.......G 00000a80: 0189 0089 0000 0347 018f 008f 0000 0147 .......G.......G 00000a90: 01c0 00c0 0000 202a 1000 7900 5b82 2554 ...... *..y.[.%T 00000aa0: 4d52 5f08 5f48 4944 0c41 d001 0008 5f43 MR_._HID.A...._C 00000ab0: 5253 1110 0a0d 4701 4000 4000 0004 2201 RS....G.@.@...". 00000ac0: 0079 005b 8225 5254 435f 085f 4849 440c .y.[.%RTC_._HID. 00000ad0: 41d0 0b00 085f 4352 5311 100a 0d47 0170 A...._CRS....G.p 00000ae0: 0070 0000 0222 0001 7900 5b82 2253 504b .p..."..y.[."SPK 00000af0: 5208 5f48 4944 0c41 d008 0008 5f43 5253 R._HID.A...._CRS 00000b00: 110d 0a0a 4701 6100 6100 0101 7900 5b82 ....G.a.a...y.[. 00000b10: 2546 5055 5f08 5f48 4944 0c41 d00c 0408 %FPU_._HID.A.... 00000b20: 5f43 5253 1110 0a0d 4701 f000 f000 0010 _CRS....G....... 00000b30: 2200 2079 005b 824a 0d58 5452 4108 5f48 ". y.[.J.XTRA._H 00000b40: 4944 0c41 d00c 0208 5f55 4944 0108 5f43 ID.A...._UID.._C 00000b50: 5253 114e 0b0a ba47 0110 0010 0000 1047 RS.N...G.......G 00000b60: 0122 0022 0000 1e47 0144 0044 0000 1c47 ."."...G.D.D...G 00000b70: 0162 0062 0000 0247 0165 0065 0000 0b47 .b.b...G.e.e...G 00000b80: 0172 0072 0000 0e47 0180 0080 0000 0147 .r.r...G.......G 00000b90: 0184 0084 0000 0347 0188 0088 0000 0147 .......G.......G 00000ba0: 018c 008c 0000 0347 0190 0090 0000 1047 .......G.......G 00000bb0: 01a2 00a2 0000 1e47 01e0 00e0 0000 1047 .......G.......G 00000bc0: 01e0 01e0 0100 1047 0160 0160 0100 1047 .......G.`.`...G 00000bd0: 0170 0370 0300 0247 0102 0402 0400 0147 .p.p...G.......G 00000be0: 0140 0440 0400 1047 01e0 afe0 af00 0447 .@.@...G.......G 00000bf0: 0100 b000 b000 4086 0900 0000 00c0 fe00 ......@......... 00000c00: 1000 0086 0900 0000 00e0 fe00 0010 0079 ...............y 00000c10: 005b 8237 5053 324b 085f 4849 440c 41d0 .[.7PS2K._HID.A. 00000c20: 0303 085f 4349 440c 41d0 030b 085f 4352 ..._CID.A...._CR 00000c30: 5311 180a 1547 0160 0060 0000 0147 0164 S....G.`.`...G.d 00000c40: 0064 0000 0122 0200 7900 5b82 3755 4152 .d..."..y.[.7UAR 00000c50: 3108 5f48 4944 0c41 d005 0108 5f44 444e 1._HID.A...._DDN 00000c60: 0d43 4f4d 3100 085f 5549 4401 085f 4352 .COM1.._UID.._CR 00000c70: 5311 110a 0e47 01f8 03f8 0301 0823 1000 S....G.......#.. 00000c80: 0179 005b 8238 5541 5232 085f 4849 440c .y.[.8UAR2._HID. 00000c90: 41d0 0501 085f 4444 4e0d 434f 4d32 0008 A...._DDN.COM2.. 00000ca0: 5f55 4944 0a02 085f 4352 5311 110a 0e47 _UID..._CRS....G 00000cb0: 01f8 02f8 0201 0823 0800 0179 005b 8243 .......#...y.[.C 00000cc0: 0650 4556 5408 5f48 4944 0d51 454d 5530 .PEVT._HID.QEMU0 00000cd0: 3030 3100 085f 4352 5311 0d0a 0a47 0105 001.._CRS....G.. 00000ce0: 0505 0501 0179 005b 8050 454f 5201 0b05 .....y.[.PEOR... 00000cf0: 0501 5b81 0b50 454f 5201 5045 5054 0808 ..[..PEOR.PEPT.. 00000d00: 5f53 5441 0a0f 140e 5244 5054 0070 5045 _STA....RDPT.pPE 00000d10: 5054 60a4 6014 0c57 5250 5401 7068 5045 PT`.`..WRPT.phPE 00000d20: 5054 PTA few notes about the manual tests:
The BSD port of
acpidumpuses a different output format than that of Linux, Illumos, and Windows, so the comparison was made mostly by hand.Windows
EnumSystemFirmwareTablessyscall doesn't actually list all ACPI tables.acpidumpgets around this by hard-coding a process to dump the DSDT and XSDT, but this still leaves out the FACS table. I was able to retrieve it from the Windows Registry and compare it manually (luckily it's a small table filled with mostly zeros).fwtscurrently reportsnum. CPUs + 2errors and 1 warning, but they are also present when using the OVMF tables. We should look into fixing them.Automated tests are added where possible. Since the AML code is generated using the
acpi_tablescrate it didn't seem necessary to test that AML code was correct, so the tests focus on the what we do with the tables rather thatn the how we build them. The exception is the DSDT table because it uses theDsdtGeneratorpattern.The PR includes two PHD tests for proper VM testing. Currently Propolis CI uses a fairly minimal Alpine image, so
acpi_tables_generationchecks as much of the ACPI tables as possible without relying on external tools.acpi_tables_parseis a more comprehensive test but requires an image that hasacpidump,iasl, andfwtsinstalled.Note
The original test results are kept for reference, but the actual data is no longer reflective of the final version of this PR.
Original Testing
Testing
Testing
This is the dmesg of linux when using new tables. Now the standard OVMF bootrom can be used.
GlobalLockis not supported by propolis yet so the warning appears with OVMF tables as wellOVMF ACPI table dump
New ACPI table dump