On 2015/12/1 23:41, Marc Zyngier wrote:
The reason is that when guest clear the overflow register, it will trap
>to kvm and call kvm_pmu_sync_hwstate() as you see above. At this moment,
>the overflow register is still overflowed(that is some bit is still 1).
>So We need to use some flag to mark we already inject this interrupt.
>And if during guest handling the overflow, there is a new overflow
>happening, the pmu->irq_pending will be set ture by
>kvm_pmu_perf_overflow(), then it needs to inject this new interrupt, right?
I don't think so. This is a level interrupt, so the level should stay
high as long as the guest hasn't cleared all possible sources for that
interrupt.
For your example, the guest writes to PMOVSCLR to clear the overflow
caused by a given counter. If the status is now 0, the interrupt line
drops. If the status is still non zero, the line stays high. And I
believe that writing a 1 to PMOVSSET would actually trigger an
interrupt, or keep it high if it has already high.
Right, writing 1 to PMOVSSET will trigger an interrupt.
In essence, do not try to maintain side state. I've been bitten.
So on VM entry, it check if PMOVSSET is zero. If not, call
kvm_vgic_inject_irq to set the level high. If so, set the level low.
On VM exit, it seems there is nothing to do.
--
Shannon
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
