All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Troy Mitchell <troy.mitchell@linux.dev>,
	Troy Mitchell <troy.mitchell@linux.dev>,
	Paul Walmsley <pjw@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>
Cc: linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org
Subject: Re: [PATCH] irqchip/sifive-plic: use hartid as context_id in OF to fix AMP conflicts
Date: Tue, 21 Oct 2025 20:23:58 +0200	[thread overview]
Message-ID: <87y0p4xge9.ffs@tglx> (raw)
In-Reply-To: <aPbeb1SEZr7CG2eN@kernel.org>

On Tue, Oct 21 2025 at 09:14, Troy Mitchell wrote:
> On Mon, Oct 20, 2025 at 07:44:55PM +0200, Thomas Gleixner wrote:
>> On Mon, Oct 20 2025 at 11:49, Troy Mitchell wrote:
>> > In asymmetric multi-processing (AMP) scenarios, the original PLIC
>> > driver used the context loop index 'i' as context_id for OF (device
>> 
>> Which original driver and when did it stop to use the context loop index?
>> 
>> > tree) platforms. This caused multiple contexts from different harts
>> > (e.g., core0 and core4) to share the same enable_base, leading to
>> > conflicts when initializing the PLIC.
>> 
>> When did it stop to cause the issues? And if the issues have been
>> already resolved, what is this patch about?
> The issue still exists in the current driver.
> The PLIC driver for OF-based platforms assigns context_id = i inside
> the context loop, which assumes that all harts are numbered contiguously
> starting from 0.
>
> In AMP systems (e.g., when Linux boots from hart4 while hart0 runs another OS),
> this assumption breaks — multiple contexts from different clusters share the same
> enable_base(e.g., core4's enable_base = core0's enable_base), causing conflicts.
>
> This patch fixes the problem by assigning context_id based on the actual hartid,
> ensuring that each hart context maps to a unique enable region,
> while preserving behavior on SMP and UP systems.
>
> Does it make sense? I'll update my commit message in the next version.

Yes. Though this still applies:
 
>> # git grep 'This patch' Documentation/process/

Thanks,

        tglx

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: Thomas Gleixner <tglx@linutronix.de>
To: Troy Mitchell <troy.mitchell@linux.dev>,
	Troy Mitchell <troy.mitchell@linux.dev>,
	Paul Walmsley <pjw@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>
Cc: linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org
Subject: Re: [PATCH] irqchip/sifive-plic: use hartid as context_id in OF to fix AMP conflicts
Date: Tue, 21 Oct 2025 20:23:58 +0200	[thread overview]
Message-ID: <87y0p4xge9.ffs@tglx> (raw)
In-Reply-To: <aPbeb1SEZr7CG2eN@kernel.org>

On Tue, Oct 21 2025 at 09:14, Troy Mitchell wrote:
> On Mon, Oct 20, 2025 at 07:44:55PM +0200, Thomas Gleixner wrote:
>> On Mon, Oct 20 2025 at 11:49, Troy Mitchell wrote:
>> > In asymmetric multi-processing (AMP) scenarios, the original PLIC
>> > driver used the context loop index 'i' as context_id for OF (device
>> 
>> Which original driver and when did it stop to use the context loop index?
>> 
>> > tree) platforms. This caused multiple contexts from different harts
>> > (e.g., core0 and core4) to share the same enable_base, leading to
>> > conflicts when initializing the PLIC.
>> 
>> When did it stop to cause the issues? And if the issues have been
>> already resolved, what is this patch about?
> The issue still exists in the current driver.
> The PLIC driver for OF-based platforms assigns context_id = i inside
> the context loop, which assumes that all harts are numbered contiguously
> starting from 0.
>
> In AMP systems (e.g., when Linux boots from hart4 while hart0 runs another OS),
> this assumption breaks — multiple contexts from different clusters share the same
> enable_base(e.g., core4's enable_base = core0's enable_base), causing conflicts.
>
> This patch fixes the problem by assigning context_id based on the actual hartid,
> ensuring that each hart context maps to a unique enable region,
> while preserving behavior on SMP and UP systems.
>
> Does it make sense? I'll update my commit message in the next version.

Yes. Though this still applies:
 
>> # git grep 'This patch' Documentation/process/

Thanks,

        tglx

  reply	other threads:[~2025-10-21 18:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-20  3:49 [PATCH] irqchip/sifive-plic: use hartid as context_id in OF to fix AMP conflicts Troy Mitchell
2025-10-20  3:49 ` Troy Mitchell
2025-10-20 17:44 ` Thomas Gleixner
2025-10-20 17:44   ` Thomas Gleixner
2025-10-21  1:14   ` Troy Mitchell
2025-10-21  1:14     ` Troy Mitchell
2025-10-21 18:23     ` Thomas Gleixner [this message]
2025-10-21 18:23       ` Thomas Gleixner
2025-10-23  6:09       ` Troy Mitchell
2025-10-23  6:09         ` Troy Mitchell

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=87y0p4xge9.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=alex@ghiti.fr \
    --cc=aou@eecs.berkeley.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=pjw@kernel.org \
    --cc=samuel.holland@sifive.com \
    --cc=troy.mitchell@linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.