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 8CAA81F47C for ; Wed, 4 Jan 2023 20:46:28 +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=l7f7AdRX; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E44FC3858C33 for ; Wed, 4 Jan 2023 20:46:27 +0000 (GMT) Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) by sourceware.org (Postfix) with ESMTPS id A4D5B3858D35 for ; Wed, 4 Jan 2023 20:46:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A4D5B3858D35 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-pl1-x629.google.com with SMTP id jn22so37048595plb.13 for ; Wed, 04 Jan 2023 12:46:14 -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=lle/zB44oW9ABB/MA6O0Fos1v7FE/0S5wxzDNIjMM9M=; b=l7f7AdRX6pFC6Xks4/zDMCQeItS7tzcMvS0pweFf7QPcgZu+IbxG5W/lj4h9iVqWOP tMBItJTu4eZyu0N5iHs7f8iV4tawzvaKZy9fyH1pbqrmwgMGRZpIu30A+3T0iJyWrHnB ufeaTymGwS8E+D0tTFb81p6yRn2yb5YLG+kIvXRrKxQJZXjiawAUwWkcq8IvxWrjXiZ3 Gs0b1fkqP3ObLmhESg/8uL7YpfnU87xwXLjvfKDJ3+Y+bHuvZKzirn3qfPKxYUVwvtwU ieyGZpcUvTXgFrGzKWvfoeiX27jHiDj/gntqlq2O8AmyzAsEhwq1Upu0RwifCGdA5s/M ixUA== 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=lle/zB44oW9ABB/MA6O0Fos1v7FE/0S5wxzDNIjMM9M=; b=h5f3vlrCXNppJ+hWBoQEDWHUnLKd08ORUO75LNkCUar2S/D38LW3KkNnaDJOQU9BR9 /V5C2DHaLLHds363nWX/ejlSriYuGURnTKEVXoylRzJec312TtNh3HavcdkndtrCkkRa Z2P856iwgj5rmL3A9ntTpG/S83arRStmeTl5XtnxxwLS7MYnOD6/8zWwDXkv3/BTpD+w iTkBwIIvxTeZASeJKWad4oGM2tXbnPMipKWYtET6rIIDtFjkUNnYkeaGeO38C4Dw4dHM ANV9zpcOvD6Ri6/mOP+Mm9ijp6uZtZgZDn45B+AZzuRdfjNMyGO/coL4lM9mDtaoEPIL p9Sw== X-Gm-Message-State: AFqh2krlzYRy7BFfrQMgvosY0iG4sHtUwfr+dpvePzHsO3cbFRvSHoDW SDn0GtbR3WIXR6nlL8fdUaYf2Q== X-Google-Smtp-Source: AMrXdXt+pZAzLb6BO6C8Ql5trJ4pGHaK0eCIqNlBw37Nbs+K3Ez2k8kvEb7U7nhlzD9o0LvzSmVrFQ== X-Received: by 2002:a17:90b:92:b0:225:eda7:13e with SMTP id bb18-20020a17090b009200b00225eda7013emr35690275pjb.40.1672865173676; Wed, 04 Jan 2023 12:46:13 -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 gn23-20020a17090ac79700b0020bfd6586c6sm1436pjb.7.2023.01.04.12.46.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Jan 2023 12:46:12 -0800 (PST) Message-ID: Date: Wed, 4 Jan 2023 12:46:10 -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: Andy Chiu Cc: 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==?= , Philipp Tomsich , 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> <871r5sd1zq.fsf@oldenburg.str.redhat.com> <20210913135247.GL13220@brightrain.aerifal.cx> <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: 7bit 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 08:34, Andy Chiu wrote: > Hi Vineet, > > On Wed, Jan 4, 2023 at 3:17 AM Vineet Gupta wrote: >> The prctl support in there is really rudimentary and incomplete. There's >> more work needed to use the dynamic state of enablement - for say signal >> frame etc. > Yes, I agree that signal and ptrace need special handling if we'd turn > off Vector with prctl. For example, we may not need to save/restore > vector context on context switches and signal handlings. And we may > have to prevent ptrace from setting/getting vector context in such > case. I can implement this into the series if this is what you're > looking for. Perfect. This is exactly the coverage I was hoping to see. Go for it. >> 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. > So IMHO adding a build option to those who prefer not to > unconditionally enable V should be sufficient. As above, it should be other way round. Thx, -Vineet