Message-ID: <mhng-975b1d7b-7b3f-4e88-804c-8b22787f9588@palmer-ri-x1c9>
Date:   Fri, 09 Dec 2022 09:21:45 -0800 (PST)
From:   Palmer Dabbelt <palmer@...belt.com>
To:     fweimer@...hat.com
CC:     Andrew Waterman <andrew@...ive.com>,
        Vineet Gupta <vineetg@...osinc.com>, stillson@...osinc.com,
        Paul Walmsley <paul.walmsley@...ive.com>, anup@...infault.org,
        atishp@...shpatra.org, guoren@...nel.org,
        Conor Dooley <conor.dooley@...rochip.com>,
        greentime.hu@...ive.com, vincent.chen@...ive.com,
        andy.chiu@...ive.com, arnd@...nel.org,
        linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org,
        bjorn@...nel.org, libc-alpha@...rceware.org,
        christoph.muellner@...ll.eu, Aaron Durbin <adurbin@...osinc.com>,
        linux@...osinc.com
Subject:     Re: RISCV Vector unit disabled by default for new task (was Re: [PATCH v12 17/17] riscv: prctl to enable vector commands)

On Fri, 09 Dec 2022 05:04:23 PST (-0800), fweimer@...hat.com wrote:
> * 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.

The issue I'm worried about is that V needs more space in the 
ucontext-type structures.  We have an extensibility scheme there so we 
think it can be made to work, but IIUC we'll need glibc to be updated to 
handle the extended contexts in order to avoid losing state when doing 
ucontext-related operations like signal handling.

I don't see a way to handle that with just HWCAP, as we essentially need 
some bi-directional communicaton between userspace and the kernel so 
they can both decide to turn on V.  I don't think we strictly need a 
system call to do that, we kicked around the idea of encoding this in 
the ELF, but there's a lot of flavors of vector in RISC-V and we've had 
trouble trying to encode these in binaries before so it seems easier to 
just use the syscall.

> 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

Powered by blists - more mailing lists