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 955F6C3DA42 for ; Wed, 10 Jul 2024 15:35:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=JGUEPhSRnh2FXV9smpwQHMAClBJwzHn9oDau6Mvs97Q=; b=LrbfTNt4rfgLR0NQTOCMu8E7Fj R+u3jOX+30l9Z4OEclsXFU8RWokr5bdx6IUa8E1+HiLi8mHxxfCVy67DQ2n5bo7Xvyi5BMJFEOEzQ qk8E08BkVt/pt5m7dUTTAFCSmtRXlYg1/2JFsI5x/4iD1aLV6cYifsJk48zcuz8LSdhf1ELBWbymQ jpMV1ZlDcz0wWiKj1HpFBoMsZ6i421Fh6OfEfRKsM/6gOLXGlA9kWcJcf/Bvxn7ZlRVR5rPFaUnQR KKS/IYOPYjI4h7389Z5Pu8pEaqBd4RO7xGNnOMmJ68TcHv6cZby3hmDlzVqR4tK3UzUHuKtO/lFFC VQGplKgA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sRZM0-0000000Aydt-1BfX; Wed, 10 Jul 2024 15:35:36 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sRZLC-0000000AyGT-0dZ7 for linux-arm-kernel@lists.infradead.org; Wed, 10 Jul 2024 15:34:47 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 72A73113E; Wed, 10 Jul 2024 08:35:09 -0700 (PDT) Received: from [10.57.8.115] (unknown [10.57.8.115]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9967D3F766; Wed, 10 Jul 2024 08:34:36 -0700 (PDT) Message-ID: <40746334-7669-48f2-9aa7-a73da0b2a275@arm.com> Date: Wed, 10 Jul 2024 16:34:20 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 06/15] arm64: Make the PHYS_MASK_SHIFT dynamic To: Suzuki K Poulose , Will Deacon Cc: kvm@vger.kernel.org, kvmarm@lists.linux.dev, Catalin Marinas , Marc Zyngier , James Morse , Oliver Upton , Zenghui Yu , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Joey Gouly , Alexandru Elisei , Christoffer Dall , Fuad Tabba , linux-coco@lists.linux.dev, Ganapatrao Kulkarni References: <20240701095505.165383-1-steven.price@arm.com> <20240701095505.165383-7-steven.price@arm.com> <20240709114337.GB13242@willie-the-truck> <1ce456b5-0652-4522-98ea-b32d96c1adf4@arm.com> From: Steven Price Content-Language: en-GB In-Reply-To: <1ce456b5-0652-4522-98ea-b32d96c1adf4@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240710_083446_325266_85F555AD X-CRM114-Status: GOOD ( 21.26 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 09/07/2024 13:55, Suzuki K Poulose wrote: > On 09/07/2024 12:43, Will Deacon wrote: >> On Mon, Jul 01, 2024 at 10:54:56AM +0100, Steven Price wrote: >>> Make the PHYS_MASK_SHIFT dynamic for Realms. This is only is required >>> for masking the PFN from a pte entry. For a realm phys_mask_shift is >>> reduced if the RMM reports a smaller configured size for the guest. >>> >>> The realm configuration splits the address space into two with the top >>> half being memory shared with the host, and the bottom half being >>> protected memory. We treat the bit which controls this split as an >>> attribute bit and hence exclude it (and any higher bits) from the mask. >>> >>> Co-developed-by: Suzuki K Poulose >>> Signed-off-by: Suzuki K Poulose >>> Signed-off-by: Steven Price >>> >>> --- >>> v3: Drop the MAX_PHYS_MASK{,_SHIFT} definitions as they are no longer >>> needed. >>> --- >>>   arch/arm64/include/asm/pgtable-hwdef.h | 6 ------ >>>   arch/arm64/include/asm/pgtable.h       | 5 +++++ >>>   arch/arm64/kernel/rsi.c                | 5 +++++ >>>   3 files changed, 10 insertions(+), 6 deletions(-) >>> >>> diff --git a/arch/arm64/include/asm/pgtable-hwdef.h >>> b/arch/arm64/include/asm/pgtable-hwdef.h >>> index 9943ff0af4c9..2e3af0693bd8 100644 >>> --- a/arch/arm64/include/asm/pgtable-hwdef.h >>> +++ b/arch/arm64/include/asm/pgtable-hwdef.h >>> @@ -203,12 +203,6 @@ >>>    */ >>>   #define PTE_S2_MEMATTR(t)    (_AT(pteval_t, (t)) << 2) >>>   -/* >>> - * Highest possible physical address supported. >>> - */ >>> -#define PHYS_MASK_SHIFT        (CONFIG_ARM64_PA_BITS) >>> -#define PHYS_MASK        ((UL(1) << PHYS_MASK_SHIFT) - 1) >>> - >>>   #define TTBR_CNP_BIT        (UL(1) << 0) >>>     /* >>> diff --git a/arch/arm64/include/asm/pgtable.h >>> b/arch/arm64/include/asm/pgtable.h >>> index f8efbc128446..11d614d83317 100644 >>> --- a/arch/arm64/include/asm/pgtable.h >>> +++ b/arch/arm64/include/asm/pgtable.h >>> @@ -39,6 +39,11 @@ >>>   #include >>>   #include >>>   +extern unsigned int phys_mask_shift; >>> + >>> +#define PHYS_MASK_SHIFT        (phys_mask_shift) >>> +#define PHYS_MASK        ((1UL << PHYS_MASK_SHIFT) - 1) >> >> I tried to figure out where this is actually used so I could understand >> your comment in the commit message: >> >>   > This is only is required for masking the PFN from a pte entry >> >> The closest thing I could find is in arch/arm64/mm/mmap.c, where the >> mask is used as part of valid_mmap_phys_addr_range() which exists purely >> to filter accesses to /dev/mem. That's pretty niche, so why not just >> inline the RSI-specific stuff in there behind a static key instead of >> changing these definitions? >> >> Or did I miss a subtle user somewhere else? > > We need to prevent ioremap() of addresses beyond that limit too. Which is arguably not much better in terms of nicheness... But this seemed cleaner rather than trying to keep track of the niche areas of the kernel which require this and modifying them. We could use a static key here, but I don't think this is used for any hot-paths so it didn't seem worth the complexity. Steve