On Mon, Oct 23, 2023 at 8:19 AM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > On Mon, Oct 23, 2023, Gerrit Slomma wrote: > > Compilation with "gcc -mavx -i avx2 avx2.c" fails, due to used intrinsics > > are AVX2-intrinsics. > > When compiled with "gcc -mavx2 -o avx2 avx2.c" an run on a E7-4880v2 this > > yields "illegal instruction". > > When run on a KVM-virtualized "Sandy Bridge"-CPU, but the underlying CPU is > > capable of AVX2 (i.e. Haswell or Skylake) this runs, despite advertised flag > > is only avx: > > This is expected. Many AVX instructions have virtualization holes, i.e. hardware > doesn't provide controls that allow the hypervisor (KVM) to precisely disable (or > intercept) specific sets of AVX instructions. The virtualization holes are "safe" > because the instructions don't grant access to novel CPU state, just new ways of > manipulating existing state. E.g. AVX2 instructions operate on existing AVX state > (YMM registers). > > AVX512 on the other hand does introduce new state (ZMM registers) and so hardware > provides a control (XCR0.AVX512) that KVM can use to prevent the guest from > accessing the new state. > > In other words, a misbehaving guest that ignores CPUID can hose itself, e.g. if > the VM gets live migrated to a host that _doesn't_ natively support AVX2, then > the workload will suddenly start getting #UDs. But the integrity of the host and > the VM's state is not in danger. One could argue that trying to virtualize a Sandy Bridge CPU on Haswell hardware is simply user error, since the virtualization hardware doesn't support that masquerade.
