RE: Why my interrupt is not connected? qemu_irq_is_connected( ) returns false.

[Chan Kim]

Hello all,

I have assigned my device's irq at SPI 176 (= INTID 208 ).
And I found in the qemu's gicv3_cpuif_update function below, the 
icc_hppi_can_preempt(cs) returns false because cs->hppi.prio == 0xff.
I understand this means the interrupt I made is of priority 0xff (the lowest?).
How can I make my interrupt have higher priority other that 0xff? Should I do 
it in qemu device tree?(or ACPI table?)
Or should I do it in linux driver (when calling request_irq function). I'm lost 
here.
Any comment or advice will be really appreciated. (this test is using 
qemu-5.1.0)
Thank you! 

Chan Kim

static bool icc_no_enabled_hppi(GICv3CPUState *cs)
{
    /* Return true if there is no pending interrupt, or the
     * highest priority pending interrupt is in a group which has been
     * disabled at the CPU interface by the ICC_IGRPEN* register enable bits.
     */
    return cs->hppi.prio == 0xff || (cs->icc_igrpen[cs->hppi.grp] == 0);
}

void gicv3_cpuif_update(GICv3CPUState *cs)
{
    /* Tell the CPU about its highest priority pending interrupt */
    int irqlevel = 0;
    int fiqlevel = 0;
    ARMCPU *cpu = ARM_CPU(cs->cpu);
    CPUARMState *env = &cpu->env;

    g_assert(qemu_mutex_iothread_locked());

    trace_gicv3_cpuif_update(gicv3_redist_affid(cs), cs->hppi.irq,
                             cs->hppi.grp, cs->hppi.prio);

    if (cs->hppi.grp == GICV3_G1 && !arm_feature(env, ARM_FEATURE_EL3)) {
        /* If a Security-enabled GIC sends a G1S interrupt to a
         * Security-disabled CPU, we must treat it as if it were G0.
         */
        cs->hppi.grp = GICV3_G0;
    }

    if (icc_hppi_can_preempt(cs)) {
        /* We have an interrupt: should we signal it as IRQ or FIQ?
         * This is described in the GICv3 spec section 4.6.2.
         */
        bool isfiq;

        switch (cs->hppi.grp) {
        case GICV3_G0:
            isfiq = true;
            break;
        case GICV3_G1:
            isfiq = (!arm_is_secure(env) ||
                     (arm_current_el(env) == 3 && arm_el_is_aa64(env, 3)));

> -----Original Message-----
> From: Chan Kim <ckim@etri.re.kr>
> Sent: Saturday, April 2, 2022 12:44 AM
> To: 'Peter Maydell' <peter.maydell@linaro.org>
> Cc: 'qemu-discuss' <qemu-discuss@nongnu.org>
> Subject: RE: Why my interrupt is not connected? qemu_irq_is_connected( )
> returns false.
> 
> Hello Peter Maydell, and all,
> 
> > > If the device does try to raise its interrupt, then either you've
> > > wired the interrupt wrongly or else perhaps the guest never unmasked
> > > the interrupt in the GIC. You can singlestep into the
> > > qemu_raise_irq() function to see where it takes you.
> > >
> I've set breakpoint at qemu_irq_raise() just before qemu does
> qemu_set_irq(s->irq, 1) following a specific condition of register write.
> But after the mmio write is finished, it crashes before reaching
> qemu_irq_raise(). The log looks like this.
> 
> start of main!
> interupt test!
> [  511.538838] addr axpu_es = ffff000068300000, I got 524288 bytes writing
> 1 at dev reg. 0x1604
> app: calling ioctl with reqcmd = 1074291031 [  511.547039] driver : ioctl
> CallWrite called!
> [  584.800415] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
> [  584.805766] rcu:     0-...!: (2 ticks this GP)
> idle=23a/1/0x4000000000000002 softirq=50739/50739 fqs=0
> [  584.808996] rcu:     1-...!: (1 GPs behind)
> idle=3ce/1/0x4000000000000000 softirq=55180/55182 fqs=0
> [  584.812235]  (detected by 2, t=18317 jiffies, g=112541, q=0)
> [  584.819408] Call trace:
> [  584.823551]  __switch_to+0x134/0x190
> [  584.824383]  __schedule+0x31c/0x7e0
> [  584.825057]  schedule+0x40/0xb8
> [  584.825615]  do_nanosleep+0x98/0x188
> [  584.826448]  hrtimer_nanosleep+0xcc/0x198 [  584.827386]
> common_nsleep+0x3c/0x50 [  584.828356]
> __arm64_sys_clock_nanosleep+0xcc/0x148
> [  584.829230]  el0_svc_common.constprop.0+0xe4/0x1f0
> [  584.829972]  el0_svc_handler+0x38/0xa8 [  584.830589]
> el0_svc+0x10/0x2c8 [  584.832102] Call trace:
> [  584.832595]  __switch_to+0x134/0x190
> [  584.834134]  0xffff000075307480
> did you see it?
> [  584.885964] Unable to handle kernel NULL pointer dereference at virtual
> address 0000000000000000 [  584.886735] Mem abort info:
> 
> If you have any idea where I should check, please tell me.
> Thank you.
> 
> Chan Kim