From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 73277C4332F for ; Fri, 18 Nov 2022 00:05:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240298AbiKRAF4 (ORCPT ); Thu, 17 Nov 2022 19:05:56 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57850 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233270AbiKRAFx (ORCPT ); Thu, 17 Nov 2022 19:05:53 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8F22464E6 for ; Thu, 17 Nov 2022 16:05:52 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 2C19A622CF for ; Fri, 18 Nov 2022 00:05:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8B024C433D6; Fri, 18 Nov 2022 00:05:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1668729951; bh=tYQUaSeM09G8F/KzzGAMNswn3nId+Hxj+RHsrWZ9f0A=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=jrYH7HuB76vnRlY7+uz69JGm5/4wdgIvOWbv+8o+W5iLyaW01URoSblLNWZtNItyj ymFHl8V2O1OClNyEQLKx/p9lY3N+e4auM48aQljxDihnHjnigV88/HG/u1opC0Um7B j8GQ7IJVRkJattMFktFfTSqSV5kIM13rqNGtL5gZryhLa0HbGjybfLFh+xmwPuExRN u4sVSZySWRmWWxqTqv4VjYhM5HItgPPdG2phuvsSJzwZMrQyj6PvsWdNGpL4w9ExsX Vv553aFwn87kf862sD4lWti2I2ah9uvmfY1dSlb5TgWTW+EUGcLmBga7lqL1By0SqR oi9h31cIzChrA== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1ovotB-006rey-4q; Fri, 18 Nov 2022 00:05:49 +0000 Date: Fri, 18 Nov 2022 00:05:48 +0000 Message-ID: <86sfihnn37.wl-maz@kernel.org> From: Marc Zyngier To: Sean Christopherson Cc: Paolo Bonzini , Oliver Upton , Reiji Watanabe , kvm@vger.kernel.org, Colin Ian King , Colton Lewis , David Matlack , Vipin Sharma , Gautam Menghani , Peter Gonda , Vishal Annapurve Subject: Re: [GIT PULL] KVM: selftests: Early pile of updates for 6.2 In-Reply-To: References: <861qq1ptew.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: seanjc@google.com, pbonzini@redhat.com, oliver.upton@linux.dev, reijiw@google.com, kvm@vger.kernel.org, colin.i.king@gmail.com, coltonlewis@google.com, dmatlack@google.com, vipinsh@google.com, gautammenghani201@gmail.com, pgonda@google.com, vannapurve@google.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Thu, 17 Nov 2022 23:49:40 +0000, Sean Christopherson wrote: > > On Thu, Nov 17, 2022, Marc Zyngier wrote: > > On Thu, 17 Nov 2022 01:10:33 +0000, > > Sean Christopherson 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 > #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.