On Fri, Oct 04, 2024, Vitaly Kuznetsov wrote: > Sean Christopherson <seanjc@xxxxxxxxxx> writes: > > > To play nice with compilers generating AVX instructions, set CR4.OSXSAVE > > and configure XCR0 by default when creating selftests vCPUs. Some distros > > have switched gcc to '-march=x86-64-v3' by default, and while it's hard to > > find a CPU which doesn't support AVX today, many KVM selftests fail with > > > > ==== Test Assertion Failure ==== > > lib/x86_64/processor.c:570: Unhandled exception in guest > > pid=72747 tid=72747 errno=4 - Interrupted system call > > Unhandled exception '0x6' at guest RIP '0x4104f7' > > > > due to selftests not enabling AVX by default for the guest. The failure > > is easy to reproduce elsewhere with: > > > > $ make clean && CFLAGS='-march=x86-64-v3' make -j && ./x86_64/kvm_pv_test > > > > E.g. gcc-13 with -march=x86-64-v3 compiles this chunk from selftests' > > kvm_fixup_exception(): > > > > regs->rip = regs->r11; > > regs->r9 = regs->vector; > > regs->r10 = regs->error_code; > > > > into this monstronsity (which is clever, but oof): > > > > 405313: c4 e1 f9 6e c8 vmovq %rax,%xmm1 > > 405318: 48 89 68 08 mov %rbp,0x8(%rax) > > 40531c: 48 89 e8 mov %rbp,%rax > > 40531f: c4 c3 f1 22 c4 01 vpinsrq $0x1,%r12,%xmm1,%xmm0 > > 405325: 49 89 6d 38 mov %rbp,0x38(%r13) > > 405329: c5 fa 7f 45 00 vmovdqu %xmm0,0x0(%rbp) > > > > Alternatively, KVM selftests could explicitly restrict the compiler to > > -march=x86-64-v2, but odds are very good that punting on AVX enabling will > > simply result in tests that "need" AVX doing their own thing, e.g. there > > are already three or so additional cleanups that can be done on top. > > Ideally, we may still want to precisely pin the set of instructions > which are used to generete guest code in selftests as the environment > where this code runs is defined by us and it may not match the host. I > can easily imaging future CPU features leading to similar issues in case > they require explicit enablement. Maybe. I suspect the cross-section of features that require explicit enablement *and* will be generated by the compiler for "regular" code will be limited to AVX and the like. E.g. the only new in -v4 is AVX512. > To achive this, we can probably separate guest code from each test into its > own compilation unit. Hopefully we don't need to worry about that for years and years :-)
