On Thu, 17 Nov 2022 23:49:40 +0000, Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > 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. They are primitives to build atomic accessors, and the number of things you can do between the LL and the SC is pretty limited (see B2.9.5 in the I.a ARM ARM for the gory details). > > > 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. Given that we really don't need any sort of performance here, simply having a check (or an indirection) to discriminate between the two implementations would be enough. And we can then drop the GCC built-in stuff. M. -- Without deviation from the norm, progress is not possible.
