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=-3.7 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI,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 6D7F61F47C for ; Mon, 9 Jan 2023 13:33:50 +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=KA/c+jpP; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 64CFB3858416 for ; Mon, 9 Jan 2023 13:33:48 +0000 (GMT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) by sourceware.org (Postfix) with ESMTPS id 803103858D20 for ; Mon, 9 Jan 2023 13:33:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 803103858D20 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-lf1-x135.google.com with SMTP id v25so12934225lfe.12 for ; Mon, 09 Jan 2023 05:33:33 -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=chE3iaM/I2AsUGj8pFR1rZVri/HumwNXcqKA4uAuvqQ=; b=KA/c+jpPqsYG9RKG7GM44BP+lEburLumWgCNiacm3WfSEEUygXKM7QMNbjYL/y3WbZ 2bwv3rO+9LnwfgNj5tYaHTZ9cw1Ixo9zH8+w6R8H6h9xV4ReiSSCMOrk06+aGohlJqDE 4M5lecXw+HQhJpcrX1+zw47bkQvaYE8vYLbmijiG/LEDPbB0bw0nWdhSTN/8RUG7hRwD lweV2BruU2LgIJV7zHmNwVVyalobOUwxzot2g5VzRbbqP6KOB8XLbGONBDCW/kUhKNOs mxiIoAVtSY2Duh53YTTn5eNjxHGBDwtnHjXazxh+FtWnhFNoqzgBSemgo5WZYKlkNj5g 9zrw== 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=chE3iaM/I2AsUGj8pFR1rZVri/HumwNXcqKA4uAuvqQ=; b=Oij8qa36LtkKnwGkOT+itHolRmqPn7aQKsvjt/h/IKbp7hIoXTDqmztuF/1MPajpl6 1x7i2kg1tepKyfIm5NI/MvLmFQrj/IyuNmhcr0pRpvc4Ot7etJpM9mYDPmPiIVNZM27s VTuhVaYU9ErWf4Wh+ZCYpZfoPnamT3rrdXAXQiEYWGcffF5On5eVLBPe0KbGr64z/+KO yfAy2Pl/71WswrlLWAoo1VB2hdsIZlr6a4hbm+0orI2u0krbOTYWC3sySkoL/3mdJKaS aZ3iXq6kX2pzTx+UnnEHaWOcEigt9KHK0emqqDWNT9mD0gVHzY3NfoQ+fvqJ3+oZRyOO E3Qg== X-Gm-Message-State: AFqh2koYHSwW7fQ2Vf3/B7zI0//QASgzrWeycW/4/HTRYK43nXqb41Rv p9FCGUySkig3BMIZz3UrQ2T8frDD420lfGaQKRYhKQ== X-Google-Smtp-Source: AMrXdXuHbWNt7mwfQOB8gnRg9VuDp/BXPug0MqwSjKMVuVT1ROH2lXFsRm3JGo7X6iCU5RztA4EUylkun5qlIpdb8RQ= X-Received: by 2002:a05:6512:3413:b0:4cc:82f6:256f with SMTP id i19-20020a056512341300b004cc82f6256fmr189816lfr.668.1673271211866; Mon, 09 Jan 2023 05:33:31 -0800 (PST) MIME-Version: 1.0 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> <1f8f1d21-4a19-54fe-8b29-bf9e2a8501d7@rivosinc.com> In-Reply-To: <1f8f1d21-4a19-54fe-8b29-bf9e2a8501d7@rivosinc.com> From: Kito Cheng Date: Mon, 9 Jan 2023 21:33:20 +0800 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: Philipp Tomsich , Andy Chiu , Richard Henderson , 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" Content-Transfer-Encoding: quoted-printable 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" Hi Vineet: > >>>> 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 kee= p > >> 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 > > 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. I don't think RISCV_ATTRIBUTES is the right place to check that - even if t= he program compiles without V, it still can enable V and then get performance benefit by ifunc in glibc, or even some 3rd party libraries might also be optimized with V ext. And don't forget other shared libraries in the system, are we going to check all dependent libraries at program load time? it will require resolving the library dependency at kernel. Or we intend to enable V only if executable compiles with V? > 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).