From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id A3FC43846402 for ; Mon, 18 Jan 2021 11:17:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A3FC43846402 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-425-HJG2OEglOfCFdvgvzek4Qg-1; Mon, 18 Jan 2021 06:17:15 -0500 X-MC-Unique: HJG2OEglOfCFdvgvzek4Qg-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 7036D800D53; Mon, 18 Jan 2021 11:17:14 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-112-110.ams2.redhat.com [10.36.112.110]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 61F7960C67; Mon, 18 Jan 2021 11:17:13 +0000 (UTC) From: Florian Weimer To: "H.J. Lu via Libc-alpha" Subject: Re: V6 [PATCH 1/2] x86: Support GNU_PROPERTY_X86_ISA_1_V[234] marker [BZ #26717] References: <20201206144952.2109594-1-hjl.tools@gmail.com> <20201206144952.2109594-2-hjl.tools@gmail.com> <83ab601d-adbe-6d26-8d9c-235d52503171@linaro.org> Date: Mon, 18 Jan 2021 12:17:09 +0100 In-Reply-To: (H. J. Lu via Libc-alpha's message of "Thu, 7 Jan 2021 12:58:27 -0800") Message-ID: <87im7uqytm.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (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; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, LIKELY_SPAM_BODY, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no 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, 18 Jan 2021 11:17:21 -0000 * H. J. Lu via Libc-alpha: > +static void > +dl_isa_level_check (struct link_map *m, const char *program) > +{ > + const struct cpu_features *cpu_features =3D __get_cpu_features (); > + unsigned int i; > + struct link_map *l; > + > + i =3D m->l_searchlist.r_nlist; > + while (i-- > 0) > + { > + /* Check each shared object to see if ISA level is compatible. */ > + l =3D m->l_initfini[i]; > + > + /* Skip ISA level check if functions have been executed. */ > + if (l->l_init_called) > +=09continue; > + > +#ifdef SHARED > + /* Skip ISA level check for ld.so since ld.so won't run if its ISA > +=09 level is higher than CPU. */ > + if (l =3D=3D &GL(dl_rtld_map) || l->l_real =3D=3D &GL(dl_rtld_map)= ) > +=09continue; > +#endif > + > + if ((l->l_x86_isa_1_needed & cpu_features->isa_1) > +=09 !=3D l->l_x86_isa_1_needed) > +=09{ > +=09 if (program) > +=09 _dl_fatal_printf ("%s: CPU ISA level is lower than required\n", > +=09=09=09 *l->l_name !=3D '\0' ? l->l_name : program); > +=09 else > +=09 _dl_signal_error (0, l->l_name, "dlopen", > +=09=09=09 N_("CPU ISA level is lower than required")); > +=09} > + } > +} We may have hit an integration issue with this check. It turns out that libvirt defaults to the qemu64 model. It masks most of the feature bits required by x86-64-v2. Libvirt developers have previously told me that nothing should be using the qemu64 model, but it's still the default for API stability reasons (in the same way SSL 3 and DES used to be the default in crypto libraries, under the assumption that if you negotiatied a particular protocol and set of algorithms in 1998, you'd still want the exact same choice fifteen years later). But of course, despite no one should be using the qemu64 model, they still do. Here's an example: Guest: fix to always use host-passthrough CPU for all arches One pecularity about x86-64-v2 is that under KVM virtualization, the new structions added over the baseline do not actually trap (assuming the host supports them). So we could paper over this integration issue by doing the check for x86-64-v3 and later only. (Although it might not work there=E2=80=94I looked at printing a nice error message for the same situation when we transitioned to z13, but it it turned to be quite difficult.) Downstream, this would likely buy us about three years, in which we could fix qemu64-type problems. But maybe we should tackle this now. I also hope to have a conversation about the libvirt developers regarding defaults, but I'm still trying to figure out the appropriate forum. Thanks, Florian --=20 Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'N= eill