From: Puranjay Mohan <puranjay12@gmail.com>
To: "Björn Töpel" <bjorn@kernel.org>, "Mark Rutland" <mark.rutland@arm.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Steven Rostedt <rostedt@goodmis.org>,
"Masami Hiramatsu" <mhiramat@kernel.org>,
Sami Tolvanen <samitolvanen@google.com>,
Guo Ren <guoren@kernel.org>,
Ley Foon Tan <leyfoon.tan@starfivetech.com>,
Deepak Gupta <debug@rivosinc.com>,
Sia Jee Heng <jeeheng.sia@starfivetech.com>,
Bjorn Topel <bjorn@rivosinc.com>,
"Song Shuai" <suagrfillet@gmail.com>,
Cl'ement L'eger <cleger@rivosinc.com>,
"Al Viro" <viro@zeniv.linux.org.uk>,
Jisheng Zhang <jszhang@kernel.org>,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-trace-kernel@vger.kernel.org,
Andy Chiu <andy.chiu@sifive.com>
Subject: Re: [RFC PATCH] riscv: Implement HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS
Date: Thu, 14 Mar 2024 14:16:04 +0000 [thread overview]
Message-ID: <mb61pplvw6grf.fsf@gmail.com> (raw)
In-Reply-To: <8734suqsth.fsf@all.your.base.are.belong.to.us>
Björn Töpel <bjorn@kernel.org> writes:
>
> Hmm, depending on RISC-V's CMODX path, the pro/cons CALL_OPS vs dynamic
> trampolines changes quite a bit.
>
> The more I look at the pains of patching two instruction ("split
> immediates"), the better "patch data" + one insn patching look.
I was looking at how dynamic trampolines would be implemented for RISC-V.
With CALL-OPS we need to patch the auipc+jalr at function entry only, the
ops pointer above the function can be patched atomically.
With a dynamic trampoline we need a auipc+jalr pair at function entry to jump
to the trampoline and then another auipc+jalr pair to jump from trampoline to
ops->func. When the ops->func is modified, we would need to update the
auipc+jalr at in the trampoline.
So, I am not sure how to move forward here, CALL-OPS or Dynamic trampolines?
Thanks,
Puranjay
_______________________________________________
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: Puranjay Mohan <puranjay12@gmail.com>
To: "Björn Töpel" <bjorn@kernel.org>, "Mark Rutland" <mark.rutland@arm.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Steven Rostedt <rostedt@goodmis.org>,
"Masami Hiramatsu" <mhiramat@kernel.org>,
Sami Tolvanen <samitolvanen@google.com>,
Guo Ren <guoren@kernel.org>,
Ley Foon Tan <leyfoon.tan@starfivetech.com>,
Deepak Gupta <debug@rivosinc.com>,
Sia Jee Heng <jeeheng.sia@starfivetech.com>,
Bjorn Topel <bjorn@rivosinc.com>,
"Song Shuai" <suagrfillet@gmail.com>,
Cl'ement L'eger <cleger@rivosinc.com>,
"Al Viro" <viro@zeniv.linux.org.uk>,
Jisheng Zhang <jszhang@kernel.org>,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-trace-kernel@vger.kernel.org,
Andy Chiu <andy.chiu@sifive.com>
Subject: Re: [RFC PATCH] riscv: Implement HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS
Date: Thu, 14 Mar 2024 14:16:04 +0000 [thread overview]
Message-ID: <mb61pplvw6grf.fsf@gmail.com> (raw)
In-Reply-To: <8734suqsth.fsf@all.your.base.are.belong.to.us>
Björn Töpel <bjorn@kernel.org> writes:
>
> Hmm, depending on RISC-V's CMODX path, the pro/cons CALL_OPS vs dynamic
> trampolines changes quite a bit.
>
> The more I look at the pains of patching two instruction ("split
> immediates"), the better "patch data" + one insn patching look.
I was looking at how dynamic trampolines would be implemented for RISC-V.
With CALL-OPS we need to patch the auipc+jalr at function entry only, the
ops pointer above the function can be patched atomically.
With a dynamic trampoline we need a auipc+jalr pair at function entry to jump
to the trampoline and then another auipc+jalr pair to jump from trampoline to
ops->func. When the ops->func is modified, we would need to update the
auipc+jalr at in the trampoline.
So, I am not sure how to move forward here, CALL-OPS or Dynamic trampolines?
Thanks,
Puranjay
next prev parent reply other threads:[~2024-03-14 14:16 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-06 16:59 [RFC PATCH] riscv: Implement HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS Puranjay Mohan
2024-03-06 16:59 ` Puranjay Mohan
2024-03-06 20:35 ` Alexandre Ghiti
2024-03-06 20:35 ` Alexandre Ghiti
2024-03-06 20:38 ` Alexandre Ghiti
2024-03-06 20:38 ` Alexandre Ghiti
2024-03-07 0:17 ` Puranjay Mohan
2024-03-07 0:17 ` Puranjay Mohan
2024-03-08 8:48 ` Andy Chiu
2024-03-08 8:48 ` Andy Chiu
2024-03-11 13:56 ` [DMARC Error] " Evgenii Shatokhin
2024-03-11 13:56 ` Evgenii Shatokhin
2024-03-07 19:27 ` Björn Töpel
2024-03-07 19:27 ` Björn Töpel
2024-03-07 19:51 ` Puranjay Mohan
2024-03-07 19:51 ` Puranjay Mohan
2024-03-08 9:18 ` Andy Chiu
2024-03-08 9:18 ` Andy Chiu
2024-03-08 14:13 ` Puranjay Mohan
2024-03-08 14:13 ` Puranjay Mohan
2024-03-10 1:37 ` Guo Ren
2024-03-10 1:37 ` Guo Ren
2024-03-08 10:16 ` Björn Töpel
2024-03-08 10:16 ` Björn Töpel
2024-03-08 14:22 ` Puranjay Mohan
2024-03-08 14:22 ` Puranjay Mohan
2024-03-08 15:15 ` Björn Töpel
2024-03-08 15:15 ` Björn Töpel
2024-03-12 13:42 ` Mark Rutland
2024-03-12 13:42 ` Mark Rutland
2024-03-13 11:23 ` Björn Töpel
2024-03-13 11:23 ` Björn Töpel
2024-03-14 14:16 ` Puranjay Mohan [this message]
2024-03-14 14:16 ` Puranjay Mohan
2024-03-14 15:07 ` Björn Töpel
2024-03-14 15:07 ` Björn Töpel
2024-03-14 20:50 ` Björn Töpel
2024-03-14 20:50 ` Björn Töpel
2024-03-20 16:41 ` Andy Chiu
2024-03-20 16:41 ` Andy Chiu
2024-03-21 8:48 ` Björn Töpel
2024-03-21 8:48 ` Björn Töpel
2024-03-21 17:39 ` Andy Chiu
2024-03-21 17:39 ` Andy Chiu
2024-03-21 18:10 ` Björn Töpel
2024-03-21 18:10 ` Björn Töpel
2024-03-25 12:50 ` Robbin Ehn
2024-03-25 12:50 ` Robbin Ehn
2024-03-20 18:03 ` Mark Rutland
2024-03-20 18:03 ` Mark Rutland
2024-03-21 8:58 ` Björn Töpel
2024-03-21 8:58 ` Björn Töpel
2024-03-21 14:49 ` Steven Rostedt
2024-03-21 14:49 ` Steven Rostedt
2024-03-21 20:02 ` Steven Rostedt
2024-03-21 20:02 ` Steven Rostedt
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=mb61pplvw6grf.fsf@gmail.com \
--to=puranjay12@gmail.com \
--cc=andy.chiu@sifive.com \
--cc=aou@eecs.berkeley.edu \
--cc=bjorn@kernel.org \
--cc=bjorn@rivosinc.com \
--cc=cleger@rivosinc.com \
--cc=debug@rivosinc.com \
--cc=guoren@kernel.org \
--cc=jeeheng.sia@starfivetech.com \
--cc=jszhang@kernel.org \
--cc=leyfoon.tan@starfivetech.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mhiramat@kernel.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=rostedt@goodmis.org \
--cc=samitolvanen@google.com \
--cc=suagrfillet@gmail.com \
--cc=viro@zeniv.linux.org.uk \
/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.