On Thu, Nov 17, 2022, Marc Zyngier wrote: > On Thu, 17 Nov 2022 01:10:33 +0000, > Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > > > Please pull a set of selftests updates for 6.2. Many of these changes are > > prep work for future selftests, e.g. for SEV and TDX, and/or have myriad > > conflicts, e.g. the former "perf util" code. I am hoping to get these > > changes queued up for 6.2 sooner than later so that the chain of dependent > > work doesn't get too long. > > > > Except for the ARM single-step changes[*], everything has been posted for > > quite some time and/or has gone through multiple rounds of review. > > > > The ARM single-step changes are a last minute fix to resolve a hilarious > > (IMO) collision between the pool-based ucall implementation and the > > recently added single-step test. Turns out that GCC will generate older > > flavors of atomics that rely on a monitor to detect conflicts, and that > > A quick nit, and to make things clear: there is no "older flavours of > atomics". These are exclusive accesses, and atomics are, well, > atomics. Heh, good to know even ARM doesn't consider them atomics. > The tests seem to use the former, which cannot guarantee forward progress. > Yes, this is utter crap. Ya, it's gcc-12's built-in "atomics" :-( > > monitor is cleared by eret. gdb is allegedly smart enough to skip over > > atomic sequences, but our selftest... not so much. > > I'm not sure how GDB performs this feat without completely messing > things up in some cases... > > But it brings another question. Shouldn't these tests actively use > atomics when on 8.1+ HW? tools/ doesn't exactly have robust arch-specific support, e.g. the x86 versus the world stuff is a big hack: #if defined(__i386__) || defined(__x86_64__) #include "../../arch/x86/include/asm/atomic.h" #else #include <asm-generic/atomic-gcc.h> #endif Patching in modern alternatives, especially in the guest code, would be quite rough. Oliver suggested trying "-march=armv8.1-a" to get gcc to use actual atomics, but that obviously requires knowing the target hardware.
