Fix GICD initialization failure in VirtCCA/Realm by preventing post-index addressing

[WEIXIAOYVYI]

Summary

This PR fixes a system hang/crash during the GIC Distributor (GICD) initialization phase in VirtCCA (Realm) confidential computing environments. By introducing core::hint::black_box to disrupt compiler optimization, we force the generation of addressing modes without Writeback, ensuring the Hardware Exception Syndrome (ISV bit) remains valid for MMIO emulation.

---

Root Cause Analysis

In confidential computing environments like VirtCCA (based on ARM Confidential Compute Architecture), guest access to GICD MMIO registers triggers a Data Abort exception, which is trapped and handled by the Hypervisor (KVM) or Realm Management Monitor (RMM).

1. Hardware Limitation (ISV = 0):
   According to the ARMv8 Architecture Reference Manual, when a Data Abort is triggered by a Load/Store instruction with Writeback semantics (e.g., Post-indexed: str w8, [x10], #4 or Pre-indexed: str w8, [x10, #4]!), the hardware sets the ISV (Instruction Specific Syndrome Valid) bit in the ESR_EL2 register to 0.

2. Confidential Computing Impact:

   • In standard virtual machines, if ISV=0, KVM attempts to "fetch and decode" the guest instruction by reading guest memory to determine the target register and value.
   • In VirtCCA (Realm), guest memory is encrypted and isolated. The RMM/KVM cannot read the guest's code segments.
   • Without a valid Syndrome (ISV=1) and without the ability to disassemble guest code, the Hypervisor cannot emulate the MMIO write, leading to a hang or an unrecoverable exception during early boot.

3. Compiler Optimization:
   In a standard for loop, the Rust compiler (LLVM) optimizes address increments by using Post-indexed addressing:
   str w8, [x10], #4 (Result: ISV=0, Emulation Fails)

---

Solution

We introduce core::hint::black_box(i) within the loop. This breaks the compiler's static analysis of the loop index i, forcing it to abandon the post-index increment optimization and fall back to Register Offset Addressing:
str w12, [x11, x9, lsl #2]

Addressing Mode Comparison:

• Optimized (Failed): str w8, [x10], #4 -> Has Writeback -> ISV=0 -> Realm emulation fails.
• Fixed (Success): str w12, [x11, x9, lsl #2] -> No Writeback -> ISV=1 -> Hypervisor reads the syndrome directly from ESR_EL2 and emulates the write successfully.

---

Changes

• Applied core::hint::black_box to the loop index in GICD register clearing/initialization logic.

for i in 0..8 {
    // Use black_box to prevent the compiler from generating instructions with 
    // Writeback (e.g., Post-index). This ensures ESR_EL2.ISV=1 when an 
    // MMIO Trap occurs in a Confidential Computing (Realm) environment.
    let idx = core::hint::black_box(i);
    self.ICPENDR[idx].set(u32::MAX);
}

Verification Results

• Environment: VirtCCA Realm (ARMv8-A with RME).
• Observation: Before this change, the kernel hung during GIC initialization with an empty syndrome (ISV=0). After the change, disassembly confirms the use of str [base, offset] and the boot process continues successfully

[ZR233]

感谢这个 PR，这里有一个潜在问题：

black_box 本质是 best-effort 的优化屏障
Rust / LLVM 没有保证它一定会阻止某种特定的 codegen（比如 post-index addressing）
不同编译器版本 / 优化级别 / backend 组合下，行为可能变化
从长期来看不太稳。
我比较推荐的方式是：不要让编译器从“数组索引”推导寻址模式，而是显式表达 MMIO 写操作

具体来说，可以考虑：
建议改为统一的寄存器访问 helper，例如：

impl Gicd {
    #[inline(always)]
    unsafe fn write32(&self, offset: usize, val: u32) {
        core::ptr::write_volatile(
            self.base.add(offset).cast::<u32>(),
            val,
        );
    }

    #[inline(always)]
    unsafe fn write_icenabler(&self, n: usize, val: u32) {
        self.write32(0x180 + n * 4, val);
    }
}

然后初始化代码变成：

for i in 0..num {
    self.write_icenabler(i, u32::MAX);
}

[WEIXIAOYVYI]

感谢建议，已经按照建议进行修改，virtcca环境测试可以正常通过初始化。不过有一点不同的是，write32函数使用了inline never。如果使用inline always，在我的编译环境下测试仍然会使用post-index addressing方式寻址。