Adding V-ext regs to signal context w/o expanding kernel struct sigcontext to avoid glibc ABI break
Vineet Gupta
vineetg at rivosinc.com
Wed Jan 4 12:46:10 PST 2023
On 1/4/23 08:34, Andy Chiu wrote:
> Hi Vineet,
>
> On Wed, Jan 4, 2023 at 3:17 AM Vineet Gupta <vineetg at rivosinc.com> wrote:
>> The prctl support in there is really rudimentary and incomplete. There's
>> more work needed to use the dynamic state of enablement - for say signal
>> frame etc.
> Yes, I agree that signal and ptrace need special handling if we'd turn
> off Vector with prctl. For example, we may not need to save/restore
> vector context on context switches and signal handlings. And we may
> have to prevent ptrace from setting/getting vector context in such
> case. I can implement this into the series if this is what you're
> looking for.
Perfect. This is exactly the coverage I was hoping to see. Go for it.
>> The new Kconfig CONFIG_RISCV_VSTATE_INIT_ALL seems like a
>> hack bolted on top.
> IIUC, most opinions suggested that we should keep the default Vector
> state to ON in thread:
> https://lore.kernel.org/all/20220921214439.1491510-17-stillson@rivosinc.com/T/#u
Actually community feedback is that they *don't * want the default
vector state to be on due to power implications, increased stack and
memory usage for vector contents (in that thread and else where as
well). So we should keep it disabled by default, but indeed we could
have that Kconfig option to enable it. Granted distro kernels will keep
it disabled by default, this lets vendors enable it selectively until
the full userspace enabling bits are in place.
> So IMHO adding a build option to those who prefer not to
> unconditionally enable V should be sufficient.
As above, it should be other way round.
Thx,
-Vineet
More information about the linux-riscv
mailing list