Re: [PATCH 05/11] KVM: selftests: Configure XCR0 to max supported value by default

[Sean Christopherson <seanjc@google.com>]

On Fri, Oct 04, 2024, Vitaly Kuznetsov wrote:
> Sean Christopherson <seanjc@google.com> 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 :-)