The execBlock method supports the various control flows defined by the
ACPI standard (next instr, continue, break and return). It is designed
so that it can be recursively invoked both AML methods and various
flow-altering opcodes (e.g. opIf, opWhile e.t.c.)
Due to the large number of opcodes that the AML VM needs to support,
using a long switch statement will not be as performant as setting up a
jump table due to the way that the go compiler generates code for long
switch statements on integer values (asm code indicates that binary
search is used to select the switch target).
For the time being, the populateJumpTable method will assign a
placeholder function to each jump table entry that just returns a
"opcode X not implemented error".
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.
The hal package automatically selects the best font from the list of
available fonts based on the console dimensions and the font priorities. The font
selection can be overriden by passing the "consoleFont" boot commandline
parameter to the kernel (e.g. consoleFont=terminus8x16)
Ths page offset is defined in arch/XXX/constants.inc and needs to be
passed to the kernel so we can correctly calculate the physical frame
addresses that correspond to the ELF section virtual memory addresses.
The GDT is initially loaded in the 32-bit rt0 code where we cannot use
the 48-bit VMA for the GDT table and instead we use its physical
address. This approach works as the rt0 code establishes an identity
mapping for the region 0-8M. However, when the kernel creates a more
granular PDT it only includes the VMA addresses for the kernel ELF image
sections making the 0-8M invalid. Unless the GDT is reloaded with the
VMA of the table, the CPU will cause a non-recoverable page fault when
it tries to restore the segment registers while returning from a
recoverable page fault.
