> On 27. Jan 2026, at 12:08, Peter Maydell <[email protected]> wrote: > > On Wed, 21 Jan 2026 at 13:41, Mohamed Mediouni <[email protected]> > wrote: >> >> Signed-off-by: Mohamed Mediouni <[email protected]> >> --- >> MAINTAINERS | 1 + >> hw/arm/virt.c | 10 ++ >> hw/intc/arm_gicv3_common.c | 3 + >> hw/intc/arm_gicv3_whpx.c | 238 +++++++++++++++++++++++++++++ >> hw/intc/meson.build | 1 + >> include/hw/intc/arm_gicv3_common.h | 3 + >> 6 files changed, 256 insertions(+) >> create mode 100644 hw/intc/arm_gicv3_whpx.c > >> +static void whpx_gicv3_icc_reset(CPUARMState *env, const ARMCPRegInfo *ri) >> +{ >> + GICv3State *s; >> + GICv3CPUState *c; >> + >> + c = env->gicv3state; >> + s = c->gic; >> + >> + c->icc_pmr_el1 = 0; >> + /* >> + * Architecturally the reset value of the ICC_BPR registers >> + * is UNKNOWN. We set them all to 0 here; when the kernel >> + * uses these values to program the ICH_VMCR_EL2 fields that >> + * determine the guest-visible ICC_BPR register values, the >> + * hardware's "writing a value less than the minimum sets >> + * the field to the minimum value" behaviour will result in >> + * them effectively resetting to the correct minimum value >> + * for the host GIC. >> + */ >> + c->icc_bpr[GICV3_G0] = 0; >> + c->icc_bpr[GICV3_G1] = 0; >> + c->icc_bpr[GICV3_G1NS] = 0; >> + >> + c->icc_sre_el1 = 0x7; >> + memset(c->icc_apr, 0, sizeof(c->icc_apr)); >> + memset(c->icc_igrpen, 0, sizeof(c->icc_igrpen)); >> + >> + if (s->migration_blocker) { >> + return; >> + } > > Looking a bit more closely at this, this is odd. Why the early > return? This looks like it was copied from the KVM GICv3 > from prior to commit 59ad421d6. But in the KVM code before Hello,
Indeed it was, will remove this from the HVF nested virt series too… And update to use s->migration_blocker for "whpx: arm64: gicv3: add migration blocker” (which I’ll squash into “whpx: interrupt controller support”) Thank you, > that commit, the reason for the early return is to avoid > the "read the ICC_CTLR value from KVM" call that won't work > (the migration blocker is for the "no KVM API to read/write > GIC registers" case). And in the KVM code after that commit, > we restructured the reset to not read the register in the > reset function, so we don't need to test s->migration_blocker > at all then. > > Probably you want to follow the pattern the newer KVM code > uses, but either way, this early return doesn't make much > sense for this whpx code as it stands, especially as the > whpx code isn't currently setting s->migration_blocker... > >> + >> + c->icc_ctlr_el1[GICV3_S] = c->icc_ctlr_el1[GICV3_NS]; >> +} > > thanks > -- PMM >
