From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-4.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (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 DFAB51F47C for ; Mon, 23 Jan 2023 12:18:58 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=GN9kKzWc; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B0B2E3858408 for ; Mon, 23 Jan 2023 12:18:54 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B0B2E3858408 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1674476334; bh=3zUQoPIQjdr5z56SbkIAZoVsvFdlOUGCvFn9K0j4mGI=; h=Date:To:CC:Subject:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=GN9kKzWcyFZN4KBvMfNfSA+vFFyWZozeXmpaumiJXYrF+MFZmzpaq1EkvChDtGosb xIQ65z8PyRJkpGs5rgJSFQGDHBU9yORDbBKj+/ldOSn7jqCb4cwB7uMY3VnffQ5260 iitl2cv4h8LnlOH9EGHwO2bvAom/GTgOJ3TJO+Io= Received: from esa.microchip.iphmx.com (esa.microchip.iphmx.com [68.232.154.123]) by sourceware.org (Postfix) with ESMTPS id 365CD3858D32 for ; Mon, 23 Jan 2023 12:18:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 365CD3858D32 X-IronPort-AV: E=Sophos;i="5.97,239,1669100400"; d="asc'?scan'208";a="133565461" Received: from unknown (HELO email.microchip.com) ([170.129.1.10]) by esa6.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 23 Jan 2023 05:18:14 -0700 Received: from chn-vm-ex01.mchp-main.com (10.10.85.143) by chn-vm-ex03.mchp-main.com (10.10.85.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.16; Mon, 23 Jan 2023 05:18:14 -0700 Received: from wendy (10.10.115.15) by chn-vm-ex01.mchp-main.com (10.10.85.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.16 via Frontend Transport; Mon, 23 Jan 2023 05:18:10 -0700 Date: Mon, 23 Jan 2023 12:17:47 +0000 To: Andy Chiu CC: Jeff Law , Richard Henderson , Vineet Gupta , Kito Cheng , Philipp Tomsich , Vincent Chen , Florian Weimer , Rich Felker , Andrew Waterman , Palmer Dabbelt , Christoph =?iso-8859-1?Q?M=FCllner?= , , Arnd Bergmann , =?iso-8859-1?Q?Bj=F6rn_T=F6pel?= , Szabolcs Nagy , Greentime Hu , Aaron Durbin , Andrew de los Reyes , linux-riscv , GNU C Library 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) Message-ID: References: <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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="/owN1yQB9D8Xo+wZ" Content-Disposition: inline In-Reply-To: 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: , From: Conor Dooley via Libc-alpha Reply-To: Conor Dooley Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" --/owN1yQB9D8Xo+wZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey Andy! On Wed, Jan 11, 2023 at 08:13:27PM +0800, Andy Chiu wrote: > 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. >=20 > 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. Meh, all of these discussions seem worthwhile to me! Now that things have died down though, I'm curious - what are your plans? Still going to submit another version of this series? Thanks, Conor. --/owN1yQB9D8Xo+wZ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCY8566wAKCRB4tDGHoIJi 0kEKAQC/ULqYyI7210QdsatFDvT5mYhk/k1CbaNyY4BaRchOmAEAl4mWEhaGyjF1 YPXTxh9JOrMeeiISlfanCp03GByC0Q8= =2LlJ -----END PGP SIGNATURE----- --/owN1yQB9D8Xo+wZ--