From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) by sourceware.org (Postfix) with ESMTPS id 940583858D3C for ; Wed, 11 Jan 2023 06:20:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 940583858D3C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=ventanamicro.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ventanamicro.com Received: by mail-pj1-x102b.google.com with SMTP id o7-20020a17090a0a0700b00226c9b82c3aso16021212pjo.3 for ; Tue, 10 Jan 2023 22:20:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=Fywcalk7yz5BAvp56hQZy/QX+1/SrPMih03sNl/Yf74=; b=h6+a3uyzJrnnhsIet2BXcTFxftT22DyCw4Sgya1AtoqMN2ORk+awnnRZdneM1fPLXn 9GxOkn3tOfjBzW58x0j66FPYiiFNS3lrG8nL8El8JCL/UpA/AyRS4H18fUiaFUwaizWh bJN3pm6pwPFSCMOLtoefCIFPpDMffF9dqpJj1TpUYVexLY1EK2oR4JDZuzt0q46hIeLn bGkmnWVsTioKMy+GAkPL1OxF0sRAuN5UCwdm8qJA1VUVTXfusPOeXE5c3leY4l7Gp/eF dQb4uNUU8QHqhYrcTcE4RKOIgUQnl7eV7+UyF9Q5Be2DAWIbsUWpKpy8b3KcxwmfWkbO 77Ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Fywcalk7yz5BAvp56hQZy/QX+1/SrPMih03sNl/Yf74=; b=H9Qly2O0WA7qLFmIK9l8yo/6sNVK0Kwc5m1rO9LgP612yEtGmoUFdHAvR1R7l+MlkX UuW1lM6MCh907J/4o89qhusHM6kX1TrsYCIWhucA3dOhoaGXFnPePQgjhJohD0lhGu+C fzUBdKnUJNbxDVnA5GS/ooB8sVaoEONgpqp8Tzg6N5mrbl2sFdzsPLcoivTPYgxIuiaN svdhQD62Jg5d3WjcfTm/ojhGeC6SOM7U5kHxabTBCBwcC2FTQ276OGOPoduTpXiJv8Zb V8u9A65ZXVcnElO7AInsVRbzslLQmmluaQkIZzLU5zxiqcR4cNzxtFENfyFBcl8+JeLk pebQ== X-Gm-Message-State: AFqh2koYiaBqKPR+2p/QmCqYszF7zhFHC3oiQvdClqhSaweJdCjdUYxY B0mXLHZu1XNyS5PZRulQ8u49vg== X-Google-Smtp-Source: AMrXdXsO/simWGOG9rDo1VDsBKthiPIJgDqXVFyG61fw1CTujscbnuwlaPtWEZtIW7T4xLktmarvwA== X-Received: by 2002:a17:90b:3015:b0:226:c6fa:9843 with SMTP id hg21-20020a17090b301500b00226c6fa9843mr1358227pjb.1.1673418009659; Tue, 10 Jan 2023 22:20:09 -0800 (PST) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id t3-20020a17090a3e4300b002276ba8fb71sm2741230pjm.25.2023.01.10.22.20.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Jan 2023 22:20:09 -0800 (PST) Message-ID: Date: Tue, 10 Jan 2023 23:20:07 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 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) Content-Language: en-US To: Andy Chiu Cc: Richard Henderson , Vineet Gupta , Kito Cheng , Philipp Tomsich , Vincent Chen , Florian Weimer , Rich Felker , Andrew Waterman , Palmer Dabbelt , =?UTF-8?Q?Christoph_M=c3=bcllner?= , davidlt@rivosinc.com, Arnd Bergmann , =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , Szabolcs Nagy , Greentime Hu , Aaron Durbin , Andrew de los Reyes , linux-riscv , GNU C Library References: <1631497278-29829-1-git-send-email-vincent.chen@sifive.com> <18465ca3-934f-5b3e-170c-1ff0edea3a89@rivosinc.com> <1f8f1d21-4a19-54fe-8b29-bf9e2a8501d7@rivosinc.com> <3a838afe-974b-60bb-a0e5-83e366ec652e@rivosinc.com> <3923eeee-e4dc-0911-40bf-84c34aee962d@linaro.org> <119da65f-e976-f382-3fe1-1585be738352@ventanamicro.com> <8be4d673-f435-429e-9a61-bb49e7820529@linaro.org> <6d13e63f-69b3-6e48-b811-bbfcf3ffb3af@ventanamicro.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 1/10/23 23:00, Andy Chiu wrote: > On Wed, Jan 11, 2023 at 1:07 PM Jeff Law 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