From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS17314 8.43.84.0/22 X-Spam-Status: No, score=-3.6 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id DF06C1F47C for ; Wed, 11 Jan 2023 06:00:34 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (2048-bit key; unprotected) header.d=sifive.com header.i=@sifive.com header.a=rsa-sha256 header.s=google header.b=bISvrXus; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 1A6A43858C54 for ; Wed, 11 Jan 2023 06:00:34 +0000 (GMT) Received: from mail-yw1-x1129.google.com (mail-yw1-x1129.google.com [IPv6:2607:f8b0:4864:20::1129]) by sourceware.org (Postfix) with ESMTPS id D5C523858D3C for ; Wed, 11 Jan 2023 06:00:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D5C523858D3C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sifive.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sifive.com Received: by mail-yw1-x1129.google.com with SMTP id 00721157ae682-4d19b2686a9so55311297b3.6 for ; Tue, 10 Jan 2023 22:00:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=lR+5G6p9e9PJouD9oukN3LD1DIcHhlkX07GUBEIUVyQ=; b=bISvrXusYKlC6iyn2Q01lxv+ZoO+4aDPxMpF33yw63s74KxFDFtdkKDHIBqezT0NZR W1qUhVil5JMBrdCxpulCaynYsTxU+8bBZ37NFBEfWCUEnf+Fk2NbqROM7Fq8e+zFvCbQ conmk1E6S4J7cv5ZowUIbbhyHpJO31s+Mjj1bKCJSK8fHQseFbMeyapvvue+EKaNy+f1 WFUSq+n7lnJ+av3o59x7BILvTex8cpOky4rV7KEdYp2GKysZ5SAgUAAgvL+27nNLJUJg oQYJZD7b0S59aoDLKENr+XA5eI8IwgVDPLnaVXaNKMXfQGId3wSPj86ZsojAR6p8yZmt ZWRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=lR+5G6p9e9PJouD9oukN3LD1DIcHhlkX07GUBEIUVyQ=; b=a9mB7ebSFOvUsRlE3Wx0wLlweCz40LXoIzJQ/rWy6a1LR8cOURfTRvPufKq73O7DEC d2RXl4hjmH7ZNRVDip7Fae6KnQufm+4cZAHWCcU7rSH5z6GxdJMjco1LUM90V7g84h9r DHgPZcuUvwmnwcULH9qqu7tRtYPvuC+1o6prnUQKO0bUbWQoAVvGP8e7s6b4iD5Z1VJi 945YLpNKEUu8+Sif0IeYilCdVYv6GoJTOmEWs1UFEw9RncVH7Ey6Cx647eyveiHm4vap WeOmiYKXIO+QIj3EfNV6oT+NYljh1QcAu8S9HcvdAdD6b+eVyi8hV9jMtb2gWYsixUkf Ting== X-Gm-Message-State: AFqh2krfGNdBdm/OUG1RehD/Q/7g+wPxcCa7rV3D/zxG0nPqVN0m0j3A dG9FUNaLtlj6LlvrtCf47pLjCRhupZgXXw5NXLcXAg== X-Google-Smtp-Source: AMrXdXukgk6HQZVqIy+bBiSvkILhNpVEIuGr1yFzG4iu5yk1QVSsYLlCZ7BzjOQi4fdnJAKji+X/yv0xLKoOzHDEGl0= X-Received: by 2002:a81:6843:0:b0:47b:bada:70a0 with SMTP id d64-20020a816843000000b0047bbada70a0mr793891ywc.504.1673416822196; Tue, 10 Jan 2023 22:00:22 -0800 (PST) MIME-Version: 1.0 References: <1631497278-29829-1-git-send-email-vincent.chen@sifive.com> <91ef3c45-165f-d2b3-7c77-322c01802c41@rivosinc.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> In-Reply-To: <6d13e63f-69b3-6e48-b811-bbfcf3ffb3af@ventanamicro.com> From: Andy Chiu Date: Wed, 11 Jan 2023 14:00:11 +0800 Message-ID: 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) To: Jeff Law 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 Content-Type: text/plain; charset="UTF-8" X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" 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. Andy