From: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
To: Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org, mark.rutland@arm.com,
robin.murphy@arm.com, gshan@redhat.com, kernel-dev@igalia.com,
kernel@gpiccoli.net, Mark Brown <broonie@kernel.org>,
Ryan Houdek <sonicadvance1@gmail.com>
Subject: Re: [PATCH] arm64/kernel: Expose the running CPU of a native task in TPIDRRO_EL0
Date: Sun, 6 Sep 2026 11:55:19 -0300 [thread overview]
Message-ID: <9fd4a55c-82d4-f0f1-c42b-e67fa9965494@igalia.com> (raw)
In-Reply-To: <8207cba6-a6e0-38e6-a1bd-6f4453651793@igalia.com>
On 17/08/2026 11:48, Guilherme G. Piccoli wrote:
> Hi Will / Catalin / all,
> first of all, thanks for your prompt responses!
>
> I'm a bit confused on what "using the register" means here. We have 2
> ways of using it, IIUC:
>
> a) Use it as it's already used today! On kernel space, this register is
> kinda free, right? Currently, it's used as the scratch, in the entry.
> But nothing prevents other usages, given that, as the final step of exit
> to EL0, it's restored to the value of the CPU id. So, AFAIU, it's fair
> use on kernel space with or without this patch.
>
> b) Use as in "expose something else to userspace". Is it OK doing that,
> even the ARM specification mentioning
>
> "Purpose
> Provides a location where software executing at EL1 or higher can store
> thread identifying information that is visible to software executing at
> EL0, for OS management purposes." ?
>
> Or do you mean exposing **different information** than the pure CPU id,
> but still related with thread information?
>
> Would it be better if we guard this usage with a Kconfig? Or as Ryan
> already said, prctl flag or another idea?
>
>
> Finally, I would like to reinforce / disambiguate things here (though
> Ryan already mentioned): rseq or vDSO **are not** valid resources for
> our use case. What we are really interested is in having this register
> filled with CPU id.
> Cheers,
>
Hi Will / Catalin / others,
gentle ping on this one.
Could we implement it using a prctl flag or maybe Kconfig? Any other
ideas to move forward here?
Thanks again,
Guilherme
next prev parent reply other threads:[~2026-09-06 14:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-15 15:19 [PATCH] arm64/kernel: Expose the running CPU of a native task in TPIDRRO_EL0 Guilherme G. Piccoli
2026-08-15 16:52 ` Bradley Morgan
2026-08-17 14:51 ` Guilherme G. Piccoli
2026-08-17 14:56 ` Bradley Morgan
2026-08-16 9:51 ` Will Deacon
2026-08-17 8:51 ` Catalin Marinas
2026-08-17 12:53 ` Ryan Houdek
2026-08-17 14:48 ` Guilherme G. Piccoli
2026-09-06 14:55 ` Guilherme G. Piccoli [this message]
2026-09-09 18:38 ` Catalin Marinas
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=9fd4a55c-82d4-f0f1-c42b-e67fa9965494@igalia.com \
--to=gpiccoli@igalia.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=gshan@redhat.com \
--cc=kernel-dev@igalia.com \
--cc=kernel@gpiccoli.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=robin.murphy@arm.com \
--cc=sonicadvance1@gmail.com \
--cc=will@kernel.org \
/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