From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-x1130.google.com (mail-yw1-x1130.google.com [IPv6:2607:f8b0:4864:20::1130]) by sourceware.org (Postfix) with ESMTPS id 291913858D38 for ; Wed, 11 Jan 2023 12:13:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 291913858D38 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-yw1-x1130.google.com with SMTP id 00721157ae682-4d59d518505so23201997b3.1 for ; Wed, 11 Jan 2023 04:13:39 -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=2eLCnFo5WAOi1V93XjmE/yKkSvLN6YHbovMr6JQ0/io=; b=BQAgwaBZ3ujz1M2gINIXqsMMbT57HdlvYSPoaRS7+CaQie/jpgsX28QafhYktDCudS Fi+d506rGuaWT171VGRE4MpExUM1yutYvbMomncGvdeYhdmNpO2jjiwCtedc3Hbk+Bia A3A4eaUPPuHvJMc1mhvURmMNSwmotcKFFr7+75HX653tgFdpJsk9eFXtTP7hGyW2DA7a bEHHKfd62O5/EyeJf2LuTvFnBFxQ64ByB2VJjASOgiunOjRUf8mNbB6UND6rksUrhYRz YL7Z0WviW82vx5PLgwCAg+eTBaoWCJ/LjR4rQtx6iStHKgXSA3LWmaf7ecc8B2pTj0Fs bAoQ== 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=2eLCnFo5WAOi1V93XjmE/yKkSvLN6YHbovMr6JQ0/io=; b=DBgqby0uNrjNSfAVNZM+19OkInEZWZauZCh/KiL6RRuKtbsACElUCaIJ5hjo25EDUC qBVM9GIPixBjheJtS4/I6i7vKmJ7eg73n1qONmhH1eGwQszFuKC+0me9Gx791MWPyBS2 sQgu23H+jsh8aSqzI9WOpAPd36cF7Yyxc/S7cQTvgHhPN3PYuuxZfkr08tZu3nsSceHZ +lVBPVQayfh0FvqV2U7dbtG429IwARUC2xr0zW8Qqj7ZWsVMirPozpzPTkbO9CSvmp6m 2HGAKRS/Ov9UHVK/IxGPi6ZqFNAXqVn4fEUXtMoNYwYs/WisfyS/vX+xxyXn44DoreOU NhoQ== X-Gm-Message-State: AFqh2kpLmEGUoo9H1d6lRj9BpR2OKvJYb957onu4G1j0fdi6lk8SYloK LT6GqgF65eNnb3pV3ojTDcEo7zuIvSQsgIkbc6nftg== X-Google-Smtp-Source: AMrXdXu7Ut7WlNDMv4JZWKxWFnPjtR7Cq3lERI8kfLNmmkFvmFOq5USdq0TsOvVNyYk9lZvLEM/JEE8wBjCqm++4DPY= X-Received: by 2002:a81:5558:0:b0:4d5:6812:d8a7 with SMTP id j85-20020a815558000000b004d56812d8a7mr262076ywb.176.1673439218434; Wed, 11 Jan 2023 04:13:38 -0800 (PST) MIME-Version: 1.0 References: <1631497278-29829-1-git-send-email-vincent.chen@sifive.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> <119da65f-e976-f382-3fe1-1585be738352@ventanamicro.com> <8be4d673-f435-429e-9a61-bb49e7820529@linaro.org> <6d13e63f-69b3-6e48-b811-bbfcf3ffb3af@ventanamicro.com> In-Reply-To: From: Andy Chiu Date: Wed, 11 Jan 2023 20:13:27 +0800 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: Jeff Law Cc: Richard Henderson , Vineet Gupta , Kito Cheng , Philipp Tomsich , 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=-1.4 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 5:28 PM Andy Chiu wrote: > > On Wed, Jan 11, 2023 at 2:20 PM Jeff Law wrote: > > Fault on first use is well understood and has been implemented on many > > architectures through the decades, even with its warts. > > Unfortunately, we don't have a direct way of acknowledging if an > illegal instruction is caused by illegitimate use of V instructions. > Unlike ARM64, where reading ESR_EL1.EC is enough to distinguish the > fault, we may have to perform a sw decode on the faulting instruction. > Then see if it is the first-use fault, or a more general illegal > instruction fault. After taking more considerations, I think this could be minor. The first V-instruction of a valid program that uses Vector is limited to vset{i}vl{i}, vlr, or vsr. And perhaps some r/w of vector-specific CSRs. Decoding these instructions should be relatively constraint and easy. And we need this decoding only once for each process since we don't have to do lazy save/restore. > > Yes, we may just enable V for a process whenever we find an OP-V major > opcode, or a LOAD/STORE-FP with vector-encoded width on illegal > instruction. But it could be kind of messy, IF, later extensions would > also like to be enabled at first-use-fault. (e.g. ARM has SME followed > by SVE). And implementing this decoding logic in sw just seems > redundant to me because hw has already done that for us. Let's limit our discussion to the scope of VS enablement for now. > > Besides, ARM64 has individual mappings of traps for the use of > FP-related units in EL1 and EL0. So SIMD running in kernel mode would > not take additional instruction to enable the unit. I assume these > kinds of CSR-controlling instructions would have to flush hw internal > buffers to some extent. And doing these takes additional latencies. We already do some VS/FS settings on the entry of kernel code. So this should be minor as well. Anyway, I agree that faulting on first-uses is a better way to make per-process control of VS feasible. Sorry for disturbing the list. Thanks, Andy