From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) by sourceware.org (Postfix) with ESMTPS id D8F4B3858D1E for ; Thu, 22 Dec 2022 20:28:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D8F4B3858D1E 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-pl1-x635.google.com with SMTP id u7so3045652plq.11 for ; Thu, 22 Dec 2022 12:28:02 -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=M5HwyEmiomjboVj/trHaxxWvGfVIfqkNF8FY6xGz8yM=; b=jY9mSbC5JDoPDVS5jt+FpQdnQrUyH/X6wqKUjthZ0lc8LdzMxpIkup1ar6IMmHfbdT gt8hu6IuB5W93JAwfipVoS8l/pmfVSsfBURw84IhCC8i9xyfX7L2kAMZc+TVNQIUweC3 qDMqyeSmlJHf6weTcWE9Amt5XK+28Nz3WGkhofGSOO7F6FnUDoFgm74IEnT91dvpcyca Yo52r2fzz3wC4Fp/yQaxKrQtWseoW5Z+NipBWRzs/duPrAwkICCxEakftW3RBmCLPT/F Ldc+WYpa/BNsRbmF7Rm7pgkH+Okx0yyvX5W/516+Z9smTHlsePdZ58ZfTDUipxvXkzcW /BfQ== 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=M5HwyEmiomjboVj/trHaxxWvGfVIfqkNF8FY6xGz8yM=; b=evIXHBz+Vkw0Q7goqljNo+OsY3+gZ1giHwoxrGqwJu83gOTl1G8wIRjwVuorSwWi79 i3GL53YCJY/Uu9/uQnStdtETp9B+7Ox1TpWOM20duBHRDRAtgNTNGdN7S1/0n/PF3oIe jsi/LJW5wcDN8jIBugQXBQUZZ0JLgO7nm6CXn13zCNM4F0mNiQ38SOCS4iuctf4QAomc RlCUvCS1oGquHfoRLF5L422+IIBPey8KnPRvh94tdTh6LOfIqkcqLpsKcWkCUakzMY0g 3y0CAh0jNOQm9Tc+SyTxGGcj3vO0ix+pok2cgkWMjY9qfbS8l/HfbvRbdpGOrws8Q76f zKaw== X-Gm-Message-State: AFqh2krhDA6KKikPxnpPmd12cpL2OXzIBaLSViVGJHh9449DShEC0j6N iJs6DU27O2TzMAgNVu0Gg5Nk+g== X-Google-Smtp-Source: AMrXdXthGIPtKi4Hv9LqMkflOsINub95XAD/fbg+asgyUkDowrE1+/YXEA7iw5vpsvW4sjialdWgbQ== X-Received: by 2002:a05:6a21:e301:b0:af:85b4:2397 with SMTP id cb1-20020a056a21e30100b000af85b42397mr9821855pzc.41.1671740881880; Thu, 22 Dec 2022 12:28:01 -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 t16-20020a634610000000b00473c36ea150sm1060512pga.92.2022.12.22.12.28.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Dec 2022 12:28:01 -0800 (PST) Message-ID: <91ef3c45-165f-d2b3-7c77-322c01802c41@rivosinc.com> Date: Thu, 22 Dec 2022 12:27:59 -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: Andy Chiu , Richard Henderson Cc: 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==?= , Philipp Tomsich , 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> <1631497278-29829-3-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> From: Vineet Gupta In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.4 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: On 12/22/22 10:33, Andy Chiu wrote: > On Thu, Dec 22, 2022 at 1:32 PM Richard Henderson > wrote: >> E.g. >> >> reserved[0] -> magic >> reserved[1] -> displacement to "extension area" >> reserved[2] -> size of "extension area" >> >> Thus the area can be located anywhere within 4GB and expand to 4GB. >> Not that I'd hope any signal frame would require 4GB. :-) >> > By encoding the extension magic into fp reserved space, and attaching > actual Vector states underneath, it is possible to make no size > changes to the sigcontext itself. In fact the comment section of > __riscv_q_ext_state specifies those bytes were purposely reserved for > sigcontext expansion. If this is the case then maybe we should just > use those reserved spaces anyway. > > struct __riscv_q_ext_state { > __u64 f[64] __attribute__((aligned(16))); > __u32 fcsr; > /* > * Reserved for expansion of sigcontext structure. Currently zeroed > * upon signal, and must be zero upon sigreturn. > */ > __u32 reserved[3]; > }; > > Here is a way that keeps the size and layout of sigcontext, while it > also manages to let the kernel write Vector state into an user's > signal stack. This approach also lets the user space leverage existing > reserved space to get context from new extensions. We introduce a new > struct, __riscv_extra_ext_header, unioning with __riscv_fp_state in > sigcontext. __riscv_extra_ext_header is the same size as > __riscv_fp_state. The only purpose of the struct is to point to the > magic header of a following extension, e.g. Vector, located at the > reserved space. If there is no more extension to come, then all of > those bytes should be zeros. > > struct sigcontext { > struct user_regs_struct sc_regs; > - union __riscv_fp_state sc_fpregs; > + union { > + union __riscv_fp_state sc_fpregs; > + struct __riscv_extra_ext_header sc_extdesc; > + }; > }; > > I wrote a PoC patch for this and it has been pushed into the following git tree: > https://github.com/sifive/riscv-linux/tree/dev/andyc/for-next-v13 > I tested it on a rv32 QEMU virt machine and the user space can get/set > Vector registers normally. I haven't tested it on rv64 yet but it > should be no difference. The patch is not the final version and maybe > I missed some basic ideas. But if everyone agrees with this approach > then I would like to start formalizing and submit the series. This approach looks perfect. Lets productize it to fold this patch into the respective patch(es). We would then need fixups to not unconditionally enable V on fork/execve and hook that up to a prctl. Let me work on that and provide something on top of your series. -Vineet