Re: [PATCH 05/11] KVM: selftests: Configure XCR0 to max supported value by default
From: Sean Christopherson
Date: Fri Oct 04 2024 - 09:35:41 EST
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 :-)