From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=microchip.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=microchip.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1674476313; x=1706012313; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=3zUQoPIQjdr5z56SbkIAZoVsvFdlOUGCvFn9K0j4mGI=; b=UFEOlM/gUI236IC3bxZcEJC3C3JWlTikdHq25kqjzu2TBSIs0WHy/haY WSxA94xBDXbGuHPkLAs1y3kpXztg1Iz8POF9/YUzOrJs26iHzU04eL2Dt +escLjStggUmuZbGIxaKS2hMx9B9zOrVIrkTPI5lAGp8jQoQrf8druSvo +rWpkCkquVVx7q/6EYmZLiy6fHlzML2TlBEmmOfatl+XhBv/R7use7G3W qJDAPq3XJ2zaXfqItLthcFxn9f4Rn5Dlc96SaWNCMHkEGcGKvX5xirAmt uh9YhvcvZ6e6EJvzymbzY2gaK4D/oYDjg+9dKMIY7bXf3uSfIBCRHhrTi g==; 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 From: Conor Dooley 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-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,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: --/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--