From: Nam Cao <namcao@linutronix.de>
To: "Yan Zheng(严政)" <zhengyan@asrmicro.com>
Cc: "tglx@linutronix.de" <tglx@linutronix.de>,
"maz@kernel.org" <maz@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"paul.walmsley@sifive.com" <paul.walmsley@sifive.com>,
"samuel.holland@sifive.com" <samuel.holland@sifive.com>,
"linux-riscv@lists.infradead.org"
<linux-riscv@lists.infradead.org>,
"Zhou Qiao(周侨)" <qiaozhou@asrmicro.com>
Subject: Re: 答复: [PATCH] irqchip/sifive-plic: ensure interrupt is enable before EOI
Date: Mon, 24 Jun 2024 13:56:29 +0200 [thread overview]
Message-ID: <20240624115629.6vSA6hQE@linutronix.de> (raw)
In-Reply-To: <69174a28eff44ad1b069887aa514971e@exch03.asrmicro.com>
On Mon, Jun 24, 2024 at 11:14:47AM +0000, Yan Zheng(严政) wrote:
> > I have no knowledge about affinity stuff, so I don't really understand this
> > patch. But there is another idea regarding this "ignored EOI" problem:
> > always "complete" the interrupt while enabling. That would move this extra
> > complication out of the hot path, and also looks simpler in my opinion.
> >
> > Something like the patch below. Would this solve this "affinity problem"
> > too?
> >
> No, I'm afraid the following patch can't solve this corner case. I thought it's because the core
> Who executes plic_irq_enable is not the core who missing a write claim.
> So if we want to do it in enable it might be something like follows :
> static void plic_toggle(struct plic_handler *handler, int hwirq, int enable)
> {
> raw_spin_lock(&handler->enable_lock);
> - __plic_toggle(handler->enable_base, hwirq, enable);
> + if (enable) {
> + writel(hwirq, handler->hart_base + CONTEXT_CLAIM);
> + __plic_toggle(handler->enable_base, hwirq, enable);
> + }
> raw_spin_unlock(&handler->enable_lock);
> }
Again, I don't know anything about interrupt affinity thingy, so I may be
saying something dumb here:
I think this wouldn't work either. In plic_set_affinity(), I see the
interrupt is disabled, then enabled again. With your new proposed solution,
the interrupt would also be marked completed within plic_set_affinity().
So, the interrupt may be asserted again, earlier than it is supposed to (it
is not supposed to be asserted again until plic_irq_eoi() is called). It's
rare, but I think it's a possible race.
I don't have a better idea, at least for now. So probably we should stick
to your current solution.
>
> But there is a little difference:
> a. check whether it's enabled when do write claim
> b. write claim anyway before enable
>
> sounds like a. is better?
>
> And I'd like to illustrate more about this case:
> For example, broadcast tick is working, cpu0 is about to response, cpu1 is the next
> 1. cpu0 response the timer irq, read the claim REG, and do timer isr event,
> 2. during the timer isr it will set next event
> tick_broadcast_set_event -> irq_set_affinity-> xxx-> plic_set_affinity -> plic_irq_enable
> 3. in plic_set_affinity disable cpu0's IE and enable cpu1'IE
> 4. cpu0 do the write claim to finish this irq, while cpu0's IE is disabled , left an active state in plic
This is useful information, you may want to add it in your commit message.
>
> Best regards,
> zhengyan
>
> > diff --git a/drivers/irqchip/irq-sifive-plic.c b/drivers/irqchip/irq-sifive-plic.c
> > index 0a233e9d9607..63f2111ced4a 100644
> > --- a/drivers/irqchip/irq-sifive-plic.c
> > +++ b/drivers/irqchip/irq-sifive-plic.c
> > @@ -122,7 +122,15 @@ static inline void plic_irq_toggle(const struct
> > cpumask *mask,
> >
> > static void plic_irq_enable(struct irq_data *d) {
> > + struct plic_priv *priv = irq_data_get_irq_chip_data(d);
> struct plic_handler *handler = this_cpu_ptr(&plic_handlers);
> missing a definition? If adds like this will cause a problem.
Sorry, should have mentioned I didn't build this patch. Just wanted to
throw out ideas..
> > +
> > + writel(0, priv->regs + PRIORITY_BASE + d->hwirq * PRIORITY_PER_ID);
> > +
> > + writel(d->hwirq, handler->hart_base + CONTEXT_CLAIM);
> > +
> > plic_irq_toggle(irq_data_get_effective_affinity_mask(d), d, 1);
> > +
> > + writel(1, priv->regs + PRIORITY_BASE + d->hwirq * PRIORITY_PER_ID);
> > }
> >
> > static void plic_irq_disable(struct irq_data *d) @@ -148,13 +156,7 @@ static
> > void plic_irq_eoi(struct irq_data *d) {
> > struct plic_handler *handler = this_cpu_ptr(&plic_handlers);
> >
> > - if (unlikely(irqd_irq_disabled(d))) {
> > - plic_toggle(handler, d->hwirq, 1);
> > - writel(d->hwirq, handler->hart_base + CONTEXT_CLAIM);
> > - plic_toggle(handler, d->hwirq, 0);
> > - } else {
> > - writel(d->hwirq, handler->hart_base + CONTEXT_CLAIM);
> > - }
> > + writel(d->hwirq, handler->hart_base + CONTEXT_CLAIM);
> > }
> >
> > #ifdef CONFIG_SMP
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2024-06-24 11:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-24 8:53 [PATCH] irqchip/sifive-plic: ensure interrupt is enable before EOI zhengyan
2024-06-24 9:35 ` Nam Cao
2024-06-24 11:14 ` 答复: " Yan Zheng(严政)
2024-06-24 11:35 ` [PATCH v2] " zhengyan
2024-07-07 18:27 ` Nam Cao
2024-07-22 7:36 ` 答复: " Yan Zheng(严政)
2024-06-24 11:56 ` Nam Cao [this message]
2024-06-24 12:43 ` 答复: 答复: [PATCH] " Yan Zheng(严政)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240624115629.6vSA6hQE@linutronix.de \
--to=namcao@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=maz@kernel.org \
--cc=paul.walmsley@sifive.com \
--cc=qiaozhou@asrmicro.com \
--cc=samuel.holland@sifive.com \
--cc=tglx@linutronix.de \
--cc=zhengyan@asrmicro.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox