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: X-Spam-Status: No, score=-4.6 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,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 [IPv6:2620:52:3:1:0:246e:9693:128c]) (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 01C8F1F47C for ; Wed, 4 Jan 2023 22:43:26 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (2048-bit key; unprotected) header.d=rivosinc-com.20210112.gappssmtp.com header.i=@rivosinc-com.20210112.gappssmtp.com header.a=rsa-sha256 header.s=20210112 header.b=O1FuQeF0; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D60973858423 for ; Wed, 4 Jan 2023 22:43:22 +0000 (GMT) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) by sourceware.org (Postfix) with ESMTPS id CFA713858C54 for ; Wed, 4 Jan 2023 22:43:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CFA713858C54 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com Received: by mail-pf1-x436.google.com with SMTP id 18so11790914pfx.7 for ; Wed, 04 Jan 2023 14:43:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; 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=CH/GksoyQ7eGY7DkX8kZfT0W+/XE2gY76x4ssyQdIVU=; b=O1FuQeF0/OMopxUP425sEjF8ble0mj9nrnNey0bg3Bqb598B/ViCHrKAuGDqoLPqLi uVp5UYEMQ3phzW9RZujzcom+ZUORqTK1CDsSn1DeOexWYckP6JG/Km0QoGHir1lA3UKV iqR61FGZcIppiheckRFXdpHP8Vb3svS0nUZehOEWC45PYUDhADv/0+Es/uJnkJVwnP6W zgDWB/tjImbV1sPtwQaDouHbP3dIWPFLWYjaEmE+mejTa/RJP2qAo8Ukg7sK+pQId8Z5 4Wq69TpXISInKfNWcyEjBjiG6X4ZmbZ7WZbOdHWxqlpUocRuExdWLkpvggkuNOlj9v3C blRQ== 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=CH/GksoyQ7eGY7DkX8kZfT0W+/XE2gY76x4ssyQdIVU=; b=zFeUxcI5WLffyaruHaQgZ1lOTuSpoZgKuLijF4t+tRn0CLNJqCM8rjXgavgfHLe+n5 gOWoMed3lusVQU/fOb3kmGKDQnP+jWLwI6koqkqTMDR4MYBQZVRaRxLff1vSZ1FM7rJC A9+klUNE/tCEZ6wAt1xs62p4upS4y1UGcz3889VsaSwYGNegH5VbfANroUr24BBEavu8 wh5ct/r3D8ttuibmJxFp4xMptMndlyC8WtU9+lrbSDzwBlQLKEqikLSTNrKL9uZwddk1 7h+wdZVRkTWFKYbhKVdnqUaJM0AIFi/rKs6gZ0sQCM+JQo50IDMTxzxpefKbYT5tMWBP gXdw== X-Gm-Message-State: AFqh2kpha1qbn4sIBpCQhmYE/i0+K4DjigMQ3KuxW5JRNcEYP1FJp0Qb koxWhqB44l67UNAetMX2IwL2GA== X-Google-Smtp-Source: AMrXdXsqd4B2onkPisCRhs3U7HUpP89IIwJcmA1M3HjkuwBa8tU/6aBQMGlqcgSUNzu/8jzimUQQ0g== X-Received: by 2002:a05:6a00:1ca3:b0:582:ec3a:5145 with SMTP id y35-20020a056a001ca300b00582ec3a5145mr4434522pfw.6.1672872187795; Wed, 04 Jan 2023 14:43:07 -0800 (PST) Received: from [192.168.50.116] (c-24-4-73-83.hsd1.ca.comcast.net. [24.4.73.83]) by smtp.gmail.com with ESMTPSA id j1-20020a62c501000000b00581d48ad9b0sm12101331pfg.154.2023.01.04.14.43.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Jan 2023 14:43:06 -0800 (PST) Message-ID: <1f8f1d21-4a19-54fe-8b29-bf9e2a8501d7@rivosinc.com> Date: Wed, 4 Jan 2023 14:43:04 -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: Adding V-ext regs to signal context w/o expanding kernel struct sigcontext to avoid glibc ABI break Content-Language: en-US To: Philipp Tomsich Cc: Andy Chiu , Richard Henderson , Vincent Chen , Florian Weimer , Rich Felker , Andrew Waterman , Palmer Dabbelt , Kito Cheng , =?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> <87sfy5ndid.fsf@oldenburg.str.redhat.com> <73c0124c-4794-6e40-460c-b26df407f322@rivosinc.com> <50c598a6-e3b3-3062-abe7-23a406067533@rivosinc.com> <7430f494-9b43-5e03-c1e9-6b83e2611a11@rivosinc.com> <91ef3c45-165f-d2b3-7c77-322c01802c41@rivosinc.com> <18465ca3-934f-5b3e-170c-1ff0edea3a89@rivosinc.com> From: Vineet Gupta In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 1/4/23 13:29, Philipp Tomsich wrote: >>>> The new Kconfig CONFIG_RISCV_VSTATE_INIT_ALL seems like a >>>> hack bolted on top. >>> IIUC, most opinions suggested that we should keep the default Vector >>> state to ON in thread: >>> https://lore.kernel.org/all/20220921214439.1491510-17-stillson@rivosinc.com/T/#u >> Actually community feedback is that they *don't * want the default >> vector state to be on due to power implications, increased stack and >> memory usage for vector contents (in that thread and else where as >> well). So we should keep it disabled by default, but indeed we could >> have that Kconfig option to enable it. Granted distro kernels will keep >> it disabled by default, this lets vendors enable it selectively until >> the full userspace enabling bits are in place. > Should we punt this to the ELF (e.g., using a RISC-V specific > attribute) and take a per-process decision on whether to start in ON > or OFF? > I don't feel fully comfortable with a KCONFIG that could change and > invalidate the assumptions a userspace process could have made… The Kconfig is just a stop gap for vendors to enable V development while the full userspace stuff is sorted out. Indeed RISCV_ATTRIBUTES section has -march info, but we need to do some development around it to parse it and use it. There are still corner cases such as non-V executable dlopen a dso - so kernel elf parser doing this might not cover all cases. Similar logic will need to be added to glibc loader - eventually. Adding the full plumbing is a chicken-and-egg problem. > Alternatively, we could establish the convention of having two stub > libraries that set up either enabled or disable state from their > .init_array to provide a mechanism for folks that want to make an > explicit assumption. Although this may try to overdesign a solution > for a non-issue. I was thinking more along the lines of x86 GLIBC_TUNABLES to enable it via env/sub-shell on a per-task basis - the tunable hook could in turn verify that Vector support does exist - or it could invoke the prctl unconditionally (which would fail if V didn't exist etc).