From: Marc Zyngier <maz@kernel.org>
To: Qianhui Xu <xiaqinghuan@mail.ustc.edu.cn>
Cc: Thomas Gleixner <tglx@kernel.org>,
linux-arm-msm@vger.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: Mon, 26 Oct 2026 13:53:06 +0000 [thread overview]
Message-ID: <86y0bky3el.wl-maz@kernel.org> (raw)
In-Reply-To: <179301488974.13269.12823732532276833194@mail.ustc.edu.cn>
On Mon, 26 Oct 2026 11:41:29 +0000,
Qianhui Xu <xiaqinghuan@mail.ustc.edu.cn> wrote:
>
> Hi Marc,
>
> Understood on all three points, and the series is withdrawn -- I am not
> going to resend it in any form.
Thanks.
>
> Just so it is on record that I got the reasoning right this time:
>
> - Inheriting LPI tables is not something the incoming kernel can decide to
> fix up after the fact. By the time it runs, it can no longer tell which
> of those pages are still the LPI tables and which are ordinary memory it
> has already handed out, so any "claim" is a race with a statistical
> chance of being correct. That is why it is either configured before the
> handoff, or not at all.
Indeed. By the time it gets to the GIC driver, the memory used by the
LPI tables could be allocated to other things (page tables, for
example), and memory corruption is very likely.
> - EFI and DT are not alternatives: the reservation has to exist in
> whichever description the next kernel is given, EFI memory map or DT
> reserved-memory, and EFI booting a DT machine is the normal case.
Correct. The EFI reservation is done through Linux-specific EFI tables
that are available irrespective of the platform description method. DT
reserved memory is also usable, but obviously has to be set from the
initial boot point.
> - Therefore the LPI tables have to be programmed and reserved by the
> firmware/bootloader at boot and stay reserved across the whole kexec
> chain.
>
> In our case the "bootloader" for a kexec chain is the kexec loader itself,
> so the work moves there: add the reservation to the FDT that is handed over
> (e.g. grow the blob when there is no space for the memreserve) and have the
> loader program the tables, instead of the kernel trying to reclaim them.
> Anything that needs LPIs will simply use a full reboot until that exists.
If you're using Linux as your first stage bootloader (like petitboot),
then the DT you produce has to have the reservation. If you're using
u-boot without EFI as the bootloader, you can perform the reservation
there.
M.
--
Without deviation from the norm, progress is not possible.
prev parent reply other threads:[~2026-10-26 13:53 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
2026-10-26 11:41 ` Qianhui Xu
2026-10-26 13:53 ` Marc Zyngier [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=86y0bky3el.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.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®