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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9CA7FC433EF for ; Sat, 16 Apr 2022 16:05:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ofeayWwjgAioBalA0sx9i9DHZcyJjrBMIUAGF3ehAcI=; b=lFsmW8FBhYqoYI 8F+LAMbyebItvU/LNm+IHriXX0C7VMKOmlxgZvEUSdodRx2XlXQFLeSsWJz0eRjjAg8pC2Y5OM8tm Iazwz88e59ugH4FmbGYHF0HArf1WPq9ai657lLiAKB1bb9v+fls+H6z+7P2vmmTzqZ0/mi3fjoLdg dNYHAgJX8P8s+2e/+Vu/B41/OZK/TekygjqUu9jJItcFXXIrhr9M6Kpi3oqCnz/7Rm6gncicd7MOp fObS8XCPiH4zQINkrQqKJx0DKiO5ecmCkIYkM9+fXpFD68l1ywNvPcFmwXN5NqHzk0AdoybrAiqnd OkhgvFsIiR2ZuLISpTvA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nfktW-00DDN1-Dv; Sat, 16 Apr 2022 16:03:30 +0000 Received: from mail-il1-x129.google.com ([2607:f8b0:4864:20::129]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nfktT-00DDMX-9o for linux-arm-kernel@lists.infradead.org; Sat, 16 Apr 2022 16:03:28 +0000 Received: by mail-il1-x129.google.com with SMTP id t4so6303325ilo.12 for ; Sat, 16 Apr 2022 09:03:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=wEt9N3Zhz4Vmmb7sqXNK/pWIreJjgm6LVz0beu10MRM=; b=NvYgpTXq2m6azGeR9w4P/7TL4sXEY6B7fIf4UDvIRkvKtw0JIK1J+IidxSzbdFxSy5 q1mdOSugjRgbVCfiBlDGhlZwCYA1ffXlpS5AX4ZIweRQ1aQo3q64medWVQ/vYBEJjcvN DAqBX4epYgzd3f6LmhN5uzmuf2GfSB0KVh73/FepfptUrNHen2fvG68RcYzMw6JzV99b yLY1W0wifkrv/2/Ob38mT18umNWV5beggdvvctMKrLs4VfKdb6qU6azx3WXFFG8XT2GK uEm13V9Gc0CDOO52seiIEPeqUFpstU6G8/dRys8h5EWZA/RUBcr+z6MZdWmXDh63T8mb ccZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=wEt9N3Zhz4Vmmb7sqXNK/pWIreJjgm6LVz0beu10MRM=; b=cJ/7+3x2xQwUEUylfg5n7hOIhOELfrI9Itw/SHBbjxMObNnfmXapQrZ4Os0kVGfUgd ZUx+hQNf+UsHKa/wJHZOnlFiQfnu/hbu+nOq4x8d+tV7nuYGlc3FtGcAaWHcQoNxEfb6 0n2sDWzKa/SxhdPwKWEVSanOubtidyz7dye0zyRSk5Cc7gps8hwKIyCgQ70JieTgXtyX AmbvpciEvPQiBggusviA/kriuOc63je+lPs1JmRr7B+wGxFxcxSW9I2p7z2ZJnlx6aCG gYLjqdUqXRR4ngZwaG0WvhRwTYDKKLX/s5S9ZO6c+LYZv1aoPWPVJ/oDXfBSQVprAFfg mwwg== X-Gm-Message-State: AOAM531b3I7i59st0PgzFvrdxmVuDX/q2A0h5oaIrkH+fb5EcZMgcK4J 0cS+NlaC0IV3nfVXrFTDKCyYBw== X-Google-Smtp-Source: ABdhPJyyOEmzYK0FQivDQe0O5g3cZHm6nQaURPCa+AA+WKAFPTZsK7uW8SAGhg3mYpfM2B8pgGhfRQ== X-Received: by 2002:a92:d7d0:0:b0:2ca:33ba:8bde with SMTP id g16-20020a92d7d0000000b002ca33ba8bdemr1596697ilq.121.1650125004003; Sat, 16 Apr 2022 09:03:24 -0700 (PDT) Received: from google.com (194.225.68.34.bc.googleusercontent.com. [34.68.225.194]) by smtp.gmail.com with ESMTPSA id k6-20020a6b4006000000b00649d7111ebasm4865516ioa.0.2022.04.16.09.03.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 16 Apr 2022 09:03:21 -0700 (PDT) Date: Sat, 16 Apr 2022 16:03:09 +0000 From: Oliver Upton To: Marc Zyngier Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, James Morse , Alexandru Elisei , Suzuki K Poulose , linux-arm-kernel@lists.infradead.org, Peter Shier , Ricardo Koller , Reiji Watanabe , Paolo Bonzini , Sean Christopherson , Ben Gardon , David Matlack Subject: Re: [RFC PATCH 05/17] KVM: arm64: Take an argument to indicate parallel walk Message-ID: References: <20220415215901.1737897-1-oupton@google.com> <20220415215901.1737897-6-oupton@google.com> <871qxxb700.wl-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <871qxxb700.wl-maz@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220416_090327_400964_6B07647B X-CRM114-Status: GOOD ( 26.40 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sat, Apr 16, 2022 at 12:30:23PM +0100, Marc Zyngier wrote: > Hi Oliver, > > On Fri, 15 Apr 2022 22:58:49 +0100, > Oliver Upton wrote: > > > > It is desirable to reuse the same page walkers for serial and parallel > > faults. Take an argument to kvm_pgtable_walk() (and throughout) to > > indicate whether or not a walk might happen in parallel with another. > > > > No functional change intended. > > > > Signed-off-by: Oliver Upton > > --- > > arch/arm64/include/asm/kvm_pgtable.h | 5 +- > > arch/arm64/kvm/hyp/nvhe/mem_protect.c | 4 +- > > arch/arm64/kvm/hyp/nvhe/setup.c | 4 +- > > arch/arm64/kvm/hyp/pgtable.c | 91 ++++++++++++++------------- > > 4 files changed, 54 insertions(+), 50 deletions(-) > > > > diff --git a/arch/arm64/include/asm/kvm_pgtable.h b/arch/arm64/include/asm/kvm_pgtable.h > > index ea818a5f7408..74955aba5918 100644 > > --- a/arch/arm64/include/asm/kvm_pgtable.h > > +++ b/arch/arm64/include/asm/kvm_pgtable.h > > @@ -194,7 +194,7 @@ enum kvm_pgtable_walk_flags { > > typedef int (*kvm_pgtable_visitor_fn_t)(u64 addr, u64 end, u32 level, > > kvm_pte_t *ptep, kvm_pte_t *old, > > enum kvm_pgtable_walk_flags flag, > > - void * const arg); > > + void * const arg, bool shared); > > Am I the only one who find this really ugly? Sprinkling this all over > the shop makes the code rather unreadable. It seems to me that having > some sort of more general context would make more sense. You certainly are not. This is a bit sloppy, a previous spin of this needed to know about parallelism in the generic page walker context and I had picked just poking the bool through instead of hitching it to kvm_pgtable_walker. I needed to churn either way in that scheme, but that is no longer the case now. > For example, I would fully expect the walk context to tell us whether > this walker is willing to share its walk. Add a predicate to that, > which would conveniently expand to 'false' for contexts where we don't > have RCU (such as the pKVM HYP PT management, and you should get > something that is more manageable. I think the blast radius is now limited to just the stage2 visitors, so it can probably get crammed in the callback arg now. Limiting the changes to stage2 was intentional. The hyp walkers seem to be working fine and I'd rather not come under fire for breaking it somehow ;) -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel