Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <24a1a812-95a9-ed97-abd1-c0ff259726d2@linaro.org>
Date:   Thu, 15 Dec 2022 07:33:53 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.2
Subject: Re: RISCV Vector unit disabled by default for new task (was Re:
 [PATCH v12 17/17] riscv: prctl to enable vector commands)
Content-Language: en-US
To:     Florian Weimer <fweimer@redhat.com>,
        =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= <bjorn@kernel.org>
Cc:     Darius Rad <darius@bluespec.com>,
        Vineet Gupta <vineetg@rivosinc.com>,
        Palmer Dabbelt <palmer@dabbelt.com>,
        Andrew Waterman <andrew@sifive.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,
        libc-alpha@sourceware.org, christoph.muellner@vrull.eu,
        Aaron Durbin <adurbin@rivosinc.com>, linux@rivosinc.com
References: <mhng-975b1d7b-7b3f-4e88-804c-8b22787f9588@palmer-ri-x1c9>
 <e9cf13a9-561a-3438-00f0-41fe2631888d@rivosinc.com>
 <Y5irn63DQkwumfvW@bruce.bluespec.com>
 <8fe9cfaf-2cbc-8de6-3928-067de9113bfc@rivosinc.com>
 <Y5qByfCtpV0uNID3@bruce.bluespec.com>
 <877cysx4yf.fsf@all.your.base.are.belong.to.us>
 <87h6xwdf5g.fsf@oldenburg.str.redhat.com>
From:   Richard Henderson <richard.henderson@linaro.org>
In-Reply-To: <87h6xwdf5g.fsf@oldenburg.str.redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 12/15/22 04:28, Florian Weimer via Libc-alpha wrote:
> * Björn Töpel:
> 
>>> For SVE, it is in fact disabled by default in the kernel.  When a thread
>>> executes the first SVE instruction, it will cause an exception, the kernel
>>> will allocate memory for SVE state and enable TIF_SVE.  Further use of SVE
>>> instructions will proceed without exceptions.  Although SVE is disabled by
>>> default, it is enabled automatically.  Since this is done automatically
>>> during an exception handler, there is no opportunity for memory allocation
>>> errors to be reported, as there are in the AMX case.
>>
>> Glibc has an SVE optimized memcpy, right? Doesn't that mean that pretty
>> much all processes on an SVE capable system will enable SVE (lazily)? If
>> so, that's close to "enabled by default" (unless SVE is disabled system
>> wide).
> 
> Yes, see sysdeps/aarch64/multiarch/memcpy.c:
> 
>    static inline __typeof (__redirect_memcpy) *
>    select_memcpy_ifunc (void)
>    {
>      INIT_ARCH ();
>    
>      if (sve && HAVE_AARCH64_SVE_ASM)
>        {
>          if (IS_A64FX (midr))
>            return __memcpy_a64fx;
>          return __memcpy_sve;
>        }
>    
>      if (IS_THUNDERX (midr))
>        return __memcpy_thunderx;
>    
>      if (IS_THUNDERX2 (midr) || IS_THUNDERX2PA (midr))
>        return __memcpy_thunderx2;
>    
>      if (IS_FALKOR (midr) || IS_PHECDA (midr))
>        return __memcpy_falkor;
>    
>      return __memcpy_generic;
>    }
>    
> And the __memcpy_sve implementation actually uses SVE.
> 
> If there were a prctl to select the vector width and enable the vector
> extension, we'd have to pick a width in glibc anyway.

There *is* a prctl to adjust the SVE vector width, but glibc does not need to select 
because SVE dynamically adjusts to the currently enabled width.  The kernel selects a 
default width that fits within the default signal frame size.

The other thing of note for SVE is that, with the default function ABI all of the SVE 
state is call-clobbered, which allows the kernel to drop instead of save state across 
system calls.  (There is a separate vector function call ABI when SVE types are used.)

So while strcpy may enable SVE for the thread, the next syscall may disable it again.


r~