From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) by sourceware.org (Postfix) with ESMTPS id 74EEB3858D1E for ; Mon, 9 Jan 2023 19:16:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 74EEB3858D1E 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-pf1-x432.google.com with SMTP id a30so6928323pfr.6 for ; Mon, 09 Jan 2023 11:16:38 -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=36j6vxRdrN87qT9QG9gc8q89/F94zjQ4zX9eyo6qDi0=; b=Q6VyJuZP6ZWcuQ3OTp5DozEx8Ne3i6oXmBm61F1yhW8fr2legrtQFdbDqwV4xtMv60 BQzX6iX2wD67GnFoPDozCtQxmzwMANI9lRFVv7AkUTeUPZc5do5pfm1IbWshw2vvxlRm FP776wJLGZblFpEhED3D2QtJK3H/nn1ZImJXsDmge1bJwZCtaBY3O+6zKVnuBx1LYxW9 OCDDLCe14cWHcTuI7INqO9rHjf8XwaYAE10aoiO5bzk38uHWPqCECzASWaF+ZIciXxiB be4nsT737dm4LcnX5TxKZxS0AUplHZWpgCHAmZTlBrHsXYGidRA5Yz+0fcrshJjIJh0q Y/rw== 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=36j6vxRdrN87qT9QG9gc8q89/F94zjQ4zX9eyo6qDi0=; b=U9goHSM9aDITlRa1hk0Qydf2Wz85dVh62fcTAyG90Q+p+JgYKEYQI5k5/a3c4G81k2 mvsmdq1FPKVspmEae9un7gey8qyv6KahlfHC8Zs/yFoOY/yS+OverVDCETI4OVSPRfr9 9rRrJIi6A3PUA4Bv79Z9dXOvF0PGNwzfu1O1cCZ8TeBOX6YR8nHIn0xT3TEf+MfdLvGw 0eGq4BY/JESVWqU6Ygm+r4aiHm8M56XaiIh/tmgFzr1NMTyjnTfaMQ3iw9suBpWh8pQz xZKJQTS4QUEwbC1vOEoxpK5756jbf55SbL8yOwNI65zGoXxBQ9la5ffXkTN3pxTEsPCR Xdow== X-Gm-Message-State: AFqh2koWAQJguUvHRb3M9J4SrDbG38YrQtensiMVyUwHgDwdNZZA7BLB AfOc/sTZNOJm1JZucU1b+H5b8Q== X-Google-Smtp-Source: AMrXdXv0O5WaluwoFm8aPDb6dSP9+OFCBzpMT5xJOVFG0YkRDZ61Rd0iQFmmj6amw0kPPWPHKGzXsA== X-Received: by 2002:a05:6a00:4148:b0:582:a8f2:675 with SMTP id bv8-20020a056a00414800b00582a8f20675mr24864865pfb.20.1673291797385; Mon, 09 Jan 2023 11:16:37 -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 p6-20020aa79e86000000b0056b4c5dde61sm6611960pfq.98.2023.01.09.11.16.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Jan 2023 11:16:36 -0800 (PST) Message-ID: <3a838afe-974b-60bb-a0e5-83e366ec652e@rivosinc.com> Date: Mon, 9 Jan 2023 11:16:34 -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: Kito Cheng 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 References: <1631497278-29829-1-git-send-email-vincent.chen@sifive.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> From: Vineet Gupta In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,NICE_REPLY_A,RCVD_IN_BARRACUDACENTRAL,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: Hi Kito, On 1/9/23 05:33, Kito Cheng wrote: > 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@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… >> 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 - What a timing. I just finished testing initial kernel patch to parse the elf section and on to tag parsing now ;-) https://git.kernel.org/pub/scm/linux/kernel/git/vgupta/linux.git/log/?h=topic-elf-attr > even if the > 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. Right kernel can only handle dynamic executable and/or the the loader itself. If V is used distro wide we are covered. And it can then also pass this info (V enabled as HWCAP*, no need for everything) But you are not suggesting that there is a scenario with executable built somehow with V instructions (even .byte encoded) but not have that info encoded in RV_ATTR_TAG_arch string. And I'd argue that it is user error, they need to make sure that -march had 'v' passed to compiler and/or assembler. > And don't forget other shared libraries in the system, No I've not forgotten about shared libs (and there's also a case of non-V built executable dlopen a V built dso) which can't be handled by above. > 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? So we need a similar parsing in glibc loader which creates a union of "V enabled in any lib" and then invokes the prctl to enable, if it is not already. -Vineet