Hello, Marc.
On 2/4/25 13:00, Marc Zyngier wrote:
> When updating the interrupt state for an emulated timer, we return
> early and skip the setup of a soft timer that runs in parallel
> with the guest.
>
> While this is OK if we have set the interrupt pending, it is pretty
> wrong if the guest moved CVAL into the future. In that case,
> no timer is armed and the guest can wait for a very long time
> (it will take a full put/load cycle for the situation to resolve).
>
> This is specially visible with EDK2 running at EL2, but still
> using the EL1 virtual timer, which in that case is fully emulated.
> Any key-press takes ages to be captured, as there is no UART
> interrupt and EDK2 relies on polling from a timer...
>
> The fix is simply to drop the early return. If the timer interrupt
> is pending, we will still return early, and otherwise arm the soft
> timer.
>
> Fixes: 4d74ecfa6458b ("KVM: arm64: Don't arm a hrtimer for an already pending timer")
> Signed-off-by: Marc Zyngier <maz@xxxxxxxxxx>
> Cc: stable@xxxxxxxxxxxxxxx
Tested-by: Dmytro Terletskyi <dmytro_terletskyi@xxxxxxxx>
> ---
> arch/arm64/kvm/arch_timer.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/arch/arm64/kvm/arch_timer.c b/arch/arm64/kvm/arch_timer.c
> index d3d243366536c..035e43f5d4f9a 100644
> --- a/arch/arm64/kvm/arch_timer.c
> +++ b/arch/arm64/kvm/arch_timer.c
> @@ -471,10 +471,8 @@ static void timer_emulate(struct arch_timer_context *ctx)
>
> trace_kvm_timer_emulate(ctx, should_fire);
>
> - if (should_fire != ctx->irq.level) {
> + if (should_fire != ctx->irq.level)
> kvm_timer_update_irq(ctx->vcpu, should_fire, ctx);
> - return;
> - }
>
> kvm_timer_update_status(ctx, should_fire);
>
