Re: strange SIGILL (under Xen)

[Greg Troxel <gdt%lexort.com@localhost>]

Greg Troxel <gdt%lexort.com@localhost> writes:

> gdb points at
>
> 431     extern __inline int
> 432     __attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
> 433     _mm256_movemask_epi8 (__m256i __A)
> 434     {
> 435       return __builtin_ia32_pmovmskb256 ((__v32qi)__A);
> 436     }

This is, as far as I can tell AVX2.  ccache seems to intend to check cpu
features, and my CPU indeed has AVX2.  (Alder Lake also originally had
AVX-512 on P cores only, not E cores, but now it just doesn't.)

Booting into GENERIC on bare metal, ccache works fine.

So it seems that in a PV dom0 and in a PV domU, AVX2 instructions fault.


I found at
https://xenbits.xen.org/docs/unstable/misc/xen-command-line.html

  1.2.179 spec-ctrl (x86)

  [snip]
  
  On all hardware, the gds-mit= option can be used to force or prevent
  Xen from mitigating the GDS (Gather Data Sampling) vulnerability. By
  default, Xen will mitigate GDS on hardware believed to be
  vulnerable. On hardware supporting GDS_CTRL (requires the August 2023
  microcode), and where firmware has elected not to lock the
  configuration, Xen will use GDS_CTRL to mitigate GDS with. Otherwise,
  Xen will mitigate by disabling AVX, which blocks the use of the AVX2
  Gather instructions.

but booting with that did not seem to help.