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=-4.2 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.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 484A11F852 for ; Thu, 22 Dec 2022 19:25:47 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (2048-bit key; unprotected) header.d=rivosinc-com.20210112.gappssmtp.com header.i=@rivosinc-com.20210112.gappssmtp.com header.b="1dmu3WGo"; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A7A3B3858005 for ; Thu, 22 Dec 2022 19:25:43 +0000 (GMT) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) by sourceware.org (Postfix) with ESMTPS id 6324A3858284 for ; Thu, 22 Dec 2022 19:25:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6324A3858284 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-pg1-x532.google.com with SMTP id e190so1940646pgc.9 for ; Thu, 22 Dec 2022 11:25:30 -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=yB1NUsw2OOJ4s3GRJv7W/3p4cooq8aSsPXXdqNZx6es=; b=1dmu3WGoywCgc5sYxKABgoHOXmBMuPHQahfpt9Fljbpx4HgGDNdC3hGqKGyjRaphUg 3AnBcrTOhQvHOvLzbhbja2QdkWMwutzxqB7p0WaUxQwgiLF1onfoqA+pjIdDeFMED/+O /iVl2BSWR1yyFm8LyOX2VGRlOio+c+80o8fZcZdskwwW+8w1JJNRDjJHI1lnLKbiC5tz ymEajIK3HnTkNizq3odPVZG/esGVStDCH+EJ/h0qoMZ9pBYIv0lM35OPT9GFui+rbb68 l99/0EkdEDL+bRQTWdfOIm1CS/H6lei0k5MRGWHGXd62xjHRSoWemBtm+hPqH0lOFFxK JfVg== 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=yB1NUsw2OOJ4s3GRJv7W/3p4cooq8aSsPXXdqNZx6es=; b=QzV5PJ8jxAez6xVvZ5iQtrl3JrIhnyxwVZxmwQzqafOZrLHGXYiOCWCIBLACBQJ/MQ YA8vOZFzbwAYKzgzCgZ0qPqLSWg007CDOUd6BdVERJpes4P4UNVe5l7kPkWXGV9AtUnS m6qSeJh/aBf08/N8gioDD1wJDa7xxO//5AQR4rrjs1rx/Ft5+J/YABDolQDwbzo5qfLB 8eFWbCTIJSfariSrZsLbyLHN6qMvoEfvIwdoej3FPcO+q8Rrpy6dFXWPGVBdchl7kCgI 4LuxPoo9L+2t0gyOedQjQxOP0RKqK7CqGjsRhV8lqhHcfOzUU1QtfENb8A51XW/5hmbF aVvg== X-Gm-Message-State: AFqh2koWKdn+QwWp/PAMWA/HZa7KZfehWqd2ORSwxJ1CnXdM/jqGymAA OzDxgejuuCFVcYqTmqpI0gtJUw== X-Google-Smtp-Source: AMrXdXtX5V7Oq9wn6JDLeEAucZK85QgVp0t+7h4EAEv5jPpf6Gn5QiD+MfydfVUOvj89yq52ZIcU+A== X-Received: by 2002:aa7:9631:0:b0:57a:9a7f:7896 with SMTP id r17-20020aa79631000000b0057a9a7f7896mr22083241pfg.28.1671737129334; Thu, 22 Dec 2022 11:25:29 -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 w192-20020a6282c9000000b00575448ab0e9sm1048356pfd.123.2022.12.22.11.25.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Dec 2022 11:25:28 -0800 (PST) Message-ID: Date: Thu, 22 Dec 2022 11:25:26 -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: Vincent Chen Cc: 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 , Andy Chiu , 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-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 12/21/22 19:37, Vincent Chen wrote: > On Thu, Dec 22, 2022 at 3:52 AM Vineet Gupta wrote: >> >> >> On 12/21/22 11:45, Vineet Gupta wrote: >>> 4. Kernel with RVV support + user program using original Glibc sigcontext >>> In this case, the kernel needs to save vector registers context to >>> memory. The user program may encounter memory issues if the user space >>> does not reserve enough memory size for the kernel to create the >>> sigcontext. However, we can't seem to avoid this case since there is >>> no flexible memory area in struct sigcontext for future expansion. >> This is not an issue, if we don't change sigcontext (in kernel and >> glibc) - it is essentially the case of existing binaries. >> kernel still saves regs on user stack, in rt_sigframe, its just that >> userspace is not able to access them in SA_SIGINFO signal handers. >> aarch64 have this implemented this approach and it is likely they can't >> do that either for SVE regs. > Sorry, I don't clearly describe the case. As you mentioned, the kernel > will save the vector registers to the user stack or user-specified > memory region by struct rt_sigframe in your patch. But, if there is an > existing binary compiled with the original sigcontext.h, it will > assume that the kernel only occupies the sizeof(struct sigcontext) to > save these registers. It will not aware the RVV extension is supported > and not expect that the kernel with RVV support needs an extra huge > memory region on its stack or specified memory region to save vector > registers context. In this case, the user program will encounter > memory corruption issues if the size of the memory region specified by > the user program is not enough to store these vector registers' > context. No, it will not. In this scheme struct sigcontext remains same as before. Kernel is copying the RVV context not in sigcontext, but beyond the canonical sigcontext, in layout specified in the rt_sigframe. Please take a look at my patch again. It works. Again I don't care what scheme we follow, I just want o make forward progress. -Vineet