Re: Auto-enabling V unit and/or use of elf attributes (was Re: Adding V-ext regs to signal context w/o expanding kernel struct sigcontext to avoid glibc ABI break)

From: Jeff Law <jlaw@ventanamicro.com>
To: Andy Chiu <andy.chiu@sifive.com>
Cc: "Richard Henderson" <richard.henderson@linaro.org>,
	"Vineet Gupta" <vineetg@rivosinc.com>,
	"Kito Cheng" <kito.cheng@sifive.com>,
	"Philipp Tomsich" <philipp.tomsich@vrull.eu>,
	"Vincent Chen" <vincent.chen@sifive.com>,
	"Florian Weimer" <fweimer@redhat.com>,
	"Rich Felker" <dalias@libc.org>,
	"Andrew Waterman" <andrew@sifive.com>,
	"Palmer Dabbelt" <palmer@rivosinc.com>,
	"Christoph Müllner" <christoph.muellner@vrull.eu>,
	davidlt@rivosinc.com, "Arnd Bergmann" <arnd@arndb.de>,
	"Björn Töpel" <bjorn@kernel.org>,
	"Szabolcs Nagy" <szabolcs.nagy@arm.com>,
	"Greentime Hu" <greentime.hu@sifive.com>,
	"Aaron Durbin" <adurbin@rivosinc.com>,
	"Andrew de los Reyes" <adlr@rivosinc.com>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	"GNU C Library" <libc-alpha@sourceware.org>
Subject: Re: Auto-enabling V unit and/or use of elf attributes (was Re: Adding V-ext regs to signal context w/o expanding kernel struct sigcontext to avoid glibc ABI break)
Date: Tue, 10 Jan 2023 23:20:07 -0700	[thread overview]
Message-ID: <e2a2ef3a-bb5e-0bda-20e5-a2344e7c4cef@ventanamicro.com> (raw)
In-Reply-To: <CABgGipUAhZNt3gaxEx7mPm20Xw7WNVVppRZ4fxZX-XswA5VG2g@mail.gmail.com>

On 1/10/23 23:00, Andy Chiu wrote:
> On Wed, Jan 11, 2023 at 1:07 PM Jeff Law <jlaw@ventanamicro.com> wrote:
>>
>>
>>
>> On 1/10/23 21:57, Richard Henderson wrote:
>>> On 1/10/23 20:28, Jeff Law wrote:
>>>>
>>>>
>>>> On 1/10/23 18:22, Richard Henderson wrote:
>>>>> On 1/10/23 10:07, Vineet Gupta wrote:
>>>>>> Yes bulk of glibc might not have vector code, but those V ifunc
>>>>>> routines do and IMO this information needs to be recorded somewhere
>>>>>> in the elf. Case in point being the current issue with how to enable
>>>>>> V unit. Community wants a per-process enable, using an explicit
>>>>>> prctl from userspace (since RV doesn't have fault-on-first use
>>>>>> hardware mechanism unlike some of the other arches). But how does
>>>>>> the glibc loader know to invoke prctl. We can't just rely on user
>>>>>> env GLIBC_TUNABLE etc since that might not be accurate. It needs
>>>>>> somethign concrete which IMO can come from elf attributes. If not,
>>>>>> do you have suggestions on how to solve this issue ?
>>>>>
>>>>> Why not just fault on first use to enable?  That's vastly less
>>>>> complicated than trying to plumb anything through elf resulting in a
>>>>> prctl.
>>>> Well, the answer is in Vineet's paragraph -- the hardware apparently
>>>> doesn't have fault-on-first-use which is mighty unfortunate.
>>>
>>> Nonsense -- sstatus.vs stores {off, initial, clean, dirty} state, just
>>> like fpu.
>>> Now treat the vector unit just like fpu lazy migration.
>> Then let's do something sensible.    Manually enabling via prctl seems
>> silly if we have fault on first use.
> Yes, faulting on first use is a viable way of approaching. However, my
> concern is that doing this on a system with libraries having common
> V-optimized routines such as memcpy, memset would essentially trap
> every process to m-mode starting up. This might take more cost than a
> prctl syscall. And if every process on the system wants to be
> benefited from V-optimized ifuncs, then having an additional prctl to
> call at start time seems tedious as well.
>
It's not perfect, but it's workable.  Explicitly turning things on seems 
like madness.  It boils down to having to annotate every binary and DSO 
and also adds complexity to JITs, the dynamic loader and probably all 
kinds of places we haven't thought through yet.

Fault on first use is well understood and has been implemented on many 
architectures through the decades, even with its warts.

jeff

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv