企业官网建设流程全解析

做固件这么多年，我有个挺深的体会：ACPI相关的问题，十有八九不是AML写不出来，而是系统描述表本身没写明白。上一篇文章把ACPI软件编程模型的大框架过了一遍，这篇按标题计划继续往表层面钻，集中聊最容易出事的三个细节——保留位和保留字段、兼容性、地址格式（Generic Address Structure，也就是GAS）。这三样东西看着不起眼，但它们恰恰是固件和操作系统之间全部契约的承重墙。你在BIOS里把一个保留位从0改成1，Windows可能直接给你一个无法解释的启动失败；你在GAS的Access Size字段填错一个值，Linux内核可能把整个FADT寄存器读串，然后ACPI事件全乱。别觉得夸张，下面提到的每个坑，都有对应的实机案例。

本文适合三类人看：写固件/BIOS的工程师，做OS内核或驱动开发的人，以及那些拿到一块板子第一次跑acpidump、对着二进制表发懵的新手。我会把ACPI规范6.5里关于表的规则，翻译成可以直接落地的检查动作。

1. 先把公共表头搞明白：Signature、Length、Checksum与那36字节的规矩

1.1 每一张表的前36个字节，是OS解析一切的起点

ACPI系统描述表种类非常多，FADT、MADT、DSDT、SSDT、HPET、MCFG、SRAT、SLIT……但不管哪张表，只要它走的是“系统描述表”的通道，开头这36个字节的布局完全一致。这部分在ACPI规范里叫Common Table Header，我建议你把它背到滚瓜烂熟，因为后面所有解析逻辑都建立在它上面。

先记住一个最反直觉的陷阱：FADT（Fixed ACPI Description Table）在讨论时都叫FADT，但它在二进制里的Signature是4字节大写的"FACP"。几乎每个新手第一次用acpidump导出表时都会找"FADT"找不到，最后发现文件名叫FACP。这不是笔误，是规范历史遗留，习惯就好。

OS解析表的时候，不是靠内存里某个固定位置去猜，而是先找到RSDP，再从RSDT/XSDT的表指针数组里读到每张表的物理地址，然后在表头验证Signature是否匹配目标。签名错了，整张表直接丢弃。所以写固件时，表里的Signature字段永远不要动，不要想着“我加个自定义签名方便调试”，OS只认它认识的字符。

1.2 Checksum算法很简单，但翻车的点不少

Checksum的算法本身只有一句话：从表头第一个字节到表最后一个字节，所有字节相加，结果取低8位，这个值必须等于0。用C写出来就是：

uint8_t acpi_table_checksum(uint8_t *table, size_t length) { uint8_t sum = 0; for (size_t i = 0; i < length; i++) { sum = (uint8_t)(sum + table[i]); } return sum; /* 合法表应该返回0 */ }

常见的翻车点有三个。第一，有人只对表头做校验，漏掉了整个表体，OS校验时算出来非零，表被直接判定无效。第二，有人把Length字段改小了，只校验改小后那段数据，但OS是按Length字段去读整张表的，多出来的部分全是垃圾，一样校验失败。第三，也是最隐蔽的：改表的时候往保留字段塞了调试数据，然后忘了重新计算Checksum。这个问题在开发阶段特别常见，因为自制的解析工具往往不校验，上了真OS才炸。

另外，RSDP（Root System Description Pointer）是特殊的，它不是“表”，而是一个指针结构。ACPI 2.0以后的RSDP有36个字节，包含两个Checksum：前20个字节的校验和，以及整个36字节的校验和。我第一次写RSDP解析器时只校验了前20字节，结果在支持XSDT的机器上拿到一个被改坏的扩展区域，排查了半天。记住：能用XSDT就认XSDT，同时一定要把两个校验都验完。

1.3 Length和Revision，是解析安全的第一条安全带

很多开发者刚接触表时，习惯用Revision去判断“我该按哪个版本的结构体解析”。这个方向是对的，但千万别把“表Revision”和“ACPI规范版本号”划等号。ACPI规范从1.0一路走到6.5，但每张表都有自己的Revision迭代节奏。比如MCFG表的Revision长期是1，哪怕机器的ACPI版本已经到6.x；FADT的Revision则独立经历了1、2、3、4、5、6多个版本。判断一张表该怎么解析，永远应该同时看两个信息：Signature、Revision，以及Length——因为Revision描述的是“这张表最低应该多长”，而Length告诉你“这张表实际有多长”。

OS解析的原则是：Length只用来圈定可读边界，Revision用来决定字段是否有意义。一个旧OS拿到一张新表，Length变了、Revision变高了，它不会崩溃，因为它只读自己认识的、且在Length范围内的字段，多余部分当不存在。这就是ACPI向后兼容的根基。反过来，新OS拿到旧表，如果缺字段，它得自己准备降级策略。比如FADT的Revision小于2时，没有64位的X_DSDT、X_PM_TMR_BLK这些扩展字段，OS就必须回退到32位的旧字段。

写固件时我的建议很简单：Length一定要和实际导出的字节数严格一致，差一个字节都可能让部分OS的parser数组越界；Revision则要按你实际使用的最小规范版本来填，不要为了“显得新”乱填高位版本号。

2. 保留位与保留字段：画一条“固件必须清零、OS必须忽略”的边界线

2.1 规范里的Reserved，其实是两个方向的约定

“保留位”可能是ACPI表里被误解最深的词。很多人以为Reserved就是“没人管的位置”，可以随便用。这是最危险的想法，ACPI规范里的Reserved从来不是“空着真可惜”，而是一份双向合同：对固件（表的写者）来说，保留字段必须写0；对OS（表的读者）来说，保留字段必须忽略，不能用于任何行为判断。

这两个方向缺一不可。固件把保留位置1，理论上OS应该忽略，但你无法保证世界上所有OS实现都严格按规范忽略；OS如果拿保留位做判断，那它自己也不合格。所以实务上的铁律是：固件写的表里，所有Reserved字节和位都要是0；OS读表时，对未知字段一律mask掉。

在寄存器层面，规则略有不同。ACPI规范区分三种语义：RW可读写、RO只读，以及“Reserved”和“Preserved”。对寄存器里的保留位，OS在做读改写（RMW）时，应该把保留位原样写回，而不是清零，因为硬件可能在这些位上放着OS不知道的状态。ACPI 6.x里专门有“Reserved and Preserved”这种表述，意思是“请保留原值”。这就容易出问题：固件在某个阶段把一个保留位改成1，OS按规范“保留原值”写回，硬件又依赖这个位的原始状态，两边就吵起来了。我见过最典型的案例，是EC通过GAS暴露的状态寄存器里，固件在一个保留位上放了标志，OS在睡眠恢复路径做RMW时把它清零写回，EC立刻走错分支，结果就是唤醒后风扇狂转、电池策略全乱。查了两轮才发现根本不是AML的问题，是固件把一个保留位当成了自己的状态位。所以，无论OS是保留还是清零，固件都不能把保留位当状态位用，这是规范性底线，也是稳定性底线。

2.2 挑几个真实高频的保留位现场

拿FADT的Flags字段举例，这个32位字段里从bit 0到bit 21基本都有定义，比如bit 20是HW_REDUCED_ACPI，bit 21是LOW_POWER_S0_IDLE_CAPABLE，而bit 22到bit 31明确保留。有些固件喜欢往高位塞芯片组厂商的内部信息，这在Windows和较新Linux上通常没事，因为OS会屏蔽未知位；但一旦某个旧版本内核的代码对Flags做了整体比较而不是按位比较，保留位就可能改变分支结果。更稳妥的做法是把Flags看成一组独立开关，只设置规范定义的位，其余保持0。

MADT（Multiple APIC Description Table）同样是重灾区。它的表头Flags只有bit 0是PC-AT Compatibility，规范要求这个位必须是1，其余位保留。而MADT里每个Local APIC条目也有自己的Flags：bit 0是Enabled，bit 1是Online Capable，其余保留。问题常常出在“条目长度”和“保留字段”的组合上：MADT每个条目自带Length，OS按Length跳过未知条目。如果你在一个条目的保留字节里塞了自定义数据，又顺手把条目Length改错了一个字节，那么从这一个条目开始，后面所有APIC条目全部分裂错位，多核系统直接变成单核。这不是危言耸听，ACPI驱动的内核邮件列表里每年都有类似报告。

AML层面也有“保留”的概念。ACPI命名空间里，所有以下划线开头的名字都是规范保留的，比如_OSI、_PR3、_DSM。OEM自定义方法如果也用下划线开头，就是在抢规范的地盘，轻则被OS忽略，重则被ACPICA直接拒绝加载整个DSDT。我给OEM提的建议永远是：自定义标识符老老实实字母开头，别碰下划线宇宙。

2.3 我亲眼见过的“保留位翻车”实录

说两个让我印象深刻的实机案例。

案例一，一张服务器主板的DSDT里，_OSC方法的返回值被固件塞了厂商自定义信息到保留位里。_OSC是OS用来和平台协商能力的机制，返回的Control/Status字段里明确划分了已定义位和保留位。一开始OS都没事，但某个Windows更新后对_OSC的校验严格了一个数量级，保留位非零被当作协商失败，PCIe热插拔能力被直接降级，整列NVMe盘在系统运行中变成了不可热插拔。排查到最后，不是AML语法问题，不是槽位信号问题，就是几个保留位多写了一串非零值。这个案例的教训是：你在保留字段里埋的任何“小聪明”，都是在赌未来所有OS实现都足够宽容，而历史上这种赌局输多赢少。

案例二，一块平板上，固件在FADT的保留字节里写入了调试版本号。做内部调试时自研工具读得津津有味，可一旦把这张表带到Windows HLK测试环境，OS解析到保留字段时虽然不会直接崩溃，但日志里出现了大量“Invalid FADT”的告警，把所有其他问题都掩盖了。最后把那个字段清零，整机立刻通过。很多时候，保留位翻车的后果不是当场崩，而是用一种非常难查的方式污染整个调试链路。

这种问题怎么批量发现？除了人肉盯表，我强烈推荐用工具。Linux生态里FWTS（Firmware Test Suite）专门有ACPI检查项，跑一句sudo fwts acpi -就能把所有表过一遍，保留字段、Checksum、Length、GAS地址合法性都在检查范围内。我每拿到一块新板子，第一件事就是跑FWTS，比瞪着眼睛看hexdump高效得多。

3. 兼容性设计：Revision号、_OSI与RSDT/XSDT到底在解决什么问题

3.1 表Revision是“每张表自己的版本号”，别和ACPI版本号混为一谈

前面提过，表的Revision和ACPI规范版本是两套坐标系。这里用一个具体例子把关系讲透。FADT的Revision是这张表最重要的兼容性开关之一，它的迭代和ACPI规范有对应关系，但也不是严格同步：

可以看到，FADT的Revision只到6，但ACPI规范已经出到6.5了。所以判断一张表“新不新”，永远看字段本身的Revision和实际内容，而不是看主板厂商宣传支持ACPI 6.5。有些6.5规范的平台上，FADT Revision依然停在5，这完全正常，不构成错误。

OS处理新旧表的策略也很有意思。Linux内核解析FADT时，会先根据Revision决定是否读取X_开头的64位字段，再结合Length做一次越界防护：即使Revision宣称支持某字段，Length不够也绝不去读。这套“Revision给意图、Length给边界”的组合，是所有表解析器的标准姿势，建议你写自研工具时也照抄。

3.2 RSDT与XSDT：两根指针数组的故事

ACPI的启动发现流程是这样的：OS在BIOS EBDA（Extended BIOS Data Area）和特定内存范围里找到RSDP，RSDP里有两个指针——32位的RSDT地址和64位的XSDT地址。RSDT是32位表指针数组，XSDT是64位表指针数组，数组里都是一张张系统描述表的物理地址。

XSDT是ACPI 2.0引入的，原因很简单：32位地址空间装不下高地址的表，只有64位指针才能引用4GB以上的物理位置。但规范并没有让XSDT完全取代RSDT，而是要求两者指向“同一批表”。实际板卡上常见的问题有两种：一种是BIOS只维护了XSDT而RSDT里放着旧地址，老系统（只认RSDT）启动时读到了过时表；另一种是BIOS把只在XSDT里暴露新表，导致老OS界面里功能缺失。反过来，有些固件为了“兼容老系统”，把RSDT做得完整、XSDT反而漏表，新OS一样会抓瞎。

Linux提供一个调试参数acpi=rsdt，强制内核只用RSDT而忽略XSDT。我在调一些老x86平台时就靠这个参数判断问题出在“XSDT指向的表坏了”还是“内核解析逻辑坏了”。但作为固件作者，正确做法永远是：RSDT和XSDT都要完整、一致、校验正确。如果你实在不想维护两份，至少保证XSDT完整，因为现代OS优先用XSDT。

3.3 _OSI是一面镜子，不是一个开关

_OSI是AML里一个非常特殊的方法，OS通过它向固件宣告自己“知道哪些接口”。固件在DSDT里可以写If (_OSI("Windows 2020"))之类的判断，然后决定走哪段AML逻辑。很多固件工程师把它当成“给某家OS开小灶”的后门，这没错，但要注意规范本意：_OSI是一个查询机制，固件通过它了解OS的能力，而不是一个万能开关。

实际开发里最常见的翻车场景是这样的：OEM希望自己的平台在Windows和Linux下都表现一致，于是在DSDT里写了大段依赖于_OSI返回值的逻辑，比如只在_OSI("Windows 2012")返回True时才启用某组Function Fixed Hardware，其他OS一律走旧路径。结果Linux端用户一升级发行版，ACPICA的行为变了，_OSI返回值变化，设备行为也跟着变。我在调试中习惯用Linux内核参数acpi_osi="!Windows 2012"去模拟“一个不认识该串的OS”，来验证固件在非Windows环境下会不会出问题。这个方法很土，但极其有效。

必须提醒的是，_OSI里的字符串不是随便传的，规范维护了一套Interface集合，比如"Windows 2009"、“Windows 2012”、“Linux”这类。自定义字符串通常返回不支持，所以不要把关键功能绑死在某个_OSI结果上，除非你有绝对理由确信目标平台永远只跑某一种OS。

3.4 向后兼容：新表配旧OS、旧表配新OS的生存法则

“新表配旧OS”的经典场景是把一张ACPI 6.x的表放到只支持ACPI 2.0的老系统上。老OS会按自己的Length和Revision上限去解析，不识别的字段直接跳过，所以只要你不乱动保留字段、不改变已有字段的语义，通常不会出大问题。真正的风险在于你“借用”了某个旧字段来表达新含义，这在老OS眼里就完全变味了。规范规定得很清楚：每加一个新能力，要么用新字段，要么用新表，绝不允许复用旧字段加约束。

“旧表配新OS”则更棘手。举一个热搜索词相关的例子：PCIe设备级电源状态。现代OS要管理PCIe设备的D3cold状态，依赖固件在_DSM或_PSx、_PR0/_PR3这些方法里提供电源资源描述。如果你这张表是在PCIe电源管理概念普及之前写的，固件压根没有_PR3方法，新OS的电源管理器就会发现“平台不支持D3cold”，于是设备永远停留在D3hot，功耗下不去。我在服务器平台上见过的情况是，一块GPU明明支持D3cold，因为AMT表里漏了_PR3，整机待机功耗多出几十瓦。新OS遇到这种情况不会报错，它只会静默放弃省电机会。这也是为什么“系统描述表和OS能力对齐”如此重要——表里没有的东西，OS永远不知道，也不会问。

4. Generic Address Structure（GAS）：寄存器怎么访问，全靠这一组小字段

4.1 GAS只有12个字节，却决定了寄存器访问的一切

GAS是ACPI 2.0起引入的通用寄存器描述结构，FADT里的X_PM1a_EVT_BLK、X_GPE0_BLK、HEST里的错误寄存器、DBG2里的调试寄存器，用的都是它。结构如下：

总长12字节。注意，是12字节，不是16。我在代码评审里见过有人按16字节分配GAS结构体，然后把后面4个字节当成自己的扩展字段，结果OS解析时用了规范定义的12字节，两边结构体长度对不上，表里的后续字段全线错位。此类问题一旦出现，几乎是灾难级的排查难度。

Address Space ID是整个GAS的灵魂，它告诉OS这串地址到底要去哪里访问。常见的取值如下：

4.2 Access Size说的是总线事务宽度，不是寄存器大小

这是GAS里最容易被误解的字段。很多人以为Register Bit Width是寄存器宽度，Access Size就应该是等价的访问宽度，直接填一样的值。这个理解错了一半。Register Bit Width是“这个寄存器有多少位是有效的”，Access Size是“OS做一次总线读/写用多大的事物流”。两者分开，是为了处理“寄存器没落在自然对齐边界上”的情况。

举个例子：一个16位宽的寄存器，真实硬件把它放在32位寄存器的高16位，也就是bit 16到bit 31。那GAS应该写成Register Bit Width=16，Register Bit Offset=16，Access Size=3（表示32位访问）。OS看到Access Size=3，就做一次32位读，再右移16位，取低16位作为寄存器的值。如果你把Access Size也填成2（16位），OS只做16位读，读到的恰好是位偏移错位后的垃圾。这类寄存器在电源管理和状态上报里特别常见，填错后症状不是崩溃，而是状态值整体偏移一个常数，极难用肉眼发现。

Access Size的合法取值是0到4，分别表示未定义、字节（8位）、字（16位）、双字（32位）、四字（64位）。填0是个馊主意，虽然有些OS实现会回退到按Register Bit Width处理，但行为不统一，日志还会打出警告。我的原则是：只要这个寄存器真实可访问，就把Access Size填成实际总线宽度，别偷懒。

4.3 不同Address Space的访问姿势差异很大

同样是GAS，Address Space ID不同，OS内部走的代码路径完全不同。

System Memory是最直观的。OS拿到Address后，要先把这段物理地址映射到内核态，然后按Access Size做内存读写。这里我见过一个非常危险的填法：寄存器还没分配好地址，先把GAS的Address填成0，指望OS忽略它。结果有些OS实现会把物理地址0直接映射，然后访问空指针，启动早期直接死机。Address填0的GAS，要么是整个结构该Retired，要么是你还没准备好，别把它当作“占位符”。

System I/O则是生成in/out指令访问端口。端口空间一般只有16位地址，但GAS的Address是64位，所以高48位必须为0。有的BIOS在32位地址系统里没事，但在64位系统里高位置了垃圾，OS用这个端口地址去访问，要么访问到错误端口，要么直接触发未解码总线周期。

PCI Configuration Space的GAS比较特殊：Address字段不是普通线性地址，而是被规范重新编码成Segment、Bus、Device、Function和Register的组合。具体位域布局我强烈建议每次写之前都去翻规范原文，不要凭记忆填，因为我在这个字段上吃过亏——凭印象写了一个“线性地址”，结果OS解析出来的总线号完全是乱码。在PCIe电源管理场景中，_PR3里描述的电源资源如果挂在PCI配置空间上，Access Size填错会导致OS在睡眠唤醒路径上读到脏状态，D3cold永远进不去，功耗问题又会绕回来。

Embedded Controller的GAS规则更死：只能按字节访问。EC协议本身是走0x62/0x66端口做命令和数据交换的，OS拿到GAS后需要通过完整的EC事务流程去读写指定偏移，而不是直接读端口。所以EC类型GAS的Register Bit Width必须填8，Address填的是EC内部偏移，不是端口号。填错的话，OS读出来的值永远是EC栈里的垃圾字节。

Functional Fixed Hardware（FFH）是个例外中的例外。它标记“这块寄存器由固定的硬件接口定义，不能用通用地址解码”，只能在规范明确允许的位置使用，比如FADT里某些特殊寄存器，以及配合Intel定义的MWAIT接口做C-state切换。你在GAS里看到Address Space ID为0x0A时，不要自己发明访问方式，去查芯片组手册和ACPI规范针对FFH的附加定义。

另外，字节序也是一个隐形的坑。GAS访问的内存和I/O寄存器，规范默认是Little-Endian，也就是和x86一致；但Embedded Controller和SMBus等空间要求按字节事务处理，一旦你把一个32位寄存器描述成EC地址，字节序和事务宽度会在内核里被组合成一场灾难。

4.4 从FADT出发，看GAS在真实表里怎么用

FADT是GAS用得最密集的表之一。Revision 2以上的FADT提供X_PM_TMR_BLK，用GAS描述PM Timer寄存器；提供X_GPE0_BLK，描述通用事件寄存器块；提供Reset Register，描述系统复位寄存器。以Reset Register为例，绝大多数平台上的实现是Address Space ID=1（System I/O）、Register Bit Width=8、Access Size=1（字节）、Address=0xCF9，ResetValue是0x06这类值。OS需要复位时，写ResetValue到该端口。如果固件把Access Size写成2（16位），OS做16位端口写，CF9端口的行为会因为多写了一个字节而变得不可预测，轻则复位失败，重则触发错误的总线周期。

PM Timer也是一个好例子：它通常是24位或32位自由运行计数器，有的平台把它挂在高位，偏移不为0。正确写法是Register Bit Width=24、Register Bit Offset=8、Access Size=3（32位读），OS读32位后右移8得到真正的计数值。如果Register Bit Offset填错成0，读出来的时间戳会整体偏移，导致ACPI定时器精度错乱，进而在某些OS里引发scheduler tick混乱。这类问题的隐蔽性极高，因为系统不会崩，只是行为“慢半拍”。

看GAS还有一个通用技巧：不要只看GAS本身，要看它和“非GAS的旧字段”之间怎么配合。FADT里很多寄存器同时有32位旧字段和64位新字段，比如PM_TMR_BLK和X_PM_TMR_BLK。OS优先用X_版本，但如果X_版本的GAS地址非法，而旧版本地址有效，不同OS的降级策略并不一样。固件的最优实践是让新旧两套地址保持一致且都有效，这样无论OS走哪条路径都不会踩坑。

5. 一张表的自我体检：从解析工具到板级验证的完整套路

5.1 先把手头工具用起来

在Linux上排ACPI问题，我最常用的路径是这几条命令：

# 查看当前系统已经加载了哪些表 ls /sys/firmware/acpi/tables/ # 把FACP表导出成原始二进制 sudo cp /sys/firmware/acpi/tables/FACP ./facp.bin # 一次性导出所有表，生成acpidump格式文件 sudo acpidump -o acpi_dump.dat # 从dump文件里拆分出原始AML二进制 acpixtract -a acpi_dump.dat # 反编译DSDT/SSDT成可读的ASL iasl -d dsdt.dat # 用FWTS给全部ACPI表做一次系统性体检 sudo fwts acpi -

/sys/firmware/acpi/tables/下每个文件就是一张表的原始二进制，文件名显示的往往是OS加载时用的名字，比如FACP、APIC、DSDT。很多新手找FADT找不到，就是因为这个原因——规范概念名和实际签名不一致。FWTS的acpi测试组会把保留字段、Checksum、表长、GAS地址合法性全部过一遍，是当前性价比最高的自动化体检方式。

5.2 我常用的表验收清单

如果你自己写固件、改DSDT，或者只是拿到一张别人交付的表要做评审，下面这份清单可以直接抄走：

• Length字段是否等于实际字节数？先从acpidump导出，再用工具比对。
• 整表Checksum是否为0？不是0的表，OS根本不会信任。
• 所有Reserved字段、Reserved位是否全为0？这是最便宜也最容易被忽略的一关。
• 每个GAS的六要素（Space ID、Bit Width、Bit Offset、Access Size、Address）是否和真实硬件一致？特别是Access Size，别偷懒填0。
• 新旧两套字段是否有冲突？比如FADT里的PM_TMR_BLK和X_PM_TMR_BLK，地址必须一致且有效。
• Revision是否和实际使用特性匹配？用了ACPI 6.x的特性，就别把表Revision停在1。
• 表在纯64位系统上是否有问题？检查所有Address的高位是否有垃圾值。

这些条目看着机械，但每一条都对应过我手里的真实故障。验收表不是走形式，是把高风险点提前拦在量产之前。

5.3 写表之前，先把自己当成OS

最后分享三个我一直在用的习惯。

第一个习惯：动手写表之前，先写一个只依赖Public Header的解析器。我常用Python的struct模块写个几十行的脚本，把FADT、MADT这类表按规范结构体解析一遍，打印所有字段。这个过程会让你强制把表头、Length、保留字段、GAS这些细节都过一遍，而不是看着厂商模板直接改。人眼很难连续盯几十个字段不出错，但脚本一次就能抓出结构体长度偏差。

第二个习惯：测试矩阵里至少要包含两代“性格不同”的OS。老OS会按Length忽略新字段，新OS会按Revision读取扩展字段。同一张表在这两类OS上行为一致，才叫真正的兼容。我在调试中常用Linux的acpi=rsdt和acpi_osi="!Windows 2012"这类参数去人为制造“更老、更严格”的环境，专门考验表在极限场景下的表现。

第三个习惯：所有自定义数据，一律不进保留字段，一律不用下划线开头命名，一律不靠_OSI返回值传递业务状态。这三条禁令看起来保守，但能省掉未来绝大多数“查无头绪”的兼容性问题。

做ACPI这行久了，你会发现真正的稳定性往往不是哪个大功能，而是这些零碎字段全对。每一个保留位、每一段地址、每一次校验，都是固件和OS之间的一行合同条款。写表时把它们当合同对待，出问题的概率会指数级下降。希望这篇能把你在ACPI系统描述表上的排查路径缩短一半，少走我当时走的弯路。