From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) by sourceware.org (Postfix) with ESMTPS id 40A473858D39 for ; Wed, 4 Jan 2023 21:38:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 40A473858D39 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-il1-x136.google.com with SMTP id p15so9182898ilg.9 for ; Wed, 04 Jan 2023 13:38:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; 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=nZjvACipyW+kfRXXX+ecbaA5spgW4jYeTs+sqkargLc=; b=BcVf880cxpZVL3hD/o9rRH7s7SiFpCgcJuWUUK5Fp9ln+KRb4tBDR8KddW/AN9ir7i 3D+6cCgSx463Vh9uQY7Vmfe/8rg37497lBOZp69hjZm/j22KM4xYo2xZP1KBxcGzlP65 paApSGntvFe+evOMrMt9e1zQjkIKtPIwCvY+/lrC4ycFEY5nLjfwgxeQIldEUYaissSt KFA5wpq8+YDNetdFOQ6SBoj9unpneR7n7+Iyfo18NEb3DQc2OTlaCfWsWKxcj2qeTW1H Bv+OA0UOhO4foSESWPYK98D9sG5r2L4vViPBAREr1bqjfoSIW98jKUic6QJ/R6Nq95M9 BMMA== 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=nZjvACipyW+kfRXXX+ecbaA5spgW4jYeTs+sqkargLc=; b=y8KHAtJYmvxuK4uewDJaZGqTIiBiKP11AJBcNDb8FRL1urBFcmU5gwcl38KEINBs4j durT2qNPWDbGYjXPG6Meu9kQIhUnfuVkGIPG23mHFaEd/T/qgpUhkuBX7Xv6Em6IfM5/ mLSjXFW2iu6nMH92NKq1CllfwxK5N7B+kbMYGewMlXb93iWjmZz4CAC+JZ8Y2k3YYJRQ siIZzx3nD1L56qg7ukK8+Sm7YrdTzM6Kpj6fbPiLa48p27S2HeE6ttqi/IAhftbMYP15 xB8hQAKUz5ztg8I4ow8ARgJVcPfV/NRnHNZq3NBfJw8Ya0c+LhHPPGOTF+GvXZF85rfk Pe+g== X-Gm-Message-State: AFqh2kqxFgyOMLnGzc/YksR78pNHXbki19lZpIzhfIXAi5O6fzRZIBQl dY/hcfan937CwJdDzMEeT5oxX0Nd3GaZRFf8W11iFWRVefmoZfRRduMykLRgaqUIeyoriLfmfxp s4Ox1ugSlae/JelcFzd5j8IEa3rmhKE9qPvrZH4TbIYj6Y2hv3XbYJW9kTwIN1K3pEgWOrqJ5vA == X-Google-Smtp-Source: AMrXdXuLRNtLScY8mPSzdKP1yQ8v0FutfCSzd2drkmLDW5KxXAUJwXVLLD6PmpSf5AHnsHJc+REFEA== X-Received: by 2002:a05:6e02:972:b0:30c:436d:a6ab with SMTP id q18-20020a056e02097200b0030c436da6abmr9216082ilt.12.1672868285123; Wed, 04 Jan 2023 13:38:05 -0800 (PST) Received: from mail-il1-f176.google.com (mail-il1-f176.google.com. [209.85.166.176]) by smtp.gmail.com with ESMTPSA id u6-20020a056e02110600b0030d6d425cd9sm1031266ilk.57.2023.01.04.13.38.04 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Jan 2023 13:38:04 -0800 (PST) Received: by mail-il1-f176.google.com with SMTP id g2so17005802ila.4 for ; Wed, 04 Jan 2023 13:38:04 -0800 (PST) X-Received: by 2002:a92:cd0f:0:b0:303:19d2:9def with SMTP id z15-20020a92cd0f000000b0030319d29defmr4436974iln.21.1672868283710; Wed, 04 Jan 2023 13:38:03 -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: Andrew Waterman Date: Wed, 4 Jan 2023 13:37:51 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Adding V-ext regs to signal context w/o expanding kernel struct sigcontext to avoid glibc ABI break To: Philipp Tomsich Cc: Vineet Gupta , Andy Chiu , Richard Henderson , Vincent Chen , Florian Weimer , Rich Felker , 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.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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 Wed, Jan 4, 2023 at 1:29 PM Philipp Tomsich w= rote: > > 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 wr= ote: > > >> The prctl support in there is really rudimentary and incomplete. The= re's > > >> more work needed to use the dynamic state of enablement - for say si= gnal > > >> frame etc. > > > Yes, I agree that signal and ptrace need special handling if we'd tur= n > > > 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@rivosi= nc.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 I am supremely confident we will eventually have userspace that unconditionally wants V (for optimized C library routines at minimum), and that it will follow very closely on the heels of V becoming mainstream. So, your proposal to embed this information in the ELF header (so that the kernel can enable V automatically on program load, or so the dynamic loader can execute the `prctl` call on library load, or whatever) seems more forward-looking to me than making this a Kconfig option. > > 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