From: Yipeng Zou <zouyipeng@huawei.com>
To: Marc Zyngier <maz@kernel.org>
Cc: <tglx@linutronix.de>, <samuel@sholland.org>,
<oleksandr_tyshchenko@epam.com>, <andy.shevchenko@gmail.com>,
<apatel@ventanamicro.com>, <lvjianmin@loongson.cn>,
<linux-kernel@vger.kernel.org>, <chris.zjh@huawei.com>,
<liaochang1@huawei.com>, James Gowans <jgowans@amazon.com>
Subject: Re: [RFC PATCH] genirq: introduce handle_fasteoi_edge_irq flow handler
Date: Sat, 15 Apr 2023 09:38:28 +0800 [thread overview]
Message-ID: <847e4b85-f081-e214-dc24-75a7b3c2c885@huawei.com> (raw)
In-Reply-To: <86edomln7k.wl-maz@kernel.org>
在 2023/4/14 19:25, Marc Zyngier 写道:
> On Fri, 10 Mar 2023 10:14:17 +0000,
> Yipeng Zou <zouyipeng@huawei.com> wrote:
>> Recently, We have a LPI migration issue on the ARM SMP platform.
>>
>> For example, NIC device generates MSI and sends LPI to CPU0 via ITS,
>> meanwhile irqbalance running on CPU1 set irq affinity of NIC to CPU1,
>> the next interrupt will be sent to CPU2, due to the state of irq is
>> still in progress, kernel does not end up performing irq handler on
>> CPU2, which results in some userland service timeouts, the sequence
>> of events is shown as follows:
>>
>> NIC CPU0 CPU1
>>
>> Generate IRQ#1 READ_IAR
>> Lock irq_desc
>> Set IRQD_IN_PROGRESS
>> Unlock irq_desc
>> Lock irq_desc
>> Change LPI Affinity
>> Unlock irq_desc
>> Call irq_handler
>> Generate IRQ#2
>> READ_IAR
>> Lock irq_desc
>> Check IRQD_IN_PROGRESS
>> Unlock irq_desc
>> Return from interrupt#2
>> Lock irq_desc
>> Clear IRQD_IN_PROGRESS
>> Unlock irq_desc
>> return from interrupt#1
>>
>> For this scenario, The IRQ#2 will be lost. This does cause some exceptions.
> Please see my reply to James at [1]. I'd appreciate if you could give
> that patch a go, which I expect to be a better avenue to fix what is
> effectively a GIC architecture defect.
>
> Thanks,
>
> M.
>
> [1] https://lore.kernel.org/all/86pm89kyyt.wl-maz@kernel.org/
Hi Marc:
Thanks for your time about this issue.
I have seen your latest patch, and I am preparing the environment
for testing, I will sent the testing status of this patch later.
--
Regards,
Yipeng Zou
prev parent reply other threads:[~2023-04-15 1:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-10 10:14 Yipeng Zou
2023-04-14 11:25 ` Marc Zyngier
2023-04-15 1:38 ` Yipeng Zou [this message]
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=847e4b85-f081-e214-dc24-75a7b3c2c885@huawei.com \
--to=zouyipeng@huawei.com \
--cc=andy.shevchenko@gmail.com \
--cc=apatel@ventanamicro.com \
--cc=chris.zjh@huawei.com \
--cc=jgowans@amazon.com \
--cc=liaochang1@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lvjianmin@loongson.cn \
--cc=maz@kernel.org \
--cc=oleksandr_tyshchenko@epam.com \
--cc=samuel@sholland.org \
--cc=tglx@linutronix.de \
/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
all inboxes | Powered by JetHome®