On Tue, Aug 30, 2016 at 12:07:36PM +0100, Marc Zyngier wrote:

+Mark
On 30/08/16 11:35, majun (F) wrote:

quoted

? 2016/8/30 16:50, Marc Zyngier ??:

quoted

On 30/08/16 05:17, MaJun wrote:

quoted

From: Ma Jun <redacted>

During system booting, if the interrupt which has no action registered
is triggered, it would cause system panic when try to access the
action member.

And why would that interrupt be enabled? If you enable a PPI before
registering a handler, you're doing something wrong.

Actually,the problem described above happened during the capture
kernel booting.

In my system, sometimes there is a pending physical timer
interrupt(30) when the first kernel panic and the status is kept
until the capture kernel booting.

And that's perfectly fine. The interrupt can be pending forever, as it
shouldn't get enabled.

quoted

So, this interrupt will be handled during capture kernel booting.

Why? Who enables it?

quoted

Becasue we use virt timer interrupt but not physical timer interrupt
in capture kernel, the interrupt 30 has no action handler.

Again: who enables this interrupt? Whichever driver enables it should be
fixed.

I'm also at a loss.

In this case, arch_timer_uses_ppi must be VIRT_PPI. So in
arch_timer_register(), we'll only request_percpu_irq the virt PPI.
arch_timer_has_nonsecure_ppi() will be false, given arch_timer_uses_ppi
is VIRT_PPI, so in arch_timer_starting_cpu() we'll only
enable_percpu_irq() the virt PPI.

We don't fiddle with arch_timer_uses_ppi after calling
arch_timer_register(). So I can't see how we could enable another IRQ in
this case.

Looking at the driver in virt/kvm/arm/arch_timer.c, we only enable what
we've succesfully requested, so it doesnt' seem like there's an issue
there.

From a quick look at teh GIC driver, it looks like we reset PPIs

correctly, so it doesn't look like we have a "latent enable".

Thanks,
Mark.