Re: [PATCH 25/41] hw/intc/arm_gicv3_cpuif: Support vLPIs

[Richard Henderson]

On 4/8/22 07:15, Peter Maydell wrote:
> The CPU interface changes to support vLPIs are fairly minor:
> in the parts of the code that currently look at the list registers
> to determine the highest priority pending virtual interrupt, we
> must also look at the highest priority pending vLPI. To do this
> we change hppvi_index() to check the vLPI and return a special-case
> value if that is the right virtual interrupt to take. The callsites
> (which handle HPPIR and IAR registers and the "raise vIRQ and vFIQ
> lines" code) then have to handle this special-case value.
>
> This commit includes two interfaces with the as-yet-unwritten
> redistributor code:
>   * the new GICv3CPUState::hppvlpi will be set by the redistributor
>     (in the same way as the existing hpplpi does for physical LPIs)
>   * when the CPU interface acknowledges a vLPI it needs to set it
>     to non-pending; the new gicv3_redist_vlpi_pending() function
>     (which matches the existing gicv3_redist_lpi_pending() used
>     for physical LPIs) is a stub that will be filled in later
>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>


> @@ -2632,6 +2735,12 @@ static void gicv3_cpuif_el_change_hook(ARMCPU *cpu, void 
> *opaque)
>       GICv3CPUState *cs = opaque;
>   
>       gicv3_cpuif_update(cs);
> +    /*
> +     * Because vLPIs are only pending in NonSecure state,
> +     * an EL change can change the VIRQ/VFIQ status (but
> +     * cannot affect the maintenance interrupt state)
> +     */
> +    gicv3_cpuif_virt_irq_fiq_update(cs);

I'm a little bit surprised this is here, and not in arm_cpu_exec_interrupt (or a 
subroutine).  Is this because if a virq has highest priority, we have to find the highest 
prio physical interrupt?


r~