ACPI已经可以被Armv8通用服务器使用和支持，并且ACPI遵循Arm所制定的两个服务器标准：
- SBSA - Server Base System Architecture
- SBBR - Server Base Boot Requirements
Armv8 Linux内核代码实现了基于ACPI v5.1及其后续版本的一个简化硬件模型。关于ACPI的具体规范和相关文档，可以参考：
如果一个给定的Armv8系统没有遵循SBSA和SBBR的要求，或者不能用ACPI规范的要求来进行描述，则 ACPI 可能不适用于该系统。
SBSA和SBBR设定了关于如何建造符合工业界标准的Armv8服务器的要求，并且也可支持多个操作系统类型。
那么为什么需要在Arm生态上支持ACPI呢？
毕竟在Linux内核里，已经存在有多种技术可以描述不可枚举的硬件设备。归结起来，主要有如下几个要点：
- ACPI的字节码（AML)支持平台进行硬件行为编码，而设备树（Device Tree，DT）不能显式支持此特性。对于硬件设备商，支持硬件行为编码是一个使能操作系统支持新硬件设备的关键属性。
- ACPI的操作系统电源管理模块定义了一个功耗管理模型。该模型在限制了硬件平台针对特定模型能做什么的同时，仍然提供了硬件设计上的灵活性。
- 在企业级服务器环境下，ACPI已经建立了一套目前已经在生产环境中所使用的绑定规则（比如Reliability, Availability, Serviceability, RAS），而DT则没有。DT在某种方面确实也能定义类似的规则，但是坚持使用这种修改后的DT将意味着Arm和x86在固件和内核方面完全走了分裂的代码路径。
- 选择单个接口来描述硬件平台和操作系统之间的抽象层非常重要。如果要支持多个操作系统，硬件设备商可以不必同时支持DT和ACPI。而且，一个统一的接口，而不是每个操作系统都具有一个分裂的碎片化的接口，将提供更好的互操作性。
- 新的ACPI管理流程目前运行良好，Linux已经和硬件设备商、其他操作系统供应商处在同一个讨论桌前。目前，ACPI不再意味着只是Windows操作系统专有，Linux也不再是在ACPI领域从属于微软。现在通过UEFI论坛来进行ACPI管理。这种管理方式的变化，已经显著开放了ACPI规范的开发流程，当前相当大的 ACPI改动都正在被Linux所驱动。
使用ACPI的关键是支持模型。对于通用服务器，硬件行为的责任不能仅仅只是归属于内核的领地，而必须被区分为硬件平台和内核两部分，从而可以支持长时间的有序变化。过去操作系统需要理解硬件的所有细节，ACPI则解放了操作系统。操作系统不必为了每个硬件设备每次单独进行移植。这将允许硬件设备商不再依赖其无法控制的操作系统发布周期，同时也能承担设备功耗管理的责任。
因为硬件和操作系统供应商已经形成了ACPI这种可以支持通用计算生态系统的机制，从而其变得重要。ACPI基础技术设施已经就位，绑定规则也已就位，管理流程也已就位。反观DT, DT确实做到了Linux需要它与所有垂直整合硬件设备的事情，但是却没有能支持服务器供应商所需的良好流程。Linux也许可以通过DT实现该目标，但是这样做真的只是在重复发明轮子。ACPI已经满足了硬件设备商所需，微软也不会在DT方面进行合作。如果使用DT, 硬件设备商也不得不继续提供两套不同的固件接口，一套针对Linux，一套针对Windows。
ACPI和DT的关系
- 在Armv8内核中，驱动程序和内核子系统对于ACPI的支持永远不能和DT的支持在编译时互斥。
- 在启动阶段，内核将只能使用一种硬件描述方法。该方法依赖于bootloader所传递的参数。
- 无论是DT或者ACPI被使用，内核必须要一直能基于任一机制正常启动。
