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 0C187C433FE for ; Thu, 10 Nov 2022 13:41:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230508AbiKJNlE (ORCPT ); Thu, 10 Nov 2022 08:41:04 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56258 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229916AbiKJNlC (ORCPT ); Thu, 10 Nov 2022 08:41:02 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 04451165A5 for ; Thu, 10 Nov 2022 05:40:55 -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 954E161759 for ; Thu, 10 Nov 2022 13:40:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E861FC433C1; Thu, 10 Nov 2022 13:40:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1668087654; bh=Uh+wsUnI7Md4CmgoSgZilMSyoJPGZ0sZeCob4b+9zvI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=j2qX8jezCMmmAUlPIOh3JkbewFuuKHVylCMMe9vaFnYdjVqFyw+yFKug5VD7w6LPX YQSF2HCAI3FdBwto8Rs6vW2ZPDT1H8p1c6vTgSB58rAauOusqIK45tLxUP2zCBDnk+ essciJC7FuMjHWWRHYMejtDrFs/NJphMIcYL3v8HhIU8/H/u9dNYXnLI5dAW7rWfGJ +VBrZm+6s47zelBALBAt/ca/mtT8zHIsHEEVTjDNar0xUs/CH6XP31bkGhzC7r6LY+ hLepqjVsrf58FJBnkaRFqm8ohVznTCtbLioIea0JzvYl6G+EpT5JXuXtnL23ml1u48 x4iSXoVwi3Lww== 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 1ot7nX-005AFs-Jq; Thu, 10 Nov 2022 13:40:51 +0000 Date: Thu, 10 Nov 2022 13:40:50 +0000 Message-ID: <86leojorkt.wl-maz@kernel.org> From: Marc Zyngier To: Ben Gardon Cc: Sean Christopherson , Oliver Upton , James Morse , Alexandru Elisei , linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Reiji Watanabe , Ricardo Koller , David Matlack , Quentin Perret , Gavin Shan , Peter Xu , Will Deacon , kvmarm@lists.linux.dev Subject: Re: [PATCH v5 09/14] KVM: arm64: Atomically update stage 2 leaf attributes in parallel walks In-Reply-To: References: <20221107215644.1895162-1-oliver.upton@linux.dev> <20221107215644.1895162-10-oliver.upton@linux.dev> 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: bgardon@google.com, seanjc@google.com, oliver.upton@linux.dev, james.morse@arm.com, alexandru.elisei@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, reijiw@google.com, ricarkol@google.com, dmatlack@google.com, qperret@google.com, gshan@redhat.com, peterx@redhat.com, will@kernel.org, kvmarm@lists.linux.dev 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 Wed, 09 Nov 2022 23:00:16 +0000, Ben Gardon wrote: > > On Wed, Nov 9, 2022 at 2:42 PM Sean Christopherson wrote: > > > > On Wed, Nov 09, 2022, Ben Gardon wrote: > > > On Mon, Nov 7, 2022 at 1:58 PM Oliver Upton wrote: > > > > @@ -1054,7 +1066,7 @@ kvm_pte_t kvm_pgtable_stage2_mkold(struct kvm_pgtable *pgt, u64 addr) > > > > bool kvm_pgtable_stage2_is_young(struct kvm_pgtable *pgt, u64 addr) > > > > { > > > > kvm_pte_t pte = 0; > > > > - stage2_update_leaf_attrs(pgt, addr, 1, 0, 0, &pte, NULL); > > > > + stage2_update_leaf_attrs(pgt, addr, 1, 0, 0, &pte, NULL, 0); > > > > > > Would be nice to have an enum for KVM_PGTABLE_WALK_EXCLUSIVE so this > > > doesn't just have to pass 0. > > > > That's also dangerous though since the param is a set of flags, not unique, > > arbitrary values. E.g. this won't do the expected thing > > > > if (flags & KVM_PGTABLE_WALK_EXCLUSIVE) > > > > I assume compilers would complain, but never say never when it comes to compilers :-) > > Yeah, I was thinking about that too. IMO using one enum for multiple > flags is kind of an abuse of the enum. If you're going to put multiple > orthogonal flags in an int or whatever, it would probably be best to > have separate enums for each flag. That way you can define masks to > extract the enum from the int and only compare with == and != as > opposed to using &. Too late. The kernel is filled of this (look at the irq code, for example), and we happily use this construct all over the (oh wait!) page table code to construct permissions and other things. At this stage, this is an established construct. Compiler people can try and break this habit, good luck to them ;-). M. -- Without deviation from the norm, progress is not possible.