Hi Zenghui,
I don't believe this issue can be triggered by a Linux guest. Details below.
On 7/23/20 9:56 AM, Zenghui Yu wrote:
> Hi Alexandru,
>
> I've noticed that the timer case will fail in the -stable 4.19 kernel.
> The log is as follows:
>
> FAIL: vtimer-busy-loop: no interrupt when timer is disabled
> FAIL: vtimer-busy-loop: interrupt signal no longer pending
>
> And it's because the related fix [16e604a437c8, "KVM: arm/arm64: vgic:
> Reevaluate level sensitive interrupts on enable"] hasn't been backported
> to the stable tree.
This is not an actual fix (hence no "Fixes" tag), this is more like an improvement
of the behaviour of the GIC. Like the patch description says, this can happen even
on hardware if the GIC hasn't sampled the device interrupt state (or the device
itself hasn't updated it) before the CPU re-enables the interrupt.
>
> Just out of curiosity, _without_ this fix, had you actually seen the
> guest getting into trouble due to an un-retired level-sensitive
> interrupt and your patch fixed it? Or this was found by code inspection?
This issue was found when running kvm-unit-tests on the model.
>
> Take the exact vtimer case as an example, is it possible that the Linux
> guest would disable the vtimer (the input interrupt line is driven to 0
> but the old KVM doesn't take this into account) and potentially hit this
> issue? I'm not familiar with it.
To trigger this, a guest has to do the following steps:
1. Disable the timer interrupt at the Redistributor level.
2. Trigger the timer interrupt in the timer.
3. Disable the timer entirely (CNT{P,V}_CTL_EL0.ENABLE = 0), which also disables
the timer interrupt.
4. Enable the timer interrupt at the Redistributor level.
I believe there are two reasons why this will never happen for a Linux guest:
- This isn't the way Linux handles interrupts. Furthermore, I don't believe Linux
will ever disable a specific interrupt at the irqchip level.
- The timer IRQ handler checks the ISTATUS flag in the timer control register
before handling the interrupt. The flag is unset if the timer is disabled.
I hope my explanation made sense, please chime in if I missed something or you
want more details.
Thanks,
Alex
>
> One of our internal tree is based on the stable 4.19 and I'm sure this
> fix is not included. But I havn't received any bad reports from our
> users yet. But if there's any potential problem without this fix, it'd
> good to get it properly backported. I can help to send a backport
> request if so.
>
>
> Thanks,
> Zenghui
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
