Re: RISCV Vector unit disabled by default for new task (was Re: [PATCH v12 17/17] riscv: prctl to enable vector commands)

From: Florian Weimer <fweimer@redhat.com>
To: Andrew Waterman <andrew@sifive.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>,
	 Vineet Gupta <vineetg@rivosinc.com>,
	 stillson@rivosinc.com,  Paul Walmsley <paul.walmsley@sifive.com>,
	 anup@brainfault.org,  atishp@atishpatra.org, guoren@kernel.org,
	 Conor Dooley <conor.dooley@microchip.com>,
	greentime.hu@sifive.com,  vincent.chen@sifive.com,
	 andy.chiu@sifive.com, arnd@kernel.org,
	 linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
	 bjorn@kernel.org, libc-alpha@sourceware.org,
	 christoph.muellner@vrull.eu,
	 Aaron Durbin <adurbin@rivosinc.com>,
	 linux@rivosinc.com
Subject: Re: RISCV Vector unit disabled by default for new task (was Re: [PATCH v12 17/17] riscv: prctl to enable vector commands)
Date: Fri, 09 Dec 2022 14:04:23 +0100	[thread overview]
Message-ID: <87zgbwk9t4.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <Y5MtTLtrDnCW6Dik@bruce.bluespec.com> (Darius Rad's message of "Fri, 9 Dec 2022 07:42:52 -0500")

* Darius Rad:

> On Fri, Dec 09, 2022 at 01:32:33PM +0100, Florian Weimer via Libc-alpha wrote:
>> * Darius Rad:
>> 
>> > On Fri, Dec 09, 2022 at 11:02:57AM +0100, Florian Weimer wrote:
>> >> * Andrew Waterman:
>> >> 
>> >> > This suggests that ld.so, early-stage libc, or possibly both will need
>> >> > to make this prctl() call, perhaps by parsing the ELF headers of the
>> >> > binary and each library to determine if the V extension is used.
>> >> 
>> >> If the string functions use the V extension, it will be enabled
>> >> unconditionally.  So I don't see why it's okay for libc to trigger this
>> >> alleged UAPI change, when the kernel can't do it by default.
>> >> 
>> >
>> > Because the call to enable can fail and userspace needs to deal with that.
>> 
>> Failure is usually indicated by an AT_HWCAP or AT_HWCAP2 bit remaining
>> zero, or perhaps a special CPU register (although that is more unusual).
>
> That would indicate that the extension is not present, which is one of, but
> not the only way it can fail.

I think you should bring down the number of failure modes.  HWCAP has
the advantage that it communicates kernel/hypervisor/firmware/CPU
support in a single bit, which simplifies the programming model and
avoids hard-to-detect bugs.  It's not clear why it would be beneficial
to continue on ENOMEM failures here because the system must clearly be
in bad shape at this point, and launching a new process is very unlikely
to improve matters.  So I think the simpler programming model is the way
to go here.

> The vector extension relies on dynamically allocated memory in the kernel,
> which can fail.

But this failure can be reported as part of execve and clone.

> It also provides the opportunity for the kernel to deny access to the
> vector extension, perhaps due to administrative policy or other future
> mechanism.

HWCAP can do this, too.

Thanks,
Florian

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