From: "Heiko Stübner" <heiko@sntech.de>
To: Andrew Jones <ajones@ventanamicro.com>
Cc: linux-riscv@lists.infradead.org, palmer@dabbelt.com,
christoph.muellner@vrull.eu, prabhakar.csengg@gmail.com,
conor@kernel.org, philipp.tomsich@vrull.eu,
emil.renner.berthing@canonical.com, ardb@kernel.org,
linux-efi@vger.kernel.org,
Conor Dooley <conor.dooley@microchip.com>
Subject: Re: [PATCH v3 11/14] RISC-V: fix auipc-jalr addresses in patched alternatives
Date: Wed, 07 Dec 2022 10:35:50 +0100 [thread overview]
Message-ID: <2256630.NgBsaNRSFp@diego> (raw)
In-Reply-To: <3628021.R56niFO833@diego>
Am Dienstag, 6. Dezember 2022, 23:10:01 CET schrieb Heiko Stübner:
> Am Donnerstag, 1. Dezember 2022, 20:33:53 CET schrieb Andrew Jones:
> > On Wed, Nov 30, 2022 at 11:56:11PM +0100, Heiko Stuebner wrote:
> > > From: Heiko Stuebner <heiko.stuebner@vrull.eu>
> > >
> > > Alternatives live in a different section, so addresses used by call
> > > functions will point to wrong locations after the patch got applied.
> > >
> > > Similar to arm64, adjust the location to consider that offset.
> > >
> > > Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
> > > Signed-off-by: Heiko Stuebner <heiko.stuebner@vrull.eu>
> > > ---
> > > arch/riscv/include/asm/alternative.h | 3 ++
> > > arch/riscv/kernel/alternative.c | 72 ++++++++++++++++++++++++++++
> > > arch/riscv/kernel/cpufeature.c | 11 ++++-
> > > 3 files changed, 84 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/riscv/include/asm/alternative.h b/arch/riscv/include/asm/alternative.h
> > > index 6511dd73e812..c58ec3cc4bc3 100644
> > > --- a/arch/riscv/include/asm/alternative.h
> > > +++ b/arch/riscv/include/asm/alternative.h
> > > @@ -27,6 +27,9 @@ void __init apply_boot_alternatives(void);
> > > void __init apply_early_boot_alternatives(void);
> > > void apply_module_alternatives(void *start, size_t length);
> > >
> > > +void riscv_alternative_fix_auipc_jalr(void *alt_ptr, unsigned int len,
> > > + int patch_offset);
> > > +
> > > struct alt_entry {
> > > void *old_ptr; /* address of original instruciton or data */
> > > void *alt_ptr; /* address of replacement instruction or data */
> > > diff --git a/arch/riscv/kernel/alternative.c b/arch/riscv/kernel/alternative.c
> > > index a7d26a00beea..292cc42dc3be 100644
> > > --- a/arch/riscv/kernel/alternative.c
> > > +++ b/arch/riscv/kernel/alternative.c
> > > @@ -15,6 +15,8 @@
> > > #include <asm/vendorid_list.h>
> > > #include <asm/sbi.h>
> > > #include <asm/csr.h>
> > > +#include <asm/insn.h>
> > > +#include <asm/patch.h>
> > >
> > > struct cpu_manufacturer_info_t {
> > > unsigned long vendor_id;
> > > @@ -53,6 +55,76 @@ static void __init_or_module riscv_fill_cpu_mfr_info(struct cpu_manufacturer_inf
> > > }
> > > }
> > >
> > > +static unsigned int riscv_instruction_at(void *p, unsigned int offset)
> >
> > How about explicitly returning a u32?
>
> ok
>
> > > +{
> > > + u16 *parcel = p + (offset * sizeof(u32));
> >
> > nit: I realize this is just a helper function, but I think a cleaner
> > interface would require the caller do this math, or at least the offset
> > scaling, since only the caller knows it's necessary. And, the call to
> > patch_text_nosync() requires all the math, so it'd be consistent for
> > riscv_instruction_at() to only take a pointer too.
>
> ok
>
> >
> > > +
> > > + return (unsigned int)parcel[0] | (unsigned int)parcel[1] << 16;
> > > +}
> > > +
> > > +static inline bool riscv_insn_is_auipc_jalr(u32 insn1, u32 insn2)
> > > +{
> > > + return riscv_insn_is_auipc(insn1) && riscv_insn_is_jalr(insn2);
> > > +}
> > > +
> > > +#define JALR_SIGN_MASK BIT(RV_I_IMM_SIGN_OPOFF - RV_I_IMM_11_0_OPOFF)
> >
> > We know I-type IMM is 11 bits, so we could just define this as BIT(11).
> >
> > > +#define AUIPC_PAD (0x00001000)
> > > +
> > > +#define to_jalr_imm(value) \
> > > + ((value & RV_I_IMM_11_0_MASK) << RV_I_IMM_11_0_OPOFF)
> >
> > Should put () around the macro argument, (value)
> >
> > > +
> > > +#define to_auipc_imm(value) \
> > > + ((value & JALR_SIGN_MASK) ? \
> > > + ((value & RV_U_IMM_31_12_MASK) + AUIPC_PAD) : \
> > > + (value & RV_U_IMM_31_12_MASK))
> >
> > I know RV_U_IMM_31_12_OPOFF is 0, but it looks odd not shifting
> > RV_U_IMM_31_12_MASK when we do shift RV_I_IMM_11_0_MASK.
> >
> > So, it looks like to_auipc_imm() is doing
> >
> > offset[31:12] + ((value & BIT(11)) ? (1 << 12) : 0)
> >
> > but the spec says the auipc part of the 'call' pseudoinstruction should be
>
> can you point me to that part of the spec?
>
> For educational purposes, because in the main riscv-spec I only found
> the main auipc + jalr descriptions, but nothing about the actual
> "call" pseudoinstruction.
>
> [and I'm probably just looking at the wrong document]
>
>
> > offset[31:12] + offset[11]
> >
> > which I think would be written as
> >
> > ((((value) & RV_U_IMM_31_12_MASK) << RV_U_IMM_31_12_OPOFF) + ((value) & BIT(11)))
> >
> > or what am I missing?
So far I've found the riscv-asm-manual [0], which only states for call
auipc x1, offset[31:12]
jalr x1, x1, offset[11:0]
and the psABI spec [1], neither mention your "offset[31:12] + offset[11]" ?
But [1] does contain that tiny sentence
"The successive instruction has a signed 12-bit immediate so the value
of the preceding high 20-bit relocation may have 1 added to it."
I.e. the lower 12 bits become themself a signed number [-2048:2047]
Take an example:
- address is 1862116 ( 0b 111000110 100111100100 )
- address[31:12] becomes 1859584 (as 0b 111000110 000000000000)
- while address[11:0] is 2532 as part of the bigger number
- as lone 12bit signed IMM it becomes -1564
- so you need to add this 4096 to the auipc IMM to compensate
Heiko
[0] https://github.com/riscv-non-isa/riscv-asm-manual/blob/master/riscv-asm.md
[1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/releases/tag/v1.0
>
> that whole thing came from the ftrace parts, also doing call fixup voodoo
> And I can't really say that I understand every nook and cranny of it.
>
> But for practical purposes, the addresses generated now work,
> and also seem to work for the ftrace counterpart (see include/asm/ftrace.h)
>
> [another place that will profit from more generalization :-) ]
>
>
> > > +
> > > +void riscv_alternative_fix_auipc_jalr(void *alt_ptr, unsigned int len,
> > > + int patch_offset)
> > > +{
> > > + int num_instr = len / sizeof(u32);
> > > + unsigned int call[2];
> > > + int i;
> > > + int imm;
> > > + u32 rd1;
> > > +
> > > + /*
> > > + * stop one instruction before the end, as we're checking
> > > + * for auipc + jalr
> > > + */
> > > + for (i = 0; i < num_instr - 1; i++) {
> >
> > If we change riscv_instruction_at() to just take a pointer then we can do
> > the math in the for() and actually just use pointer arithmetic.
> >
> > uint32_t *p = alt_ptr;
> > for (i = 0; i < num_instr - 1; i++, p++) {
>
> Wasn't not using uint32 pointers the whole point of going with the accessor?
>
>
> > > + u32 inst1 = riscv_instruction_at(alt_ptr, i);
> > p
> > > + u32 inst2 = riscv_instruction_at(alt_ptr, i + 1);
> > p + 1
> > > +
> > > + if (!riscv_insn_is_auipc_jalr(inst1, inst2))
> > > + continue;
> > > +
> > > + /* call will use ra register */
> > > + rd1 = RV_EXTRACT_RD_REG(inst1);
> > > + if (rd1 != 1)
> > > + continue;
> >
> > nit: rd1 is only used once, how about
> >
> > if (RV_EXTRACT_RD_REG(inst1) != 1)
>
> ok
>
>
> Need to look at the rest tomorrow
> Heiko
>
>
> > > +
> > > + /* get and adjust new target address */
> > > + imm = RV_EXTRACT_UTYPE_IMM(inst1);
> >
> > Based on my understanding of a auipc part of the 'call', it seems we
> > should be subtracting BIT(11) here. And, since RV_EXTRACT_* does sign-
> > extension for I-type, then I'm not sure we should use it. So,
> >
> > imm = (inst2 >> RV_I_IMM_11_0_OPOFF) & RV_I_IMM_11_0_MASK;
> > imm += ((inst1 >> RV_U_IMM_31_12_OPOFF) & RV_U_IMM_31_12_MASK) - (imm & BIT(11));
> >
> > > + imm += RV_EXTRACT_ITYPE_IMM(inst2);
> > > + imm -= patch_offset;
> > > +
> > > + /* pick the original auipc + jalr */
> > > + call[0] = inst1;
> > > + call[1] = inst2;
> > > +
> > > + /* drop the old IMMs */
> > > + call[0] &= ~(RV_U_IMM_31_12_MASK);
> >
> > Same comment as above about RV_U_IMM_31_12_OPOFF. IMO, this would be more
> > consistent with the shift, even though it's zero.
> >
> > call[0] &= ~(RV_U_IMM_31_12_MASK << RV_U_IMM_31_12_OPOFF);
> >
> > > + call[1] &= ~(RV_I_IMM_11_0_MASK << RV_I_IMM_11_0_OPOFF);
> > > +
> > > + /* add the adapted IMMs */
> > > + call[0] |= to_auipc_imm(imm);
> >
> > As pointed out above, I'm not sure about to_auipc_imm().
> >
> > > + call[1] |= to_jalr_imm(imm);
> > > +
> > > + /* patch the call place again */
> > > + patch_text_nosync(alt_ptr + i * sizeof(u32), call, 8);
> > ^ ^
> > p sizeof(u32) * 2
> > > + }
> > > +}
> > > +
> > > /*
> > > * This is called very early in the boot process (directly after we run
> > > * a feature detect on the boot CPU). No need to worry about other CPUs
> > > diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
> > > index 694267d1fe81..ba62a4ff5ccd 100644
> > > --- a/arch/riscv/kernel/cpufeature.c
> > > +++ b/arch/riscv/kernel/cpufeature.c
> > > @@ -316,8 +316,15 @@ void __init_or_module riscv_cpufeature_patch_func(struct alt_entry *begin,
> > > }
> > >
> > > tmp = (1U << alt->errata_id);
> > > - if (cpu_req_feature & tmp)
> > > - patch_text_nosync(alt->old_ptr, alt->alt_ptr, alt->alt_len);
> > > + if (cpu_req_feature & tmp) {
> > > + /* do the basic patching */
> > > + patch_text_nosync(alt->old_ptr, alt->alt_ptr,
> > > + alt->alt_len);
> >
> > nit: I'd leave this line long and only have one wrap in the line below
> >
> > > +
> > > + riscv_alternative_fix_auipc_jalr(alt->old_ptr,
> > > + alt->alt_len,
> > > + alt->old_ptr - alt->alt_ptr);
> > > + }
> > > }
> > > }
> > > #endif
> > >
> >
> > Thanks,
> > drew
> >
>
>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2022-12-07 9:36 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-30 22:56 [PATCH v3 0/14] Zbb string optimizations and call support in alternatives Heiko Stuebner
2022-11-30 22:56 ` [PATCH v3 01/14] RISC-V: fix funct4 definition for c.jalr in parse_asm.h Heiko Stuebner
2022-12-01 17:00 ` Andrew Jones
2022-12-01 17:05 ` Andrew Jones
2022-12-01 17:07 ` Heiko Stübner
2022-11-30 22:56 ` [PATCH v3 02/14] RISC-V: add prefix to all constants/macros " Heiko Stuebner
2022-12-05 14:00 ` Andrew Jones
2022-12-05 14:53 ` Andrew Jones
2022-12-05 15:30 ` Andrew Jones
2022-11-30 22:56 ` [PATCH v3 03/14] RISC-V: detach funct-values from their offset Heiko Stuebner
2022-12-01 17:36 ` Andrew Jones
2022-11-30 22:56 ` [PATCH v3 04/14] RISC-V: add ebreak instructions to definitions Heiko Stuebner
2022-11-30 22:56 ` [PATCH v3 05/14] RISC-V: add auipc elements to parse_asm header Heiko Stuebner
2022-11-30 22:56 ` [PATCH v3 06/14] RISC-V: Move riscv_insn_is_* macros into a common header Heiko Stuebner
2022-11-30 22:56 ` [PATCH v3 07/14] RISC-V: rename parse_asm.h to insn.h Heiko Stuebner
2022-11-30 22:56 ` [PATCH v3 08/14] RISC-V: kprobes: use central defined funct3 constants Heiko Stuebner
2022-11-30 22:56 ` [PATCH v3 09/14] RISC-V: add U-type imm parsing to insn.h header Heiko Stuebner
2022-11-30 22:56 ` [PATCH v3 10/14] RISC-V: add rd reg " Heiko Stuebner
2022-11-30 22:56 ` [PATCH v3 11/14] RISC-V: fix auipc-jalr addresses in patched alternatives Heiko Stuebner
2022-12-01 19:33 ` Andrew Jones
2022-12-06 15:56 ` Andrew Jones
2022-12-06 22:10 ` Heiko Stübner
2022-12-07 9:35 ` Heiko Stübner [this message]
2022-12-07 10:44 ` Andrew Jones
2022-12-07 11:19 ` Emil Renner Berthing
2022-12-07 11:29 ` Emil Renner Berthing
2022-12-07 11:32 ` Emil Renner Berthing
2022-11-30 22:56 ` [PATCH v3 12/14] efi/riscv: libstub: mark when compiling libstub Heiko Stuebner
2022-12-01 19:34 ` Andrew Jones
2022-12-01 20:57 ` Ard Biesheuvel
2022-12-01 22:39 ` Heiko Stübner
2022-12-02 16:37 ` Ard Biesheuvel
2023-01-04 15:21 ` Andrew Jones
2023-01-04 15:32 ` Heiko Stübner
2022-11-30 22:56 ` [PATCH v3 13/14] RISC-V: add infrastructure to allow different str* implementations Heiko Stuebner
2022-12-01 20:07 ` Andrew Jones
2022-12-01 20:14 ` Andrew Jones
2022-12-02 4:08 ` Palmer Dabbelt
2022-12-02 8:19 ` Ard Biesheuvel
2022-11-30 22:56 ` [PATCH v3 14/14] RISC-V: add zbb support to string functions Heiko Stuebner
2022-12-01 0:02 ` [PATCH v3 0/14] Zbb string optimizations and call support in alternatives Conor Dooley
2022-12-01 11:42 ` Heiko Stübner
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=2256630.NgBsaNRSFp@diego \
--to=heiko@sntech.de \
--cc=ajones@ventanamicro.com \
--cc=ardb@kernel.org \
--cc=christoph.muellner@vrull.eu \
--cc=conor.dooley@microchip.com \
--cc=conor@kernel.org \
--cc=emil.renner.berthing@canonical.com \
--cc=linux-efi@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=philipp.tomsich@vrull.eu \
--cc=prabhakar.csengg@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