From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc34.google.com (mail-oo1-xc34.google.com [IPv6:2607:f8b0:4864:20::c34]) by sourceware.org (Postfix) with ESMTPS id 5F45E386F47D for ; Mon, 18 Jan 2021 13:50:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5F45E386F47D Received: by mail-oo1-xc34.google.com with SMTP id o5so4099901oop.12 for ; Mon, 18 Jan 2021 05:50:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=alkdiID/kFr5QrgVBaSjYDq8c3Mc/AMoDia8AukLD6E=; b=efT9uGvGqnQmxxMgk3KbpeAnwdC0SHRv+8TlT/CbKrdLmfLQ3B9UcYxw3epda4Y3n7 EaujaqZ68B6mVO6XlTr0yCssVMeYLCQ5SFbJYFfQ9Tvk24lOSRaJddCbVkC/nS6+T1lp JK6Ome8pZrWSIsLcBCb2P0QeNB78iNF1afEG0yNBl65mxIpdz0jByuu89JZa6Vyz3hQr 82Xi2EuQcDTQfHb5BQImwv7f1V/VXs1ovvt3UmkCo18TAHn0pTVkHDfpMEiZ+71w27xf QOG0dMu4hc+gqf+kc0KyLcraHqpUJdy6vDBE1owXOaQhj4jXjHHn5Dl3+hxwmkxjyyWB FArQ== X-Gm-Message-State: AOAM533AhPMimkbvBxhdkLFYUgSxK0GcPJfH47sjwKa1h6m7b9fXLar6 nJZpD6fh6a261Ro/XfUZWc6B/GXkDu67S2SDACs= X-Google-Smtp-Source: ABdhPJzufFFxD2VFPqZ/aYKzRxHhdV8s/39vzs5dzFMlX4862uGt0EDqJLHyu9EvHTHF0aG71fwcfI0U1gwfGjPaN/I= X-Received: by 2002:a4a:1e42:: with SMTP id 63mr17206891ooq.57.1610977833830; Mon, 18 Jan 2021 05:50:33 -0800 (PST) MIME-Version: 1.0 References: <20201206144952.2109594-1-hjl.tools@gmail.com> <20201206144952.2109594-2-hjl.tools@gmail.com> <83ab601d-adbe-6d26-8d9c-235d52503171@linaro.org> <87im7uqytm.fsf@oldenburg.str.redhat.com> In-Reply-To: <87im7uqytm.fsf@oldenburg.str.redhat.com> From: "H.J. Lu" Date: Mon, 18 Jan 2021 05:49:57 -0800 Message-ID: Subject: Re: V6 [PATCH 1/2] x86: Support GNU_PROPERTY_X86_ISA_1_V[234] marker [BZ #26717] To: Florian Weimer Cc: "H.J. Lu via Libc-alpha" , Adhemerval Zanella Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3029.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, LIKELY_SPAM_BODY, RCVD_IN_DNSWL_NONE, 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 13:50:35 -0000 On Mon, Jan 18, 2021 at 3:17 AM Florian Weimer wrote: > > * 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) > > + continue; > > + > > +#ifdef SHARED > > + /* Skip ISA level check for ld.so since ld.so won't run if its I= SA > > + level is higher than CPU. */ > > + if (l =3D=3D &GL(dl_rtld_map) || l->l_real =3D=3D &GL(dl_rtld_ma= p)) > > + continue; > > +#endif > > + > > + if ((l->l_x86_isa_1_needed & cpu_features->isa_1) > > + !=3D l->l_x86_isa_1_needed) > > + { > > + if (program) > > + _dl_fatal_printf ("%s: CPU ISA level is lower than required\n= ", > > + *l->l_name !=3D '\0' ? l->l_name : program)= ; > > + else > > + _dl_signal_error (0, l->l_name, "dlopen", > > + N_("CPU ISA level is lower than required"))= ; > > + } > > + } > > +} > > 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. > If we are considering a possible glibc solution, can you open a glibc bug to track it? Thanks. --=20 H.J.