Why?
As Sean pointed out if you have older CPUs that don't support a specific
instruction set you need to restrict the capabilities in order to
support live migration.
"this is expected" is a bit far fetched, it is not expected but it is
observed and real behaviour.
I came across this when testing virtualized systems for performance with
the sllr-application from primegrid which only ran with SSE-code (plain
code flavour for me), not using AVX on a CPU that said to me via lscpu
it was a E5-2660v2.
(This was VMWare for that matter and i wrote the test app i posted and
tested in KVM-qemu-virtualized on other hosts).
Regards, Gerrit.
On 23.10.23 18:29, Jim Mattson wrote:
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.
