用 REA 逆开华为 BoF-XX 的性能模式：MateBook D15 2022 在 Linux 下的真 Turbo 解锁

AI 辅助声明｜AI agent coding 辅助创作

本文的 REA 二进制检查、ACPI/WMI 协议核对、huawei-perf 实现与本地实测由 AI agent 参与完成。

机型、DMI、ACPI 表、EC 寄存器和功耗数据均来自这台 BoF-XX 的实际读取，结论只对同型号、同 BIOS/EC 固件成立。

声明

本文仅记录对相关设备的实际使用、维修或互操作研究，不隶属于任何厂商，也不代表厂商立场。

文中出现的产品名称、商标与上游项目名称仅用于事实性说明，归其各自所有者，不代表存在隶属或授权关系。

GNOME 的“性能模式”我用了很久。

直到发现它在这台 MateBook D15 上，只是把 energy_performance_preference 改成了 performance。

power-profiles-daemon 的 PlatformDriver 是 placeholder，/sys/firmware/acpi/platform_profile 根本不存在。

桌面把“性能”两个字显示出来了，但华为 EC 的功耗墙没有动。

我想知道这块主板到底有没有真正的性能模式，于是从出厂内核模块和 ACPI 表开始，把这条链路拆了一遍。

先把机器和现状钉死

这台机器的 DMI 和华为官方系列代码能对得上。

DMI 里只写 BoF-XX，不写零售名。

按华为官方支持列表，BoF 对应 MateBook D 15 2022 12 代酷睿版，所以下文把两者并列，但具体结论以本机 DMI 和 ACPI 为准。

1
cat /sys/class/dmi/id/{sys_vendor,product_name,product_version,board_name,board_version,bios_version}
2
cat /sys/class/dmi/id/product_sku

再看桌面电源模式到底做了什么。

1
powerprofilesctl list
2
ls -l /sys/firmware/acpi/platform_profile* 2>&1
3
cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
4
cat /sys/devices/system/cpu/cpufreq/policy0/energy_performance_preference

实测结果很直接。

所以“Performance”只是让 CPU 更愿意拉高频，并没有改变 EC 的持续功耗策略。

REA 先看出厂模块

REA（Reverse Engineer Anything）是一套通过 MCP 暴露给 agent 的二进制与固件分析工具。

本文用它检查出厂 huawei-wmi.ko 的身份、modinfo 和导入符号；REA 仓库 里有工具清单和使用边界。

我先确认这台机器上跑的 huawei-wmi 到底暴露了什么。

出厂模块是压缩的，先解压再做校验。

1
zstd -df /lib/modules/$(uname -r)/kernel/drivers/platform/x86/huawei-wmi.ko.zst -o /tmp/huawei-wmi.ko
2
sha256sum /tmp/huawei-wmi.ko
3
modinfo /tmp/huawei-wmi.ko | grep -E 'version|srcversion|vermagic|alias'

REA 的 kernel module parser 给出了模块身份、modinfo 和导入符号。

这台机器的模块 SHA-256 是 862b6c111c8f07edb0671154894e31a8f8f7115ad2d5b250cee6d122e0264c0c，srcversion 是 071C78DC2663E9200712E3C。

关键导入符号如下。

这说明出厂模块自己实现的能力很少，但它保留了一个 raw WMI 调用口。

/sys/kernel/debug/huawei-wmi/arg 是 0644，call 是 0400；写一个 64 位参数再读 call，就能让固件执行一次 HWMI 方法。

这里要说清楚边界。

REA 的 kernel module parser 负责确认出厂模块的身份、元数据和符号；代码级行为我用 mainline 源码和 ACPI 反编译交叉核对。

Ghidra provider 当时没有配置，所以我没有把 REA 当成反编译器使用，而是把它当成“出厂二进制事实”的检查工具。

ACPI 里的真开关

把 DSDT 和 SSDT 导出来，用 iasl 反编译。

1
mkdir -p /tmp/huawei-acpi
2
sudo cp /sys/firmware/acpi/tables/DSDT /tmp/huawei-acpi/
3
sudo cp /sys/firmware/acpi/tables/SSDT* /tmp/huawei-acpi/
4
cd /tmp/huawei-acpi
5
for f in DSDT SSDT*; do iasl -d "$f" >/dev/null 2>&1 || true; done

真正的方法在 SSDT8 的 \_SB.HWMI.WMAA。

它把输入当成 64 位小端，byte0 是 MFID，byte1 是 SFID，参数从 byte2 开始。

更有意思的是 WMIC++：只有第二次调用，WMIC == 2 时才真正分发。

1
Method (WMAA, 3, Serialized) {
2
    WMIC++
3
    CreateByteField (Arg2, 0, MFID)
4
    CreateByteField (Arg2, 1, SFID)
5
    Local1 = DerefOf (WMRP [One])
6
    CreateByteField (Local1, Zero, STAT)
7
    STAT = One
8
    If ((WMIC == 0x02)) {
9
        WMIC = Zero
10
        Switch (MFID) {
11
            Case (0x04) {
12
                Switch (SFID) {
13
                    Case (0x0E) { Local1 = GTUB (Local0) }
14
                    Case (0x0F) { Local1 = STUB (Local0) }
15
                }
16
            }
17
        }
18
    }
19
    Return (WMRP)
20
}

GTUB 和 STUB 在 DSDT 里。

GTUB 只读 EC 的 TUBO，STUB 则检查 AC 和电量，然后写 TDPS / TUBO。

1
Method (GTUB, 1, NotSerialized) {
2
    Name (BUFF, Buffer (0x0100){})
3
    CreateByteField (BUFF, Zero, STAT)
4
    CreateByteField (BUFF, One, STUB)
5
    STAT = Zero
6
    STUB = \_SB.PC00.LPCB.EC0.TUBO
7
    Return (BUFF)
8
}
9

10
Method (STUB, 1, NotSerialized) {
11
    Name (BUFF, Buffer (0x0100){})
12
    CreateByteField (Arg0, 0x02, TUBM)
13
    CreateByteField (BUFF, Zero, STAT)
14
    STAT = Zero
15
    If ((\_SB.PC00.LPCB.EC0.ACIN == Zero)) {
16
        STAT = One
17
        Return (BUFF)
18
    } ElseIf ((\_SB.PC00.LPCB.EC0.RSOC < 0x15)) {
19
        STAT = One
20
        Return (BUFF)
21
    }
22
    If ((TUBM == One)) {
23
        \_SB.PC00.LPCB.EC0.TDPS = One
24
        \_SB.PC00.LPCB.EC0.TUBO = One
25
        \_SB.PC00.LPCB.EC0._Q24 ()
26
    } ElseIf ((TUBM == Zero)) {
27
        \_SB.PC00.LPCB.EC0.TDPS = One
28
        \_SB.PC00.LPCB.EC0.TUBO = Zero
29
        \_SB.PC00.LPCB.EC0._Q23 ()
30
    } Else {
31
        STAT = One
32
    }
33
    Return (BUFF)
34
}

这段 ASL 把关键条件写得很清楚。

命令编码也随之确定。

_Q24 和 _Q23 还会把 WMEN 设成 0x02A1 / 0x02A0 并通知 HWMI。

mainline huawei-wmi 的 keymap 没有映射这两个事件，所以 Linux 里看不到“性能模式已切换”的 OSD；这不是 EC 没切换，而是没人接这个通知。

GitHub 上有没有人做过

我把能找到的公开实现都过了一遍。

结论很明确：Windows 端有人做完了，Linux 端缺一个把 STUB/GTUB 接到通用桌面的实现。

GNOME 扩展不是“写错了”，而是它依赖的 sysfs 从来不在 mainline 驱动里。

写一个 huawei-perf

实现没有绕路，直接用出厂模块留下的 debugfs 口。

写 arg，读 call，解析返回的 ACPI package 或 0x104 buffer，检查 status 和 payload[1]。

WMAA 需要两次调用，所以工具内部最多重试三次。

1
#define CMD_POWER_GET 0x00000E04ULL
2
#define CMD_POWER_SET 0x00000F04ULL
3

4
static int power_unlock_set(int on, struct wmi_reply *reply)
5
{
6
    uint64_t arg = CMD_POWER_SET | ((uint64_t)(on ? 1 : 0) << 16);
7
    return wmi_call(arg, reply, 3);
8
}
9

10
static int power_unlock_get(int *on, struct wmi_reply *reply)
11
{
12
    uint8_t value = 0;
13
    int err = wmi_simple(CMD_POWER_GET, &value, reply);
14
    if (err)
15
        return err;
16
    *on = value == 1;
17
    return 0;
18
}

代码不直接写 EC 寄存器，只发厂商 WMI。

这既是安全边界，也是兼容性边界：只要驱动保留 arg/call，内核升级后仍然能用。

1
git clone https://github.com/xingwangzhe/huawei-turbo-mode.git
2
cd huawei-turbo-mode
3
make
4
sudo ./core/build/huawei-perf status
5
sudo ./core/build/huawei-perf unlock get

第一次失败：电池只有 20%

第一次执行 unlock on，固件回了 status=1。

当时 AC 是插着的，但电池只有 20%。

STUB 的 RSOC < 0x15 判断直接命中，命令在写 TUBO 之前就返回了。

充到 22% 再试，成功了。

1
Power unlock : OFF / balanced (WMI status=0 value=0)
2
MMIO RAPL    : PL1=20.000 W  PL2=60.375 W
3
EC[0x15]     : 0x20  (TUBO=0)
4

5
$ sudo ./core/build/huawei-perf unlock on
6
发送 HWMI 0x10f04（power_unlock=1）...
7
回读：power_unlock=1（性能模式）
8

9
Power unlock : ON / performance (WMI status=0 value=1)
10
MMIO RAPL    : PL1=31.000 W  PL2=60.500 W
11
EC[0x15]     : 0x60  (TUBO=1)

这才是我想要的“真性能模式”：不是 EPP 标签，而是 EC 的 Turbo 位和平台功耗墙一起动了。

现在的“性能模式”到底真不真

要看两个层面。

我后来在电池 28%、充电中的状态又读了一次。

TUBO 仍然是 1，但 MMIO PL1 只有 10 W，PL2 35 W。

16 线程负载实测封装功耗 9.40 W。

这不是解锁失效，而是 EC 把“性能模式”暂时压到了低功耗档。

我也试过重启 thermald、临时把充电上限降到 26%，PL1 都没有变化。

所以 10 W 是 EC 自己的策略，不是 Linux 热守护进程。

桥接和持久化

固件命令只是第一步。

EC 的状态需要在每次开机后重新应用，桌面也不能直接读 debugfs。

所以我把项目拆成两层。

桥接的稳定接口不是 GNOME 扩展，而是 D-Bus 和 CLI。

GNOME 只是示例，不是依赖。

PPD 适配器默认开启时，Performance 映射到 Turbo on，Balanced/Power Saver 映射到 off；KDE 如果也用 PPD，同样适用。

不用 PPD 的桌面可以把 follow_ppd 设为 false，直接走 D-Bus 或 CLI。

1
gdbus call --system \
2
  --dest org.xingwangzhe.HuaweiTurbo \
3
  --object-path /org/xingwangzhe/HuaweiTurbo \
4
  --method org.xingwangzhe.HuaweiTurbo1.SetPerformance true
5

6
gdbus call --system \
7
  --dest org.xingwangzhe.HuaweiTurbo \
8
  --object-path /org/xingwangzhe/HuaweiTurbo \
9
  --method org.xingwangzhe.HuaweiTurbo1.GetStatus

持久化我做了两组验证。

huawei-turbod.service 是 enabled 的，状态写在 /var/lib/huawei-turbo/desired。

真实关机重启会由同一个 systemd 单元读取状态并应用；本机验证用的是等价的 systemctl restart，没有实际重启整机。

风扇：EC 控制，不是 Linux 驱动

性能模式热起来以后，我一度怀疑风扇驱动也有问题。

查下来结论是：这台机器没有可写的 fan/pwm 驱动，风扇由 EC 固件闭环控制。

所以能做的是只读诊断，不是手动控风。

1
sudo ./core/build/huawei-perf fan-health 20
2
sudo ./core/scripts/fan-check.sh 20

实测里，10 W 负载下风扇约 2695 RPM，CTMP 64–68°C；之前 31 W 短时负载到过 94°C，风扇约 3.6–3.9k RPM。

风扇会响应温度，只是 EC 的曲线偏保守，而且薄本在 31 W 下很快就撞到热墙。

20 秒全核 burn 的真实结果

我也做了一组 20 秒全核 AVX2 burn。

这组数据看起来像“性能模式更差”，但它不是干净的对比。

两次都冲到了 94°C，EC 在热饱和后大幅降额，测试顺序和起始温度也影响了结果。

它能说明的是散热瓶颈，不能说明 Turbo 本身让性能下降。

真要比较持续性能，需要先把机器冷却到 60°C 左右，用短爆发、固定顺序和多次取样。

踩坑清单

仓库和复现

完整源码、桥接和文档都在这里。

仓库：https://github.com/xingwangzhe/huawei-turbo-mode

README 默认英文，中文版是 README.zh-CN.md；core/、bridge/、examples/ 也各自提供英文和中文两份。

安装：

1
git clone https://github.com/xingwangzhe/huawei-turbo-mode.git
2
cd huawei-turbo-mode
3
make
4
sudo ./scripts/install.sh

安装后可以直接用 GNOME/KDE 的电源模式，也可以走通用接口。

1
huawei-turbo-ctl status
2
huawei-turbo-ctl on
3
huawei-turbo-ctl off

最后

这次折腾最大的收获不是“跑分涨了多少”，而是把“桌面性能模式”和“固件性能模式”拆开了。

GNOME 的 Performance 现在能落到 EC 的 TUBO，重启和休眠恢复后也能自己恢复；这部分是确定的。

但 EC 会根据电池、充电和温度动态改 PL1，薄本的散热也会在 31 W 下很快撞墙；这部分还没有一个通用解。

风扇则是另一条边界：它由 EC 固件控制，本机没有可写接口，能做的只有读转速、读温度和在异常时报警。

至少现在，我看到的“性能模式”不再只是一个标签。