From: Segher Boessenkool <segher@kernel.crashing.org>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: "linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
Nicholas Piggin <npiggin@gmail.com>
Subject: Re: [PATCH] powerpc/64s: POWER10 CPU Kconfig build option
Date: Thu, 6 Oct 2022 15:15:31 -0500 [thread overview]
Message-ID: <20221006201531.GT25951@gate.crashing.org> (raw)
In-Reply-To: <33e5c5e7-a25f-36bf-e7a1-8d6849cd4715@csgroup.eu>
Hi!
On Thu, Oct 06, 2022 at 06:07:32PM +0000, Christophe Leroy wrote:
> Le 23/09/2022 à 08:23, Nicholas Piggin a écrit :
> > I would rather complete prefixed support in the kernel and use pcrel
> > addressing. Actually even if we don't compile with pcrel or prefixed,
> > there are some instructions and we will probably get more that require
> > prefixed, possible we might want to use them in kernel. Some of it is
> > required to handle user mode instructions too. So I think removing
> > it is premature, but I guess it's up for debate.
>
> Well ok, in fact I only had code_patching in mind.
>
> Code patching is only for kernel text. Today code patching is used for
> things like kprobe, ftrace, etc .... which really do not seems to be
> prepared for prefixed instructions.
>
> If you are adding -mno-prefixed, it is worth keeping that code which
> sometimes gives us some headacke ?
-mpcrel requires -mprefixed. Using PC relative addressing will be a
significant performance benefit.
> Of course if there are plans to get real prefixed instruction in kernel
> code anytime soon, lets live with it, in that case the support should
> get completed. But otherwise I think it would be better to get rid of it
> for now, and implement it completely when we need it in years.
The future is unstoppable, certainly the near future is :-)
> When I see the following, I'm having hard time believing it would work
> with prefixed instructions in the kernel text:
>
> typedef u32 kprobe_opcode_t;
>
> struct kprobe {
> ...
> /* Saved opcode (which has been replaced with breakpoint) */
> kprobe_opcode_t opcode;
>
>
> void arch_disarm_kprobe(struct kprobe *p)
> {
> WARN_ON_ONCE(patch_instruction(p->addr, ppc_inst(p->opcode)));
> }
Why would it not work?
Segher
next prev parent reply other threads:[~2022-10-06 20:18 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-23 3:30 [PATCH] powerpc/64s: POWER10 CPU Kconfig build option Nicholas Piggin
2022-09-23 5:46 ` Christophe Leroy
2022-09-23 6:23 ` Nicholas Piggin
2022-10-06 18:07 ` Christophe Leroy
2022-10-06 20:15 ` Segher Boessenkool [this message]
2022-10-06 22:03 ` Nicholas Piggin
2022-10-10 3:41 ` Nicholas Piggin
2022-10-04 13:25 ` Michael Ellerman
2022-10-06 19:54 ` Segher Boessenkool
2022-10-06 21:56 ` Nicholas Piggin
2022-10-06 23:23 ` Segher Boessenkool
2022-10-07 0:03 ` Nicholas Piggin
2022-10-07 5:31 ` Michael Ellerman
2022-10-07 14:38 ` Segher Boessenkool
2022-10-07 14:57 ` Segher Boessenkool
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=20221006201531.GT25951@gate.crashing.org \
--to=segher@kernel.crashing.org \
--cc=christophe.leroy@csgroup.eu \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=npiggin@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).