From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS17314 8.43.84.0/22 X-Spam-Status: No, score=-3.0 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,PDS_RDNS_DYNAMIC_FP,RCVD_IN_DNSWL_MED,RDNS_DYNAMIC, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (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 133CF1F852 for ; Thu, 22 Dec 2022 18:33:52 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (2048-bit key; unprotected) header.d=sifive.com header.i=@sifive.com header.b="akTL9yqy"; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 001FC385B521 for ; Thu, 22 Dec 2022 18:33:50 +0000 (GMT) Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) by sourceware.org (Postfix) with ESMTPS id 4606B3858D1E for ; Thu, 22 Dec 2022 18:33:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4606B3858D1E 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-yb1-xb2c.google.com with SMTP id c124so2919378ybb.13 for ; Thu, 22 Dec 2022 10:33:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.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=zgQ7/HyilgHg8E9BFXKxaOdfSKQizyd/42UYLpvYwXY=; b=akTL9yqyIFNp2iIdYC5PHjy1YAfRW8nyNonh70NkM4bBKC//4ZKCq79oMjnCyxbV81 /f/Nv5leA8JsALRPdLmEMfJSXWnmNpcTV13z6/uuL2FA9sV4xdAHaZm+DzpU70B0Ixr0 9Sw8vzCkbUkP67qYDZWggLZaFfxFHWb29qIQvLEFgFikoebkwD361mEm4w7Lmxd+Y5t7 MoOYEFFupGShcUBqgcinQh24tGXDBO83w/1okjXT3TaHogM28l5ybGPaqo308v8xtahZ He2nNbOvJ59l5V8j1EMraisF9SNuvMBeUoJPyTRtgOPVStoJzDtyL7HPIfTPHi8EywXS 6YdA== 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=zgQ7/HyilgHg8E9BFXKxaOdfSKQizyd/42UYLpvYwXY=; b=VNFKR9Ku10oeq6uK5NDapN1h1oBmb7dSmgVQM5tTkgvKnP12qTkSyEpWxRO1/7DpXO LhiSN680WhKIwynggxsFHkUpJ767zkSFURxplzZqfX69FDFRB3/wmUeY+RWvXCWq9xJE HeoczRXxf+lLq9HugpIR5feoJcsIghRs7KOkaPt5wVDi7QCGb/tIZ3YjExWyubbvpOXE d1YHW0rK3fsXn9IRtiR+hiZpTAuZ2+KCHSh1SaqeDPH/iZnqE9MyvMvnRKLAYZEvj3Am pWRtEU3FsXe219357+Z5jzhbcWB50xfu+1nhWMmluw45mbEsMmPBprZ8yMZqmmQfT8Jt cbwA== X-Gm-Message-State: AFqh2krJMo3Agu0xvpM6oNB5DA0A85yJd/prJFgWNAEa8WpZmpQ7GWYI 7whRJ28YP6yntR70V34HC9RhtjjnhJOu984vjI2rVA== X-Google-Smtp-Source: AMrXdXsm02GTbuCyR6H9SG5ET6+z6HWVhYCUwJqYxCLfh0jMinpWaZPXbEzYeEB0Bn1IXhJn8zqveBqV0oWjihdfq5E= X-Received: by 2002:a25:9744:0:b0:71f:d74e:f3f with SMTP id h4-20020a259744000000b0071fd74e0f3fmr798816ybo.75.1671734017626; Thu, 22 Dec 2022 10:33:37 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: From: Andy Chiu Date: Fri, 23 Dec 2022 02:33:26 +0800 Message-ID: Subject: 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 , 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 Content-Type: text/plain; charset="UTF-8" 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" 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.