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
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

Reply via email to