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 X-Spam-Level: X-Spam-Status: No, score=-17.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7C644C433E0 for ; Thu, 4 Mar 2021 20:02:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 58AA064F6F for ; Thu, 4 Mar 2021 20:02:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236830AbhCDUB4 (ORCPT ); Thu, 4 Mar 2021 15:01:56 -0500 Received: from mail.kernel.org ([198.145.29.99]:49988 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237503AbhCDUBb (ORCPT ); Thu, 4 Mar 2021 15:01:31 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 5010A64F65; Thu, 4 Mar 2021 20:00:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1614888051; bh=UH/6WrQiM34nfHG2XS5TT/G5/0kfI/kksSdM/0P/Kfg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=bYR6f8cxrOMRb34jioQTsd1SLiLYV1KrLhOxoa/UFlla225aOMoeU9KLwametgZGX e5UxygIrCjFHk727snrTlAC+zc1THCyYWXRHNW6bhw920Ttnj9NCS5X2Ih+o5ALWVK 8bzcdOJECfCuzr/vbSR1rZ8v1jVXMhWhNw+DbirPaQMEpoASd9ZqARx+ehcehxJknU SpENUYmOkDJnSdSwOWCMFlHYV9oxLgBfqvI9lx0K5oHBwfTbiME3Cs5py0GaxJAIlR biv8pRass1hSrt2fSlv8I3qPqJs7DpFaEMb2CjobCejwGpfx5/2Bf8XJ5QX/3hqHDq ZjtqlYWz2nibg== Date: Thu, 4 Mar 2021 20:00:45 +0000 From: Will Deacon To: Quentin Perret Cc: catalin.marinas@arm.com, maz@kernel.org, james.morse@arm.com, julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com, android-kvm@google.com, linux-kernel@vger.kernel.org, kernel-team@android.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, tabba@google.com, mark.rutland@arm.com, dbrazdil@google.com, mate.toth-pal@arm.com, seanjc@google.com, robh+dt@kernel.org Subject: Re: [PATCH v3 26/32] KVM: arm64: Introduce PROT_NONE mappings for stage 2 Message-ID: <20210304200044.GF21950@willie-the-truck> References: <20210302150002.3685113-1-qperret@google.com> <20210302150002.3685113-27-qperret@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210302150002.3685113-27-qperret@google.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 02, 2021 at 02:59:56PM +0000, Quentin Perret wrote: > Once we start unmapping portions of memory from the host stage 2 (such > as e.g. the hypervisor memory sections, or pages that belong to > protected guests), we will need a way to track page ownership. And > given that all mappings in the host stage 2 will be identity-mapped, we > can use the host stage 2 page-table itself as a simplistic rmap. > > As a first step towards this, introduce a new protection attribute > in the stage 2 page table code, called KVM_PGTABLE_PROT_NONE, which > allows to annotate portions of the IPA space as inaccessible. For > simplicity, PROT_NONE mappings are created as invalid mappings with a > software bit set. Just as an observation, but given that they're invalid we can use any bit from [63:2] to indicate that it's a PROT_NONE mapping, and that way we can keep the real "software bits" for live mappings. But we can of course change that later when we need the bit for something else. > > Signed-off-by: Quentin Perret > --- > arch/arm64/include/asm/kvm_pgtable.h | 2 ++ > arch/arm64/kvm/hyp/pgtable.c | 26 ++++++++++++++++++++++++-- > 2 files changed, 26 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/include/asm/kvm_pgtable.h b/arch/arm64/include/asm/kvm_pgtable.h > index 9935dbae2cc1..c9f6ed76e0ad 100644 > --- a/arch/arm64/include/asm/kvm_pgtable.h > +++ b/arch/arm64/include/asm/kvm_pgtable.h > @@ -80,6 +80,7 @@ struct kvm_pgtable { > * @KVM_PGTABLE_PROT_W: Write permission. > * @KVM_PGTABLE_PROT_R: Read permission. > * @KVM_PGTABLE_PROT_DEVICE: Device attributes. > + * @KVM_PGTABLE_PROT_NONE: No permission. > */ > enum kvm_pgtable_prot { > KVM_PGTABLE_PROT_X = BIT(0), > @@ -87,6 +88,7 @@ enum kvm_pgtable_prot { > KVM_PGTABLE_PROT_R = BIT(2), > > KVM_PGTABLE_PROT_DEVICE = BIT(3), > + KVM_PGTABLE_PROT_NONE = BIT(4), Why do we need an extra entry here? Couldn't we just create PROT_NONE entries when none of R,W or X are set? > }; > > #define PAGE_HYP (KVM_PGTABLE_PROT_R | KVM_PGTABLE_PROT_W) > diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c > index bdd6e3d4eeb6..8e7059fcfd40 100644 > --- a/arch/arm64/kvm/hyp/pgtable.c > +++ b/arch/arm64/kvm/hyp/pgtable.c > @@ -48,6 +48,8 @@ > KVM_PTE_LEAF_ATTR_LO_S2_S2AP_W | \ > KVM_PTE_LEAF_ATTR_HI_S2_XN) > > +#define KVM_PTE_LEAF_SW_BIT_PROT_NONE BIT(55) > + > struct kvm_pgtable_walk_data { > struct kvm_pgtable *pgt; > struct kvm_pgtable_walker *walker; > @@ -120,6 +122,16 @@ static bool kvm_pte_valid(kvm_pte_t pte) > return pte & KVM_PTE_VALID; > } > > +static bool kvm_pte_prot_none(kvm_pte_t pte) > +{ > + return pte & KVM_PTE_LEAF_SW_BIT_PROT_NONE; > +} I think it would be a good idea to check !kvm_pte_valid() in here too, since it doesn't make sense to report true for valid (or table) entries. Will 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 X-Spam-Level: X-Spam-Status: No, score=-15.3 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C56EEC433E0 for ; Thu, 4 Mar 2021 20:00:56 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 418EC64F72 for ; Thu, 4 Mar 2021 20:00:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 418EC64F72 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id AB9BD4B44A; Thu, 4 Mar 2021 15:00:55 -0500 (EST) 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=@kernel.org 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 ltcH-9MrE7hI; Thu, 4 Mar 2021 15:00:54 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 79BFA4B508; Thu, 4 Mar 2021 15:00:54 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 72A924B44A for ; Thu, 4 Mar 2021 15:00:53 -0500 (EST) 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 JVgcQerYS0ky for ; Thu, 4 Mar 2021 15:00:52 -0500 (EST) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 4BC3C4B445 for ; Thu, 4 Mar 2021 15:00:52 -0500 (EST) Received: by mail.kernel.org (Postfix) with ESMTPSA id 5010A64F65; Thu, 4 Mar 2021 20:00:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1614888051; bh=UH/6WrQiM34nfHG2XS5TT/G5/0kfI/kksSdM/0P/Kfg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=bYR6f8cxrOMRb34jioQTsd1SLiLYV1KrLhOxoa/UFlla225aOMoeU9KLwametgZGX e5UxygIrCjFHk727snrTlAC+zc1THCyYWXRHNW6bhw920Ttnj9NCS5X2Ih+o5ALWVK 8bzcdOJECfCuzr/vbSR1rZ8v1jVXMhWhNw+DbirPaQMEpoASd9ZqARx+ehcehxJknU SpENUYmOkDJnSdSwOWCMFlHYV9oxLgBfqvI9lx0K5oHBwfTbiME3Cs5py0GaxJAIlR biv8pRass1hSrt2fSlv8I3qPqJs7DpFaEMb2CjobCejwGpfx5/2Bf8XJ5QX/3hqHDq ZjtqlYWz2nibg== Date: Thu, 4 Mar 2021 20:00:45 +0000 From: Will Deacon To: Quentin Perret Subject: Re: [PATCH v3 26/32] KVM: arm64: Introduce PROT_NONE mappings for stage 2 Message-ID: <20210304200044.GF21950@willie-the-truck> References: <20210302150002.3685113-1-qperret@google.com> <20210302150002.3685113-27-qperret@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210302150002.3685113-27-qperret@google.com> User-Agent: Mutt/1.10.1 (2018-07-13) Cc: android-kvm@google.com, catalin.marinas@arm.com, mate.toth-pal@arm.com, seanjc@google.com, tabba@google.com, linux-kernel@vger.kernel.org, robh+dt@kernel.org, linux-arm-kernel@lists.infradead.org, maz@kernel.org, kernel-team@android.com, kvmarm@lists.cs.columbia.edu 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 Tue, Mar 02, 2021 at 02:59:56PM +0000, Quentin Perret wrote: > Once we start unmapping portions of memory from the host stage 2 (such > as e.g. the hypervisor memory sections, or pages that belong to > protected guests), we will need a way to track page ownership. And > given that all mappings in the host stage 2 will be identity-mapped, we > can use the host stage 2 page-table itself as a simplistic rmap. > > As a first step towards this, introduce a new protection attribute > in the stage 2 page table code, called KVM_PGTABLE_PROT_NONE, which > allows to annotate portions of the IPA space as inaccessible. For > simplicity, PROT_NONE mappings are created as invalid mappings with a > software bit set. Just as an observation, but given that they're invalid we can use any bit from [63:2] to indicate that it's a PROT_NONE mapping, and that way we can keep the real "software bits" for live mappings. But we can of course change that later when we need the bit for something else. > > Signed-off-by: Quentin Perret > --- > arch/arm64/include/asm/kvm_pgtable.h | 2 ++ > arch/arm64/kvm/hyp/pgtable.c | 26 ++++++++++++++++++++++++-- > 2 files changed, 26 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/include/asm/kvm_pgtable.h b/arch/arm64/include/asm/kvm_pgtable.h > index 9935dbae2cc1..c9f6ed76e0ad 100644 > --- a/arch/arm64/include/asm/kvm_pgtable.h > +++ b/arch/arm64/include/asm/kvm_pgtable.h > @@ -80,6 +80,7 @@ struct kvm_pgtable { > * @KVM_PGTABLE_PROT_W: Write permission. > * @KVM_PGTABLE_PROT_R: Read permission. > * @KVM_PGTABLE_PROT_DEVICE: Device attributes. > + * @KVM_PGTABLE_PROT_NONE: No permission. > */ > enum kvm_pgtable_prot { > KVM_PGTABLE_PROT_X = BIT(0), > @@ -87,6 +88,7 @@ enum kvm_pgtable_prot { > KVM_PGTABLE_PROT_R = BIT(2), > > KVM_PGTABLE_PROT_DEVICE = BIT(3), > + KVM_PGTABLE_PROT_NONE = BIT(4), Why do we need an extra entry here? Couldn't we just create PROT_NONE entries when none of R,W or X are set? > }; > > #define PAGE_HYP (KVM_PGTABLE_PROT_R | KVM_PGTABLE_PROT_W) > diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c > index bdd6e3d4eeb6..8e7059fcfd40 100644 > --- a/arch/arm64/kvm/hyp/pgtable.c > +++ b/arch/arm64/kvm/hyp/pgtable.c > @@ -48,6 +48,8 @@ > KVM_PTE_LEAF_ATTR_LO_S2_S2AP_W | \ > KVM_PTE_LEAF_ATTR_HI_S2_XN) > > +#define KVM_PTE_LEAF_SW_BIT_PROT_NONE BIT(55) > + > struct kvm_pgtable_walk_data { > struct kvm_pgtable *pgt; > struct kvm_pgtable_walker *walker; > @@ -120,6 +122,16 @@ static bool kvm_pte_valid(kvm_pte_t pte) > return pte & KVM_PTE_VALID; > } > > +static bool kvm_pte_prot_none(kvm_pte_t pte) > +{ > + return pte & KVM_PTE_LEAF_SW_BIT_PROT_NONE; > +} I think it would be a good idea to check !kvm_pte_valid() in here too, since it doesn't make sense to report true for valid (or table) entries. Will _______________________________________________ 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 X-Spam-Level: X-Spam-Status: No, score=-15.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0131EC433E0 for ; Thu, 4 Mar 2021 20:02:48 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9927C64F7A for ; Thu, 4 Mar 2021 20:02:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9927C64F7A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; 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=c7R8uY62txeumEBWG4tX8iD9+0JLv4ysekFvS7zSn0M=; b=S2k905f01zr3kBrIKTU3TAqXc fUE5sErfpBoHfffuoBERft8nbmRzCIU0gj2FW7uBscaJMQApPESvzQn+5I7EkF9gaImC3J5rS3v5s UPLRIk9Y+SEUiVM7MzMQDzu81WiEKKbAV6feQex4qSgaaLWV+WIN4AbTY1GguTHT7Q1LOj4c246qJ H2fzmMnue7yu3pwg9ZbHTC70lJ3l+cv66VmKTVbkvp0U5NRd3NouiJbQRZtCMJ3xXIG0yiOk7+rPo jW+8pHoiiuyNgsAbi63mfmaHcTBwUEs/CuGyXyemt2oaKaWZxnTtuDvBZ4xlrRvHOU0IOoYIqIWMy K8NTlrxVg==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lHu9a-009rLc-UQ; Thu, 04 Mar 2021 20:00:59 +0000 Received: from mail.kernel.org ([198.145.29.99]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lHu9U-009rL2-MS for linux-arm-kernel@lists.infradead.org; Thu, 04 Mar 2021 20:00:54 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 5010A64F65; Thu, 4 Mar 2021 20:00:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1614888051; bh=UH/6WrQiM34nfHG2XS5TT/G5/0kfI/kksSdM/0P/Kfg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=bYR6f8cxrOMRb34jioQTsd1SLiLYV1KrLhOxoa/UFlla225aOMoeU9KLwametgZGX e5UxygIrCjFHk727snrTlAC+zc1THCyYWXRHNW6bhw920Ttnj9NCS5X2Ih+o5ALWVK 8bzcdOJECfCuzr/vbSR1rZ8v1jVXMhWhNw+DbirPaQMEpoASd9ZqARx+ehcehxJknU SpENUYmOkDJnSdSwOWCMFlHYV9oxLgBfqvI9lx0K5oHBwfTbiME3Cs5py0GaxJAIlR biv8pRass1hSrt2fSlv8I3qPqJs7DpFaEMb2CjobCejwGpfx5/2Bf8XJ5QX/3hqHDq ZjtqlYWz2nibg== Date: Thu, 4 Mar 2021 20:00:45 +0000 From: Will Deacon To: Quentin Perret Cc: catalin.marinas@arm.com, maz@kernel.org, james.morse@arm.com, julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com, android-kvm@google.com, linux-kernel@vger.kernel.org, kernel-team@android.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, tabba@google.com, mark.rutland@arm.com, dbrazdil@google.com, mate.toth-pal@arm.com, seanjc@google.com, robh+dt@kernel.org Subject: Re: [PATCH v3 26/32] KVM: arm64: Introduce PROT_NONE mappings for stage 2 Message-ID: <20210304200044.GF21950@willie-the-truck> References: <20210302150002.3685113-1-qperret@google.com> <20210302150002.3685113-27-qperret@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210302150002.3685113-27-qperret@google.com> User-Agent: Mutt/1.10.1 (2018-07-13) 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 Tue, Mar 02, 2021 at 02:59:56PM +0000, Quentin Perret wrote: > Once we start unmapping portions of memory from the host stage 2 (such > as e.g. the hypervisor memory sections, or pages that belong to > protected guests), we will need a way to track page ownership. And > given that all mappings in the host stage 2 will be identity-mapped, we > can use the host stage 2 page-table itself as a simplistic rmap. > > As a first step towards this, introduce a new protection attribute > in the stage 2 page table code, called KVM_PGTABLE_PROT_NONE, which > allows to annotate portions of the IPA space as inaccessible. For > simplicity, PROT_NONE mappings are created as invalid mappings with a > software bit set. Just as an observation, but given that they're invalid we can use any bit from [63:2] to indicate that it's a PROT_NONE mapping, and that way we can keep the real "software bits" for live mappings. But we can of course change that later when we need the bit for something else. > > Signed-off-by: Quentin Perret > --- > arch/arm64/include/asm/kvm_pgtable.h | 2 ++ > arch/arm64/kvm/hyp/pgtable.c | 26 ++++++++++++++++++++++++-- > 2 files changed, 26 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/include/asm/kvm_pgtable.h b/arch/arm64/include/asm/kvm_pgtable.h > index 9935dbae2cc1..c9f6ed76e0ad 100644 > --- a/arch/arm64/include/asm/kvm_pgtable.h > +++ b/arch/arm64/include/asm/kvm_pgtable.h > @@ -80,6 +80,7 @@ struct kvm_pgtable { > * @KVM_PGTABLE_PROT_W: Write permission. > * @KVM_PGTABLE_PROT_R: Read permission. > * @KVM_PGTABLE_PROT_DEVICE: Device attributes. > + * @KVM_PGTABLE_PROT_NONE: No permission. > */ > enum kvm_pgtable_prot { > KVM_PGTABLE_PROT_X = BIT(0), > @@ -87,6 +88,7 @@ enum kvm_pgtable_prot { > KVM_PGTABLE_PROT_R = BIT(2), > > KVM_PGTABLE_PROT_DEVICE = BIT(3), > + KVM_PGTABLE_PROT_NONE = BIT(4), Why do we need an extra entry here? Couldn't we just create PROT_NONE entries when none of R,W or X are set? > }; > > #define PAGE_HYP (KVM_PGTABLE_PROT_R | KVM_PGTABLE_PROT_W) > diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c > index bdd6e3d4eeb6..8e7059fcfd40 100644 > --- a/arch/arm64/kvm/hyp/pgtable.c > +++ b/arch/arm64/kvm/hyp/pgtable.c > @@ -48,6 +48,8 @@ > KVM_PTE_LEAF_ATTR_LO_S2_S2AP_W | \ > KVM_PTE_LEAF_ATTR_HI_S2_XN) > > +#define KVM_PTE_LEAF_SW_BIT_PROT_NONE BIT(55) > + > struct kvm_pgtable_walk_data { > struct kvm_pgtable *pgt; > struct kvm_pgtable_walker *walker; > @@ -120,6 +122,16 @@ static bool kvm_pte_valid(kvm_pte_t pte) > return pte & KVM_PTE_VALID; > } > > +static bool kvm_pte_prot_none(kvm_pte_t pte) > +{ > + return pte & KVM_PTE_LEAF_SW_BIT_PROT_NONE; > +} I think it would be a good idea to check !kvm_pte_valid() in here too, since it doesn't make sense to report true for valid (or table) entries. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel