From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) by sourceware.org (Postfix) with ESMTPS id 21BB83858286 for ; Fri, 15 Jul 2022 01:00:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 21BB83858286 Received: by mail-pj1-x1033.google.com with SMTP id o15so4319965pjh.1 for ; Thu, 14 Jul 2022 18:00:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:subject:to:cc:references:in-reply-to :mime-version:message-id:content-transfer-encoding; bh=Kg46N3kmwcOLg4EzYlkWBNcVyLxfrVU220KO8UaaL84=; b=N2jPSd7Aj0vViZUE3gibgmJ5VeZmxyAvtWakyDArnmtolK+eilujLeBYGjfs0hG08J fUDxDe4G48O1PtmtxVY9Z6Cmurd8jCogkBd1+p4mRsz2Vl69p/1HhXcVk8xcHiHbQhKV eX10sjPbGPXgNzbPaMsfTSeXcLWEc7dkG+Rwz2ijkHNcHy4dGh9Yt6Wmv1y5gqQ00AJO f7zMwltfvCwqKm2w9nfVduit3Get3YDc7qro7wAdypW331AbEnqVDe4+PeCd4QwjGr7X A5okDLr0cUxBoO/2Jbuq3ZJSVEj+ldN/KvoMM4dfPZIdwcFKenfNFyeZCD+EHcel4HK0 f0sg== X-Gm-Message-State: AJIora9aEk/g4IWKQJT3Uvx047OCKOcYksS6LWTiCdpn3VcBZXmpxFEp dx4pVGV63I73e7BiaCQh3r0= X-Google-Smtp-Source: AGRyM1vLDkZcNf2vhjFAHeoowKsrRchKAA21wNj+h/XwZFTKCNFTJ4uvruc5zfSNiPt7ixPUKASMUw== X-Received: by 2002:a17:90b:3c0c:b0:1ef:e647:ff48 with SMTP id pb12-20020a17090b3c0c00b001efe647ff48mr18744193pjb.173.1657846855140; Thu, 14 Jul 2022 18:00:55 -0700 (PDT) Received: from localhost (61-68-63-70.tpgi.com.au. [61.68.63.70]) by smtp.gmail.com with ESMTPSA id u12-20020a17090a400c00b001ef7eb39be1sm2099619pjc.55.2022.07.14.18.00.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Jul 2022 18:00:54 -0700 (PDT) Date: Fri, 15 Jul 2022 11:00:48 +1000 From: Nicholas Piggin Subject: Re: [PATCH Linux] powerpc: add documentation for HWCAPs To: Segher Boessenkool Cc: Peter Bergner , gcc@gcc.gnu.org, libc-alpha@sourceware.org, linuxppc-dev@lists.ozlabs.org, Michael Ellerman , Paul E Murphy References: <20220524093828.505575-1-npiggin@gmail.com> <20220524173814.GH25951@gate.crashing.org> In-Reply-To: <20220524173814.GH25951@gate.crashing.org> MIME-Version: 1.0 Message-Id: <1657845835.tt8ymcybhd.astroid@bobo.none> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=0.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2022 01:00:57 -0000 Finally got some details about the icache snoop question so just coming=20 back to this now, sorry for the delay... (POWER10 does support the=20 coherent icache flush sequence as expected, there was some updates to the UM wording but that will be fixed). Excerpts from Segher Boessenkool's message of May 25, 2022 3:38 am: > Hi! >=20 > On Tue, May 24, 2022 at 07:38:28PM +1000, Nicholas Piggin wrote: >> Thanks for all the comments and corrections. It should be nearing the >> point where it is useful now. Yes I do think it would be useful to align >> this more with OpenPOWER docs (and possibly eventually move it into the >> ABI, given that's the allocator of these numbers) but that's not >> done yet. >=20 > The auxiliary vector is a Linux/glibc thing, it should not be described > in more generic ABI documents. It is fine where you have it now afaics. It is already in the ABI document. In fact that (not the kernel) had been the allocator of the feature numbers, at least in the past I think. >=20 >> +Where software relies on a feature described by a HWCAP, it should chec= k the >> +relevant HWCAP flag to verify that the feature is present before attemp= ting to >> +make use of the feature. >> + >> +Features should not be probed through other means. When a feature is no= t >> +available, attempting to use it may result in unpredictable behaviour, = and >> +may not be guaranteed to result in any reliable indication that the fea= ture >> +is unavailable. >=20 > Traditionally VMX was tested for by simply executing an instruction and > catching SIGILL. This is portable even. This has worked fine for over > two decades, it's a bit weird to declare this a forbidden practice > now :-) The statement does not override architectural specification, so if an encoding does not exist then it should cause a trap and SIGILL. I suppose in theory we could work around performance or correctness issues in an implementation by clearing HWCAP even if the hardware does=20 execute the instruction, so I would still say testing HWCAP is preferred. >=20 > It certainly isn't recommended for more complex and/or newer things. >=20 >> +verstions. >=20 > (typo. spellcheck maybe?) Thanks, Nick