From: Jason A. Donenfeld <Jason@zx2c4.com>
To: kvm-riscv@lists.infradead.org
Subject: [PATCH] riscv: require alternatives framework when selecting FPU support
Date: Thu, 23 Mar 2023 16:56:24 +0100 [thread overview]
Message-ID: <ZBx2qFFiaRSyJubo@zx2c4.com> (raw)
In-Reply-To: <af690061-f962-498e-b2df-d2e6119292cf@spud>
On Thu, Mar 23, 2023 at 02:49:34PM +0000, Conor Dooley wrote:
> This would requiring picking up your patch Jason, but with an
> "if !XIP_KERNEL" added to the select.
So the risk of making this all work is that we wind up forgetting to add
`select alternatives if !xip` to various places that need it (fpu, kvm,
maybe others? future others?), because it appears to work, thanks to the
code in your patch.
But making it work is also probably a good thing, since we obviously
want the fpu and maybe other things to work on xip kernels.
So maybe we should get rid of the CONFIG_RISCV_ALTERNATIVES knob
entirely, making it "always enabled", and then conditonalize the
alternatives code to BUILD_BUG_ON when called with CONFIG_XIP_KERNEL=y.
Then, this build bug will get hit immediately by
riscv_has_extension_*(), which will then require your patch, which can
run in a `if (IS_ENABLED(XIP_KERNEL))` block or similar.
The result of that will be:
- !xip kernels properly use the fast riscv_has_extension_*() code and
any alternatives code needed, since it's always selected.
- xip kernels get a BUILD_BUG_ON if they use any alternatives-based code
that doesn't have a xip fallback yet.
What do you think of that approach?
A "lighter weight" version of that approach would be to just remove all of
the `select RISCV_ALTERNATIVES` lines, and instead make
RISCV_ALTERNATIVES specify `default !XIP_KERNEL`. That would more or
less amount to the above too, though with weirder error cases.
Jason
WARNING: multiple messages have this Message-ID (diff)
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Conor Dooley <conor.dooley@microchip.com>
Cc: Andrew Jones <ajones@ventanamicro.com>,
Jisheng Zhang <jszhang@kernel.org>,
Conor Dooley <conor@kernel.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Anup Patel <anup@brainfault.org>,
Atish Patra <atishp@atishpatra.org>,
Heiko Stuebner <heiko@sntech.de>,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org, kvm-riscv@lists.infradead.org,
regressions@leemhuis.info, regressions@lists.linux.dev
Subject: Re: [PATCH] riscv: require alternatives framework when selecting FPU support
Date: Thu, 23 Mar 2023 16:56:24 +0100 [thread overview]
Message-ID: <ZBx2qFFiaRSyJubo@zx2c4.com> (raw)
In-Reply-To: <af690061-f962-498e-b2df-d2e6119292cf@spud>
On Thu, Mar 23, 2023 at 02:49:34PM +0000, Conor Dooley wrote:
> This would requiring picking up your patch Jason, but with an
> "if !XIP_KERNEL" added to the select.
So the risk of making this all work is that we wind up forgetting to add
`select alternatives if !xip` to various places that need it (fpu, kvm,
maybe others? future others?), because it appears to work, thanks to the
code in your patch.
But making it work is also probably a good thing, since we obviously
want the fpu and maybe other things to work on xip kernels.
So maybe we should get rid of the CONFIG_RISCV_ALTERNATIVES knob
entirely, making it "always enabled", and then conditonalize the
alternatives code to BUILD_BUG_ON when called with CONFIG_XIP_KERNEL=y.
Then, this build bug will get hit immediately by
riscv_has_extension_*(), which will then require your patch, which can
run in a `if (IS_ENABLED(XIP_KERNEL))` block or similar.
The result of that will be:
- !xip kernels properly use the fast riscv_has_extension_*() code and
any alternatives code needed, since it's always selected.
- xip kernels get a BUILD_BUG_ON if they use any alternatives-based code
that doesn't have a xip fallback yet.
What do you think of that approach?
A "lighter weight" version of that approach would be to just remove all of
the `select RISCV_ALTERNATIVES` lines, and instead make
RISCV_ALTERNATIVES specify `default !XIP_KERNEL`. That would more or
less amount to the above too, though with weirder error cases.
Jason
_______________________________________________
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: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Conor Dooley <conor.dooley@microchip.com>
Cc: Andrew Jones <ajones@ventanamicro.com>,
Jisheng Zhang <jszhang@kernel.org>,
Conor Dooley <conor@kernel.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Anup Patel <anup@brainfault.org>,
Atish Patra <atishp@atishpatra.org>,
Heiko Stuebner <heiko@sntech.de>,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org, kvm-riscv@lists.infradead.org,
regressions@leemhuis.info, regressions@lists.linux.dev
Subject: Re: [PATCH] riscv: require alternatives framework when selecting FPU support
Date: Thu, 23 Mar 2023 16:56:24 +0100 [thread overview]
Message-ID: <ZBx2qFFiaRSyJubo@zx2c4.com> (raw)
In-Reply-To: <af690061-f962-498e-b2df-d2e6119292cf@spud>
On Thu, Mar 23, 2023 at 02:49:34PM +0000, Conor Dooley wrote:
> This would requiring picking up your patch Jason, but with an
> "if !XIP_KERNEL" added to the select.
So the risk of making this all work is that we wind up forgetting to add
`select alternatives if !xip` to various places that need it (fpu, kvm,
maybe others? future others?), because it appears to work, thanks to the
code in your patch.
But making it work is also probably a good thing, since we obviously
want the fpu and maybe other things to work on xip kernels.
So maybe we should get rid of the CONFIG_RISCV_ALTERNATIVES knob
entirely, making it "always enabled", and then conditonalize the
alternatives code to BUILD_BUG_ON when called with CONFIG_XIP_KERNEL=y.
Then, this build bug will get hit immediately by
riscv_has_extension_*(), which will then require your patch, which can
run in a `if (IS_ENABLED(XIP_KERNEL))` block or similar.
The result of that will be:
- !xip kernels properly use the fast riscv_has_extension_*() code and
any alternatives code needed, since it's always selected.
- xip kernels get a BUILD_BUG_ON if they use any alternatives-based code
that doesn't have a xip fallback yet.
What do you think of that approach?
A "lighter weight" version of that approach would be to just remove all of
the `select RISCV_ALTERNATIVES` lines, and instead make
RISCV_ALTERNATIVES specify `default !XIP_KERNEL`. That would more or
less amount to the above too, though with weirder error cases.
Jason
next prev parent reply other threads:[~2023-03-23 15:56 UTC|newest]
Thread overview: 117+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-28 17:28 [PATCH v5 00/13] riscv: improve boot time isa extensions handling Jisheng Zhang
2023-01-28 17:28 ` Jisheng Zhang
2023-01-28 17:28 ` Jisheng Zhang
2023-01-28 17:28 ` [PATCH v5 01/13] riscv: move riscv_noncoherent_supported() out of ZICBOM probe Jisheng Zhang
2023-01-28 17:28 ` Jisheng Zhang
2023-01-28 17:28 ` Jisheng Zhang
2023-01-28 17:28 ` [PATCH v5 02/13] riscv: cpufeature: detect RISCV_ALTERNATIVES_EARLY_BOOT earlier Jisheng Zhang
2023-01-28 17:28 ` Jisheng Zhang
2023-01-28 17:28 ` Jisheng Zhang
2023-01-28 17:28 ` [PATCH v5 03/13] riscv: hwcap: make ISA extension ids can be used in asm Jisheng Zhang
2023-01-28 17:28 ` Jisheng Zhang
2023-01-28 17:28 ` Jisheng Zhang
2023-01-28 17:28 ` [PATCH v5 04/13] riscv: cpufeature: extend riscv_cpufeature_patch_func to all ISA extensions Jisheng Zhang
2023-01-28 17:28 ` Jisheng Zhang
2023-01-28 17:28 ` Jisheng Zhang
2023-01-28 17:28 ` [PATCH v5 05/13] riscv: introduce riscv_has_extension_[un]likely() Jisheng Zhang
2023-01-28 17:28 ` Jisheng Zhang
2023-01-28 17:28 ` Jisheng Zhang
2023-01-28 17:28 ` [PATCH v5 06/13] riscv: fpu: switch has_fpu() to riscv_has_extension_likely() Jisheng Zhang
2023-01-28 17:28 ` Jisheng Zhang
2023-01-28 17:28 ` Jisheng Zhang
2023-03-22 12:01 ` Jason A. Donenfeld
2023-03-22 12:01 ` Jason A. Donenfeld
2023-03-22 12:01 ` Jason A. Donenfeld
2023-03-22 12:09 ` [PATCH] riscv: require alternatives framework when selecting FPU support Jason A. Donenfeld
2023-03-22 12:09 ` Jason A. Donenfeld
2023-03-22 12:09 ` Jason A. Donenfeld
2023-03-22 12:46 ` Andrew Jones
2023-03-22 12:46 ` Andrew Jones
2023-03-22 12:46 ` Andrew Jones
2023-03-22 15:17 ` Conor Dooley
2023-03-22 15:17 ` Conor Dooley
2023-03-22 15:17 ` Conor Dooley
2023-03-22 19:26 ` Andrew Jones
2023-03-22 19:26 ` Andrew Jones
2023-03-22 19:26 ` Andrew Jones
2023-03-22 19:44 ` Conor Dooley
2023-03-22 19:44 ` Conor Dooley
2023-03-22 19:44 ` Conor Dooley
2023-03-22 20:05 ` Conor Dooley
2023-03-22 20:05 ` Conor Dooley
2023-03-22 20:05 ` Conor Dooley
2023-03-22 20:19 ` Jason A. Donenfeld
2023-03-22 20:19 ` Jason A. Donenfeld
2023-03-22 20:19 ` Jason A. Donenfeld
2023-03-23 14:49 ` Conor Dooley
2023-03-23 14:50 ` Conor Dooley
2023-03-23 14:49 ` Conor Dooley
2023-03-23 15:56 ` Jason A. Donenfeld [this message]
2023-03-23 15:56 ` Jason A. Donenfeld
2023-03-23 15:56 ` Jason A. Donenfeld
2023-03-23 22:19 ` Conor Dooley
2023-03-23 22:20 ` Conor Dooley
2023-03-23 22:19 ` Conor Dooley
2023-01-28 17:28 ` [PATCH v5 07/13] riscv: module: move find_section to module.h Jisheng Zhang
2023-01-28 17:28 ` Jisheng Zhang
2023-01-28 17:28 ` Jisheng Zhang
2023-01-28 17:28 ` [PATCH v5 08/13] riscv: module: Add ADD16 and SUB16 rela types Jisheng Zhang
2023-01-28 17:28 ` Jisheng Zhang
2023-01-28 17:28 ` Jisheng Zhang
2023-01-28 17:28 ` [PATCH v5 09/13] riscv: switch to relative alternative entries Jisheng Zhang
2023-01-28 17:28 ` Jisheng Zhang
2023-01-28 17:28 ` Jisheng Zhang
2023-01-28 17:28 ` [PATCH v5 10/13] riscv: alternative: patch alternatives in the vDSO Jisheng Zhang
2023-01-28 17:28 ` Jisheng Zhang
2023-01-28 17:28 ` Jisheng Zhang
2023-01-28 17:28 ` [PATCH v5 11/13] riscv: cpu_relax: switch to riscv_has_extension_likely() Jisheng Zhang
2023-01-28 17:28 ` Jisheng Zhang
2023-01-28 17:28 ` Jisheng Zhang
2023-01-28 17:28 ` [PATCH v5 12/13] riscv: KVM: Switch has_svinval() to riscv_has_extension_unlikely() Jisheng Zhang
2023-01-28 17:28 ` Jisheng Zhang
2023-01-28 17:28 ` Jisheng Zhang
2023-01-28 17:28 ` [PATCH v5 13/13] riscv: remove riscv_isa_ext_keys[] array and related usage Jisheng Zhang
2023-01-28 17:28 ` Jisheng Zhang
2023-01-28 17:28 ` Jisheng Zhang
2023-02-02 23:39 ` [PATCH v5 00/13] riscv: improve boot time isa extensions handling Palmer Dabbelt
2023-02-02 23:39 ` Palmer Dabbelt
2023-02-02 23:39 ` Palmer Dabbelt
2023-02-02 23:40 ` patchwork-bot+linux-riscv
2023-02-02 23:40 ` patchwork-bot+linux-riscv
2023-02-02 23:40 ` patchwork-bot+linux-riscv
2023-02-12 15:43 ` Guenter Roeck
2023-02-12 15:43 ` Guenter Roeck
2023-02-12 15:43 ` Guenter Roeck
2023-02-12 15:59 ` Conor Dooley
2023-02-12 16:00 ` Conor Dooley
2023-02-12 15:59 ` Conor Dooley
2023-02-12 16:33 ` Conor Dooley
2023-02-12 16:34 ` Conor Dooley
2023-02-12 16:33 ` Conor Dooley
2023-02-12 17:06 ` Conor Dooley
2023-02-12 17:06 ` Conor Dooley
2023-02-12 17:06 ` Conor Dooley
2023-02-12 18:06 ` Conor Dooley
2023-02-12 18:06 ` Conor Dooley
2023-02-12 18:06 ` Conor Dooley
2023-02-12 18:14 ` Guenter Roeck
2023-02-12 18:14 ` Guenter Roeck
2023-02-12 18:14 ` Guenter Roeck
2023-02-12 18:20 ` Conor Dooley
2023-02-12 18:20 ` Conor Dooley
2023-02-12 18:20 ` Conor Dooley
2023-02-12 18:38 ` Guenter Roeck
2023-02-12 18:38 ` Guenter Roeck
2023-02-12 18:38 ` Guenter Roeck
2023-02-12 18:45 ` Conor Dooley
2023-02-12 18:45 ` Conor Dooley
2023-02-12 18:45 ` Conor Dooley
2023-02-12 20:27 ` Guenter Roeck
2023-02-12 20:27 ` Guenter Roeck
2023-02-12 20:27 ` Guenter Roeck
2023-02-12 20:39 ` Conor Dooley
2023-02-12 20:40 ` Conor Dooley
2023-02-12 20:39 ` Conor Dooley
2023-02-12 22:21 ` Guenter Roeck
2023-02-12 22:21 ` Guenter Roeck
2023-02-12 22:21 ` Guenter Roeck
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=ZBx2qFFiaRSyJubo@zx2c4.com \
--to=jason@zx2c4.com \
--cc=kvm-riscv@lists.infradead.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 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.