All dumps are located in the tabletest package. The DSDT/SSDT dumps were
obtained by running an aml dump tool inside a virtualbox instance. The
dumps were disassembled using the iasl tool (version 20180105) from
Intel's reference ACPICA implementation.
The parser-testsuite dumps were written by hand to ensure that all
possible happy-paths in the parser were followed and then compiled into
AML using the same iasl tool.
The added TestParser function attempts to parse various sets of AML
dumps and then uses the object tree pretty-printer to obtain a dump of
the tree. The dump is then compared to an expected value (.exp files are
also placed in the tabletest package). The test code supports passing
the "-aml-regenerate-parser-exp-files" flag to update the exp files:
go test -run TestParser -aml-regenerate-parser-exp-files
ACPI entity definitions form a tree whose roots are a sequence of
pre-defined namespace objects. The parser stores all AML entities using
a space-optimized structure (Object). These objects are organized into a
tree via the ObjectTree structure.
Instead of storing pointers to other objects (i.e. siblings, children or
parent), objects use uint32 indices to objects managed by the
ObjectTree. This has the nice advantage of reducing the memory
requirements for our tree in half when running on 64-bits (4-bytes per
index vs 8-bytes per pointer) while also allowing us to recycle objects
that are explicitly freed by the parser.
The opcode tables establish a 2-level mapping between AML opcodes (regular
or extended) and a secondary table that allows the parser to decode each
opcode. This information includes:
- the opcode name
- the opcode flags (e.g. specifies a named object or parsing must be
deferred to a later pass)
- the expected arguments for each opcode and their types.
The list provides a uniform mapping for regular (one byte), extended
(0x1b + one byte) opcodes as well as some "internal" opcodes that will be
used by the parser to represent method calls, named fields and resolved
named object references.
The existing parser implementation has several issues and will, in many
cases incorrectly parse AML bytestreams that contain (among other
things):
- ambiguous method calls (same method name defined in multiple scopes)
- bank fields
- buffer fields where the length arg contains a method call
- named objects containing one or more '^' prefixes when defined inside
nested Scope elements (e.g. Scope(_SBRG){ Device(^PCIE){...} })
Unfortunately, these issues were discovered quite late while working on
the AML interpreter and while an attempt was made to correct some of
these (see previous commits), it turns out that the current codebase
cannot be refactored to fix all issues.
I have therefore decided to get rid of the current implementation and
replace it with a new one which will be created from scratch to address
all the above issues.
This commit just cleans up the codebase so the new parser can be added
via a future PR.
The previous implementation used brute-force approach where the parser
made an initial pass scanning the AML bytestream and looking for method
declaration opcodes. It then parsed out the method name and arg count
and populated a map which was used to detect the number of arguments to
be parsed upon encountering a method invocation. This approach proved to
be error-prone and would lead to an incorrect parse tree in the
following ASL example:
Method (FOOF, 1, NotSerialized)
{
Return ("bar")
}
Method (TST0, 0, NotSerialized)
{
FOOF(0)
\_SB.FOOF(2, 3)
}
Scope(\_SB){
// Another FOOF method in \_SB which takes a different arg count
Method (FOOF, 2, NotSerialized)
{
Return ("something")
}
}
In the above example the parser would correctly parse the first FOOF
call in TST0 but fail to parse the second invocation since the method
name contains a scope. The second invocation would actually yield the
following incorrect entity list (arguments appear as sibling entities):
Ref(\_SB.FOOF), Const(2), Const(3)
The new approach gets rid of the brute-force method and instead modifies
the initial parse of the tree not to parse the entities in the AML
method bodies but to instead track the start and end offset in the
AML stream for the body contents. In the second pass (where the parser
normally resolves symbol references), the parser can properly parse the
contents of method bodies since the entire AML tree is now known and the
parser can use the regular scope lookup rules to find the correct method
declaration for the invocation and figure out the argument count it
needs to parse.
This commit moves the AML entity definitions into the entity package and
makes them exportable so we can reference them from other packages.
In addition, the commit adds some missing entity structs that were
previously treated as generic entities (e.g. Processor, PowerResource
and ThermalZone).
Finally, this commit cleans the definitions and adds missing struct
attributes for the various field types (Field, IndexField, BankField)
This commit updates the post-parse step so that:
- the visitor not longer recurses into method bodies. Since code inside
methods may potentially generate dynamic/scoped entities or even use
conditional invocations (if CondRefOf(X) { X(...) }), symbol resolution
will be deferred to the AML interpreter.
- parent-child relationships between entities are checked and updated if
not properly specified
Since the ACPI standard allows forward function declarations this step
is required so we can properly parse the argument list for function
invocations. Contrary to other AML entities, method invocations do not
include any sort of pkgLength information so unless we track the
expected argument count for each function, our parser will not be able
to figure out where the argument list ends.
vmm.IdentityMapRegion can be used by device drivers that want to
establish an identity mapping for a contiguous physical memory block in
order to access some hardware or table.
