V6 [PATCH 1/2] x86: Support GNU_PROPERTY_X86_ISA_1_V[234] marker [BZ #26717]

[H.J. Lu]

On Mon, Jan 18, 2021 at 3:17 AM Florian Weimer <fweimer@redhat.com> 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 = __get_cpu_features ();
> > +  unsigned int i;
> > +  struct link_map *l;
> > +
> > +  i = m->l_searchlist.r_nlist;
> > +  while (i-- > 0)
> > +    {
> > +      /* Check each shared object to see if ISA level is compatible.  */
> > +      l = 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 ISA
> > +      level is higher than CPU.  */
> > +      if (l == &GL(dl_rtld_map) || l->l_real == &GL(dl_rtld_map))
> > +     continue;
> > +#endif
> > +
> > +      if ((l->l_x86_isa_1_needed & cpu_features->isa_1)
> > +       != l->l_x86_isa_1_needed)
> > +     {
> > +       if (program)
> > +         _dl_fatal_printf ("%s: CPU ISA level is lower than required\n",
> > +                           *l->l_name != '\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
>   <https://github.com/clalancette/oz/pull/283>
>
> 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—I 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.

-- 
H.J.