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

[Florian Weimer <fweimer@redhat.com>]

* 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.

Thanks,
Florian

-- 
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'Neill