From: Marc Zyngier <maz@kernel.org>
To: Qianhui Xu <xiaqinghuan@mail.ustc.edu.cn>
Cc: Thomas Gleixner <tglx@kernel.org>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] irqchip/gic-v3-its: Claim LPI tables inherited across kexec on DT
Date: Sat, 24 Oct 2026 12:39:03 +0100 [thread overview]
Message-ID: <87v76r8h0o.wl-maz@kernel.org> (raw)
In-Reply-To: <20261024075856.835932-1-xiaqinghuan@mail.ustc.edu.cn>
On Sat, 24 Oct 2026 08:58:56 +0100,
Qianhui Xu <xiaqinghuan@mail.ustc.edu.cn> wrote:
>
> From: Xu Qianhui <xiaqinghuan@mail.ustc.edu.cn>
>
> When a kernel is kexec'd into while LPIs are enabled, the incoming kernel
> finds GICR_CTLR.EnableLPIs set and tries to re-initialise the LPI tables
> from scratch. That requires disabling LPIs first, which is not always
> possible: on some implementations (e.g. Qualcomm SM8750) the EnableLPIs
> bit is RES1 once set, the write to clear it is ignored, and
> redist_disable_lpis() returns -EBUSY. its_cpu_init() then bails out
> early, LPIs are never reprogrammed, and every MSI command queued against
> the ITS waits for its completion timeout: measured 99 timeouts of about
> 1.25 s each, pushing /init out from 1.3 s to 126 s.
But you're missing the point. *nothing* works at all, and this has
nothing to do with the command queue. Everything is dead.
>
> The tables themselves are still intact and usable, and the driver already
> has a path for that (RDIST_FLAGS_RD_TABLES_PREALLOCATED), but it is gated
> on the tables being reserved memory. On an EFI boot the outgoing kernel
> records a persistent reservation; on a DT boot nothing does. Adding a
What makes you think that EFI and DT are incompatible? 90% of my
machines are DT based and yet boot with EFI.
> memreserve entry is not an option either: the flattened DTB handed over by
> the bootloader has no space left for a new one (-FDT_ERR_NOSPACE), and
> kexec clones that blob when the image is loaded, long before the jump.
>
> So claim the inherited tables in the incoming kernel instead: reserve the
> property table while LPIs are being probed (memblock still owns the pages,
> well before memblock_free_all()), and the per-CPU pending tables when the
> preallocated path is taken. The preallocated path is then selected
> normally and the ITS keeps working across the handoff.
No. This is way too late, and nothing guarantees that these are not
already used for other purposes by the new kernel. I'm not interested
in something that only has a statistical chance of working. Either it
works always, or it doesn't at all.
The only sane ways to do this is to either use EFI, or to configure
the LPI tables from the bootloader, reserving them at boot time by
sticking the reservation in the DT. They are then preserved along the
whole of the kexec chain. That's what sane platforms do, and this is a
long enough established practice.
Thanks,
M.
--
Jazz isn't dead. It just smells funny.
next prev parent reply other threads:[~2026-10-24 11:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-24 7:58 Qianhui Xu
2026-10-24 11:39 ` Marc Zyngier [this message]
2026-10-26 11:41 ` Qianhui Xu
2026-10-26 13:53 ` Marc Zyngier
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=87v76r8h0o.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@kernel.org \
--cc=xiaqinghuan@mail.ustc.edu.cn \
/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®