From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) by sourceware.org (Postfix) with ESMTPS id BE12D3858D3C for ; Wed, 11 Jan 2023 05:06:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BE12D3858D3C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=ventanamicro.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ventanamicro.com Received: by mail-vs1-xe32.google.com with SMTP id n190so10699908vsc.11 for ; Tue, 10 Jan 2023 21:06:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=6UT4FoLzAv+H9zbrENJDHPjacQhg44J2Qr9vwLm9dAM=; b=MgXd9Z1ZGIddXtjpt94ur+/ZmgYWjvP2pCwNsRLaE0LMoFi+5/003c/cNWYCg/PWBe PYpT9yGeKrMOwjrh+sG8TJ0aM6K9qAkCegMilsCsB2G8KgeajixmyPP4WRPegBg5yJvB 5FLDoD1sZ42uw4gxQFEqSUYH5pZS4bjscwbiEBD3xsy1xIC3jY82OFSAHr6AumDVBoaK VTJHXekuwRaZMGXKvOTM4PzJzLxm11R7/frwM1GyXvblMcWkHiCFHTrPWUFux2BAqF19 QIk5hvOO4kmkMqsl6o0RzNkmM9OkNG9Ul9EL2HifLWiappi9J9nu83Cwjz2OfvZvyRUr INrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=6UT4FoLzAv+H9zbrENJDHPjacQhg44J2Qr9vwLm9dAM=; b=ESxoqKFkG/FxXsuC4vHtEwVYAOv9M7JDoMUu9MjderV84ygm+0LL4pnyOTILv2f/de nn+ESRqFVt8ETH1z/gxm8fWDeEZ0fZjb8nVdQlV2nHdHkA1dLrF22pnTyfZXgQUXBsZQ 5If0It3xk/62BiS1YXI4dJ03FwF5UzNR6GBTVGJvJVrNz3Q6azB2hJjRVD56YszhTxks Hb6ur2yvqW67sdjksUt2w1d//XPt2oGf6FxibQ9Ni6GWBNqzb3HjVeS9NpcElGIzWyPm +7u5gumulrpS/bhkR0znUVR+TBw/CzFdjYYxTKvqrC4ePojfY81YTC85bZDawME3uxA7 yBPw== X-Gm-Message-State: AFqh2kqgqysZ93H5ksR8NbkeiUlaeyFhCXtZ3xJdGt/JYX3Ia+8Nbh21 p68C23mSYgCFbvUIpoibFAS3PO2Zo4FvXGpjzs2g3Q== X-Google-Smtp-Source: AMrXdXvyfszATrsXFdgNudU1uoZiX6coqs+bmnK72SLDbHN9VOXMihDBptQEgM1LQaBnnCnrIvnp5EcAGgDzJDzJRCg= X-Received: by 2002:a05:6102:50a1:b0:3cc:4e4d:efbb with SMTP id bl33-20020a05610250a100b003cc4e4defbbmr5468522vsb.59.1673413559955; Tue, 10 Jan 2023 21:05:59 -0800 (PST) MIME-Version: 1.0 References: <1631497278-29829-1-git-send-email-vincent.chen@sifive.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> <3a838afe-974b-60bb-a0e5-83e366ec652e@rivosinc.com> <3923eeee-e4dc-0911-40bf-84c34aee962d@linaro.org> In-Reply-To: <3923eeee-e4dc-0911-40bf-84c34aee962d@linaro.org> From: Anup Patel Date: Wed, 11 Jan 2023 10:35:48 +0530 Message-ID: Subject: Re: Auto-enabling V unit and/or use of elf attributes (was Re: Adding V-ext regs to signal context w/o expanding kernel struct sigcontext to avoid glibc ABI break) To: Richard Henderson Cc: Vineet Gupta , Kito Cheng , Philipp Tomsich , Andy Chiu , 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" X-Spam-Status: No, score=-4.1 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 11, 2023 at 6:53 AM Richard Henderson wrote: > > On 1/10/23 10:07, Vineet Gupta wrote: > > Yes bulk of glibc might not have vector code, but those V ifunc routines do and IMO this > > information needs to be recorded somewhere in the elf. Case in point being the current > > issue with how to enable V unit. Community wants a per-process enable, using an explicit > > prctl from userspace (since RV doesn't have fault-on-first use hardware mechanism unlike > > some of the other arches). But how does the glibc loader know to invoke prctl. We can't > > just rely on user env GLIBC_TUNABLE etc since that might not be accurate. It needs > > somethign concrete which IMO can come from elf attributes. If not, do you have suggestions > > on how to solve this issue ? > > Why not just fault on first use to enable? That's vastly less complicated than trying to > plumb anything through elf resulting in a prctl. > > You might say "but the fault could fail to allocate memory", but honestly, the prctl isn't > able to fail either -- if it doesn't work, the process must exit. And, surely, there's > some minimal vector configuration for which the allocation must succeed. IMO, this is a very good suggestion. For the benefit of everyone, both sstatus.FS and sstatus.VS have the following states: 1. Off (0): All off and any access to float / vector will result in exception 2. Initial (1): None dirty or clean, some on 3. Clean (2): None dirty, some clean 4. Dirty (3): Some dirty For float, we are setting sstatus.FS = 1 (Initial) in start_thread() by default for all tasks and we are doing lazy save-restore in fstate_save() and fstate_restore(). For vector, we can take a different approach where start_thread() will by default set sstatus.VS = 0 (Off) for all tasks. Now whenever any task access vector state, Linux RISC-V will get an exception and at that point in time we can allocate memory for the vector state and also set sstatus.VS = 1 (Initial) for that task. The save restore of the vector state can still be lazy for the tasks using it. Regards, Anup