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 89CEAC4332F for ; Thu, 17 Nov 2022 14:06:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239679AbiKQOGW (ORCPT ); Thu, 17 Nov 2022 09:06:22 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42184 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234051AbiKQOGU (ORCPT ); Thu, 17 Nov 2022 09:06:20 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D79A71FFB7 for ; Thu, 17 Nov 2022 06:06:19 -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 71EBC61E1D for ; Thu, 17 Nov 2022 14:06:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BB02AC433C1; Thu, 17 Nov 2022 14:06:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1668693978; bh=kCS8Of28HB7CHeBVEnZW0E4IDz+/mMdpFVTWPQ6Q5T0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=L9VoBIhX3a4FgmFRxV5QpMBGnPOoZRn3o8bHVay6W/NByeVv26FlxFMlwouK3RN5J BdONYVhroF4OOtFeuBatZOGPsrA5KDVBK+7cgi+ZyKCE6tNLuNhKfBxiKPbUROvcBT NZrPNpg7ylDfI16sI6kMxlUye4fV0dgtKhO7kt630g6JBshf2gSxHrWZqYQNJ8vTgF SKtjUvb0l6UzN6+jEIInuVBG7bW4c8VYguQ85IADZ+ynEqUceQxnO4eKFqqSlzxnFh nmWqv3KcsJjfD/4skqzrBs3r2KPw4p2A44jHwEHtn7krcOXzEuKMhlwSWdiJQMnoNN HN6jo80Xc9RfQ== 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 1ovfWy-006jxa-Ge; Thu, 17 Nov 2022 14:06:16 +0000 Date: Thu, 17 Nov 2022 14:06:15 +0000 Message-ID: <861qq1ptew.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: 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 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. The tests seem to use the former, which cannot guarantee forward progress. Yes, this is utter crap. > 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? Thanks, M. -- Without deviation from the norm, progress is not possible.