Hi James, On Wed, Sep 30, 2026 at 04:25:36PM +0100, James Clark wrote: > Looks good to me, everything seems to be working now: > > Tested-by: James Clark <[email protected]>
Thank you for testing and for all the reviews! > There are still a few Sashiko comments though, and one critical one about > racing with pseudo-NMI PMU interrupts that looked reasonable. I tried to > test it and reproduce an actual issue but couldn't, so maybe it's bogus. The "Critical" Sashiko comment on Patch 19/22 (claiming that clearing hardware PMOVSSET_EL0 loses overflow bits because the guest has direct untrapped access to PMOVSSET_EL0) is a false positive: Patch 09/22 sets HDFGRTR_EL2_PMOVS and HDFGWTR_EL2_PMOVS (and without FGT, MDCR_EL2.TPM is set), so guest accesses to PMOVSSET_EL0 and PMOVSCLR_EL0 always trap to pmu_reg_read() / pmu_reg_write(). The pseudo-NMI race comments on Patch 11/22 and Patch 19/22 are theoretically possible in a narrow 2-instruction RMW window because local_irq_save() does not mask GICv3 pseudo-NMIs, which explains why it wasn't reproducible in practice. In v10 I will make the PMOVSSET_EL0 shadow updates and vcpu->arch.mdcr_el2 assignment atomic, and address the other valid Sashiko findings. Thanks, Colton
