fix(aarch64): restore RK3588 guest cpufreq and SCMI support

[bullhh]

背景

RK3588 Linux 客户机更新到最新代码后出现以下问题：

• CPU 调频信息不完整，客户机运行频率偏低，用户态性能下降；
• 恢复部分 CPU 设备树属性后，Linux 无法正确识别 PSCI/SMCCC 能力；
• SCMI 通信和 RKNPU 初始化可能失败，导致 /dev/dri 中没有可用的 NPU 设备。

问题由两部分共同造成：

1. AxVM 在生成客户机设备树时，无条件删除了 CPU 节点中的
   operating-points-v2、cpu-supply、#cooling-cells 和
   dynamic-power-coefficient。

   这些过滤原本用于规避 ROC-RK3568 平台问题，但同时影响了 RK3588，
   使 Linux 客户机无法获得完整的 CPU OPP 和供电信息。

2. SMC 客户机调用 PSCI_VERSION 时得到的是 AxVisor 的虚拟 PSCI 版本，
   Linux 因此无法继续确认物理固件支持的 SMCCC 版本，进而影响 SCMI
   固件通信路径。

修改内容

• 仅对以下 ROC-RK3568 平台过滤 CPU 电源管理属性：
  • rockchip,rk3568-firefly-roc-pc
  • rockchip,rk3568-firefly-roc-pc-se
• RK3588 客户机保留 CPU OPP、供电、散热和功耗属性。
• 保留原有 RISC-V cache block 属性过滤逻辑。
• SMC 客户机的 PSCI_VERSION 调用转发给物理 ATF。
• CPU_ON、CPU_OFF、SYSTEM_OFF 等虚拟机生命周期调用仍由 AxVisor
  虚拟化处理，不改变现有 vCPU 管理逻辑。
• PSCI_FEATURES 正确报告对 ARM_SMCCC_VERSION 查询的支持。
• 增加单元测试，分别验证：
  • ROC-RK3568 继续删除相关 CPU 属性；
  • RK3588 保留相关 CPU 属性；
  • SMCCC version feature 查询返回成功。

测试结果

本地测试：

• cargo fmt --all
• cargo test -p axvm --features host-test
  • 252 passed，0 failed
• cargo xtask clippy --package axvm --package arm_vcpu
  • 7 项检查全部通过
• git diff --check

OrangePi 5 Plus RK3588 实机测试：

• AxVisor 可以正常启动 Linux SMP1 客户机；
• Linux 正常进入用户态；
• PSCI：PSCIv1.1
• SMC Calling Convention：v1.5
• SCMI：Protocol v2.0
• CPU0 调频驱动：cpufreq-dt
• CPU0 当前/最高频率：1.8 GHz
• NPU 当前/最高频率：1.0 GHz
• NPU governor：rknpu_ondemand
• RKNPU 驱动初始化成功；
• /dev/dri/card* 和 /dev/dri/renderD* 正常生成；
• 针对性板端检查通过。

[mai-team-app]

本 PR 针对 RK3588 Linux 客户机恢复 CPU OPP/供电相关 DT 属性，并将 SMC 的 PSCI_VERSION 转发给 ATF、补充 SMCCC discovery。PSCI/SMCCC 修改与 Linux 的 discovery 路径一致；但 DTB 过滤与资源所有权边界存在一个阻塞问题，当前不能合入。

影响范围：改动不是隔离的字符串调整，而是改变 guest DTB 中 CPU 到 OPP、regulator、clock、thermal 的 phandle 合约。当前 FDT 生成逻辑只保留 CPU、GIC 和显式直通节点；OrangePi Linux 配置为 passthrough = []。因此恢复的 host-resource 引用没有对应 guest 节点，且不能简单复制 host 控制面来规避该问题。

验证：已核对当前头 602dc2a3ae1ca2519e430cfa3a26b0c563b906b2、差异锚点与 git diff --check。组织 CI 当前头的格式化、clippy 和多项 AxVisor 测试已成功；汇总中仍有 1 个 failure、7 个 cancelled 和路径/矩阵导致的 skipped，本次请求修改的直接依据为下方可静态复现的 guest DTB 错误，而不是将该未展开的 CI failure 归因于本 PR。按照已有成功 CI，未重复全量本地测试。

既有 review 与 PR 评论均为空。重复/重叠分析：#1658 是依赖已合入 cpufreq 的 Starry benchmark；#1716、#1909 仅共享 axvm 表面，未实现相同功能。feature-development 适用：这是共享平台/硬件能力扩展，属于中等风险；未涉及 StarryOS syscall ABI。

待解决问题：请建立可验证的 guest-owned 或 mediated OPP/clock/regulator/thermal 依赖图及资源所有权，或继续过滤宿主资源 phandle；并以实际 RK3588 DTB 的生成回归测试证明不存在悬空 phandle，且 cpufreq 路径可用。

审查清单已完成；除以下阻塞项外未发现其他待处理问题。

Powered by gpt-5.6-terra

[mai-team-app]

阻塞：这里恢复了 CPU 节点到宿主 OPP/供电/散热资源的 phandle，但 create_guest_fdt() 仍只保留 CPU、GIC 和显式 passthrough 节点。OrangePi 的 linux-smp1.toml 又是 passthrough = []，所以 operating-points-v2、cpu-supply 等目标节点不会进入 guest DTB，生成的是悬空引用；Linux 的 cpufreq/thermal 解析会失败或退化。更重要的是，简单把 OPP/regulator/clock 节点也复制过去会把仍由 host 所有的控制面暴露给 guest。请保持这些 host-resource phandle 的过滤，或者先实现有明确所有权边界的虚拟/受控依赖图，并用实际 RK3588 DTB 的生成测试验证无悬空 phandle 与 cpufreq 可用。