From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) by sourceware.org (Postfix) with ESMTP id 410D0388F06B for ; Mon, 29 Jun 2020 16:14:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 410D0388F06B Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-222-NW6c8G5UOra-8PUDV6KD2Q-1; Mon, 29 Jun 2020 12:13:57 -0400 X-MC-Unique: NW6c8G5UOra-8PUDV6KD2Q-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 1B64D80BE32; Mon, 29 Jun 2020 16:13:56 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-112-196.ams2.redhat.com [10.36.112.196]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 471A660BF3; Mon, 29 Jun 2020 16:13:55 +0000 (UTC) From: Florian Weimer To: "H.J. Lu via Libc-alpha" Subject: Re: V6: [PATCH] x86: Install [BZ #26124] References: <87ftamg7ez.fsf@oldenburg2.str.redhat.com> <87a70ug5v8.fsf@oldenburg2.str.redhat.com> <871rm4bkj6.fsf@oldenburg2.str.redhat.com> <697cab8a-2d75-ef36-9e09-dbfe6daa4ae1@linaro.org> <87a70r8urd.fsf@oldenburg2.str.redhat.com> <20200625123059.GA1169557@gmail.com> <20200625132023.GA1223726@gmail.com> Date: Mon, 29 Jun 2020 18:13:53 +0200 In-Reply-To: <20200625132023.GA1223726@gmail.com> (H. J. Lu via Libc-alpha's message of "Thu, 25 Jun 2020 06:20:23 -0700") Message-ID: <871rlxx326.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-7.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: , X-List-Received-Date: Mon, 29 Jun 2020 16:14:02 -0000 * H. J. Lu via Libc-alpha: > Small update: > > const struct cpu_features * > __x86_get_cpu_features (unsigned int max, int cpuid) > { > if (cpuid) > { > if (max > COMMON_CPUID_INDEX_MAX) > return NULL; > } > else if (max > USABLE_FEATURE_INDEX_MAX) > return NULL; > return &GLRO(dl_x86_cpu_features); > } > > Don't return NULL when checking the cpuid array when COMMON_CPUID_INDEX_MAX > is unchanged, but USABLE_FEATURE_INDEX_MAX is changed. I think these changes address the fundamental technical issues, thanks. The patch needs to be rebased on top of 4fdd4d41a17dda26c854ed935658154a17d4b906 ("x86: Detect Intel Advanced Matrix Extensions"). One thing I still dislike (sorry) is the asymmetry between the usable and feature checks. For example, why is there are usability check for VAES, but not for AES? I believe the reason is that VAES depends on AVX/AVX2, but AES only depends on SSE2. But even that suggests to me that for 32-bit, there should be a usable gate for that (which is false if SSE2 support has been masked). I think it would be more consistent to expose the usable/feature distinction for all features, and carry that over to the internal ABI, too. This way, we can give accurate reporting in cases where the usability turned out to be firmware-dependent in the end (as it happened with RDRAND). That would need additional feature-specific work; by default, we would still report such features as unsupported at the CPU level. Having both bits exposed in all cases also protects us against cases where we need to change the usability detection logic in a later release. There is a bit of a tension here regarding agility because new usable bits will only become set after glibc update. But I don't see a way to avoid this, not without teaching programmers to bypass the usable checks (which leads to bugs, of course). The interface with the max and cpuid arguments is quite close to the one I proposed further up-thread. I still think it has quite a few advantages. Should I implement it? I could have something by the end of the week, so we should still be able to make the ABI freeze. Thanks, Florian