From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) by sourceware.org (Postfix) with ESMTPS id 2A39A3858D35 for ; Wed, 4 Jan 2023 21:29:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2A39A3858D35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=vrull.eu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=vrull.eu Received: by mail-ed1-x52d.google.com with SMTP id g1so36201881edj.8 for ; Wed, 04 Jan 2023 13:29:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vrull.eu; s=google; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=VW+o1L6StC3VRfBH6+djYunwJoptCjK3QCsqzL95gaM=; b=r8I6cEwkWxq0MuZS8azw7CPZMCyQgSlvhqOxV4gJjEQJ+WQyxr0U8R9DqNcvRQRRZw o2ViBmbXvIRxPBsxwfmLIvTZSelVeS5aY2MzpLNsFwMQm4z9azTRjM51ES0BJisQhIbn Ear1COJD9ygPOtkTSzh+YWqUR7yJa+ROId58KAG38n0GxjOG0vieHz9rANGWA7IWaL3p tX/yTtKshwHQKdgGYmO9SGBvRDJA4GRvT51Ee5IcMMEKnH0VhApP6xSyYZxSL1CPrdPv haKcAgWQMLt0tvpH35d8zGb+He0D4cb2nV09eIL7jIjOWznyPxWN8rk7aB04THLwF4pf dqYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=VW+o1L6StC3VRfBH6+djYunwJoptCjK3QCsqzL95gaM=; b=H2HMMa/Eufywt9waxttK2HRBvO/hF0pkyKEwTCaf3ReeYPrS/Nvqz+mq8vbq2Wso3+ xkSX0PJ2uGvitcmK1EvC9XrHcqom+zZdv8bOtbcmtO3ykjfqUTG7+E2mZOTekdZ00D7V YPViDcvsQhycUd+stGkKFbCWZITsZ1OAekfAI+erBqQUlvqwECa8+Av8LBts83Rl1l6L 5CiJZaxPb7P51vWnnoDQAQewQzjtyi9peGJDCRNh7o7tBHWB/fjnHQz5wLis0Iz9go3N lDuD2vMAsx81V3I+7abEQsjMJJOueFSbs6G+pScy8VrUCeW538PW626rKV48iZbtSGFN tqfg== X-Gm-Message-State: AFqh2krkly3igvHO4Ann/Gwa4iCl81AJwDxtx80GjP3v7xtYx4T8wwYM xYixlelI8KMasrjInhH+VkXRHXSc/2Yh3ONPEIGAAg== X-Google-Smtp-Source: AMrXdXtkgrZjqVXqnayPeQ4OGAshsUnjIkM3fI1qfKsyBLCth9vNtl8KgvZhN9VBxp8MlZX7K08lkt2hAmyKgcVx9q0= X-Received: by 2002:aa7:dd17:0:b0:487:fdb6:11f2 with SMTP id i23-20020aa7dd17000000b00487fdb611f2mr3170781edv.213.1672867790761; Wed, 04 Jan 2023 13:29:50 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: From: Philipp Tomsich Date: Wed, 4 Jan 2023 22:29:39 +0100 Message-ID: Subject: Re: Adding V-ext regs to signal context w/o expanding kernel struct sigcontext to avoid glibc ABI break To: Vineet Gupta 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no 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 Wed, 4 Jan 2023 at 21:46, Vineet Gupta wrote: > > > > On 1/4/23 08:34, Andy Chiu wrote: > > Hi Vineet, > > > > On Wed, Jan 4, 2023 at 3:17 AM Vineet Gupta wrot= e: > >> The prctl support in there is really rudimentary and incomplete. There= 's > >> more work needed to use the dynamic state of enablement - for say sign= al > >> 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. 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=E2=80=A6 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. Philipp. > > > 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