OSDev.org

So I've been attempting to parse AML tables, and am making pretty good progress - but there seems to be one outlier in the values given so far. My version of QEMU appears to be running ACPI v1.0, but this specification does not appear to differ between ACPI revisions.

As per ACPI spec 10b: https://uefi.org/sites/default/files/re ... rata_B.pdf, the following structure is to be maintained:

DefOpRegion := OpRegionOp NameString RegionSpace RegionOffset RegionLen
OpRegionOp := ExtOpPrefix 0x80
ExtOpPrefix := 0x5B

And by extension, we can derive that the structure of a DefOpRegion should start with:

0x5B 0x80 NameString RegionSpace RegionOffset RegionLen

Here are the 10 bytes around the byte I'm trying to understand, with the odd byte >highlighted< : (0x4 is irrelevant, 0x5C 0x0 is the NULL NAME identifier from a ScopeOp containing this code)

So the 0x5B 0x80 is present, but the next byte is 0x44 - which doesn't seem to fit the NameString definition required next:

NameString := <RootChar NamePath> | <PrefixPath NamePath>
RootChar := ‘\’
PrefixPath := Nothing | <‘^’ PrefixPath>

...so the next char should either be '\\' or '^', which means 'D' really shouldn't be there. Hopefully this is enough information to be complete, but I'm not quite understanding how I'm supposed to parse this 0x44 byte. Any help would be much appreciated, as I'm relatively new to AML parsing!

Edit with further testing:
I now have encountered another problem - the same thing happens on real hardware with a DefName, this time with 0x45 ('E'). It sort of looks like sometimes NameString is actually a NameSeg? Testing it more right now.

just a quick observation - PrefixPath can be nothing, which implies, NameString doesn't necessarily need to start either with \ or ^.

I hadn't quite interpreted the manual that way - but that makes complete sense, and correlates with the edit I just made to the first post! I guess it just starts with the next portion. Thank you so much for the help!