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 mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id D97BDC433F5 for ; Sat, 16 Apr 2022 16:03:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 406754A100; Sat, 16 Apr 2022 12:03:28 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@google.com Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFP1KA1Whf7c; Sat, 16 Apr 2022 12:03:27 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 01F7C4A4BE; Sat, 16 Apr 2022 12:03:27 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 35AEC4A100 for ; Sat, 16 Apr 2022 12:03:26 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOo92WybFAxM for ; Sat, 16 Apr 2022 12:03:24 -0400 (EDT) Received: from mail-il1-f181.google.com (mail-il1-f181.google.com [209.85.166.181]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id D62B64A0FE for ; Sat, 16 Apr 2022 12:03:24 -0400 (EDT) Received: by mail-il1-f181.google.com with SMTP id i8so1312196ila.5 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=Guw9Twj1Nn9IUyBsZW9CZxSSqlawJ1Ttlyerl6yvXABRnU2O1gyfYL0G4kutxtAMyQ UZZyYl02YmZFcXRRz6+5ml3c2mMZs4OZHgDacWugGAP5jatJkJ+SQCo4N7VVKu3MShNw iBaf3ngYbrV18CHQVw6oCMrRah3Sl95dGclof5f6qJyhLRcXUj7c27fED64y5XlMG0MY gyTtKulA0fvIBX+jKa0mSuRCX4j41GGbtqAWHUzjdwgDmUcU5aQr70p5eTBXKSqtoWZ4 gEz17M/k0kdgMQtI4j3C/Owp4FlDcpGe8c5gZ3sYIZ7saDpXr9a7PdRrjnG16yxAt0PA gitA== X-Gm-Message-State: AOAM532+majWerpCodcJ9j307dyWii0vL+gTU8cCfd0U/Rvrc9jH/L9E bZD3B88BmEFzf+qP0HysngRG5A== 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 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> Cc: kvm@vger.kernel.org, Peter Shier , Ben Gardon , David Matlack , Paolo Bonzini , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu 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 _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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 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 A2387C433EF for ; Sat, 16 Apr 2022 16:03:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232502AbiDPQGB (ORCPT ); Sat, 16 Apr 2022 12:06:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51626 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230108AbiDPQGA (ORCPT ); Sat, 16 Apr 2022 12:06:00 -0400 Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D8836EDF13 for ; Sat, 16 Apr 2022 09:03:24 -0700 (PDT) Received: by mail-il1-x12e.google.com with SMTP id r17so319624iln.9 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=hqhfeB1ys/MX8nW9A38kB65aKcpVesdp+wBp2eXMr2xzZWCczZPGhbQeMrXxvcFteM S7zHi1Riy3h5q/eyH+1kNSJdj/6RppSslEOe2snsoQoffkocKvT3iQMco/JA3QS/RuBI seE16sDKePor6mzyGCHtfEOTe7/8vHwsTx2pL2pMGgBZ+boNnsyy6/PDe0wDdkhMTZTX sTURM9TV85Ix/biy8ZiWg/c/F2mCr3kdlHd+RaJZ/Vm88hyLmhiUOUuMv775yCgSg3p5 Ozd9D4PyBJUp8zvCi6shY9EpGMZ9O8PljPGCg2wij8Ijbl+5+TP0oeQ8Kw0Ee+ZwmxGu rRYw== X-Gm-Message-State: AOAM532ppY3gQRgfoPFP45Yx5/f+0Q+HH/rybNdTlXNkwzEoNKXUBWqs 5w344nwYmVcvTzdozugx60acIA== 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-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <871qxxb700.wl-maz@kernel.org> Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.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