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 8591AC4167B for ; Mon, 11 Dec 2023 13:58:58 +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=Pv9D0WPvExU2wkKqZVTr1costKnkZohRu7n5FqlppxQ=; b=OcfbFc0E99jA27 Oi+y+PfYcaJOQ52r+FqcBmlu2wGZaDT6LQ/O4cqBHW1cPFd1dIZ/Ec7cZHgU1KOj/uzLJ3NAgr/ak ORZd9STbuhmis33iX5UHtqKzI3mdHFVOwaVcXp9MlztVdYc8UnVJV1MCyUC359VoNspE2QiXvhOR2 xJJZySEMpNeVT0KS8QIYkdCtVeRuvq3Dw7MDr8XJ16/b1yCDBsC4VOUb9HUN+Dup7SjXvQgWdQ0Nf I66t+n6u7ZXPoW/kKDC8Swm1QZWJhY+nWQ+xd4NbvK8SvrjPS+/dl1dD3mdI2iBeUAY7GPCKUfOyc VVmFxOD83JpjyTBmNzJw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rCgnl-0053X1-1h; Mon, 11 Dec 2023 13:58:29 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rCgnE-0053Is-1m for linux-arm-kernel@lists.infradead.org; Mon, 11 Dec 2023 13:58:26 +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 08EEBFEC; Mon, 11 Dec 2023 05:58:37 -0800 (PST) Received: from FVFF77S0Q05N.cambridge.arm.com (FVFF77S0Q05N.cambridge.arm.com [10.1.34.127]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 318E93F738; Mon, 11 Dec 2023 05:57:49 -0800 (PST) Date: Mon, 11 Dec 2023 13:57:44 +0000 From: Mark Rutland To: Ard Biesheuvel Cc: linux-arm-kernel@lists.infradead.org, Ard Biesheuvel , Catalin Marinas , Will Deacon , Marc Zyngier , Ryan Roberts , Anshuman Khandual , Kees Cook Subject: Re: [PATCH v6 04/41] arm64: mm: Move PCI I/O emulation region above the vmemmap region Message-ID: References: <20231129111555.3594833-43-ardb@google.com> <20231129111555.3594833-47-ardb@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20231129111555.3594833-47-ardb@google.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231211_055756_669324_927D32FC X-CRM114-Status: GOOD ( 19.74 ) 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 Hi Ard, On Wed, Nov 29, 2023 at 12:16:00PM +0100, Ard Biesheuvel wrote: > From: Ard Biesheuvel > > Move the PCI I/O region above the vmemmap region in the kernel's VA > space. This will permit us to reclaim the lower part of the vmemmap > region for vmalloc/vmap allocations when running a 52-bit VA capable > build on a 48-bit VA capable system. > > Signed-off-by: Ard Biesheuvel > --- > arch/arm64/include/asm/memory.h | 4 ++-- > arch/arm64/mm/ptdump.c | 4 ++-- > 2 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h > index b8d726f951ae..99caeff78e1a 100644 > --- a/arch/arm64/include/asm/memory.h > +++ b/arch/arm64/include/asm/memory.h > @@ -49,8 +49,8 @@ > #define MODULES_VSIZE (SZ_2G) > #define VMEMMAP_START (-(UL(1) << (VA_BITS - VMEMMAP_SHIFT))) > #define VMEMMAP_END (VMEMMAP_START + VMEMMAP_SIZE) > -#define PCI_IO_END (VMEMMAP_START - SZ_8M) > -#define PCI_IO_START (PCI_IO_END - PCI_IO_SIZE) > +#define PCI_IO_START (VMEMMAP_END + SZ_8M) > +#define PCI_IO_END (PCI_IO_START + PCI_IO_SIZE) > #define FIXADDR_TOP (VMEMMAP_START - SZ_32M) This looks simple, but it does have a subtle dependency on VMEMMAP_SIZE being sufficiently smaller than the negative offset we choose for VMEMMAP_START, and it took mw a while to convince myself that we always ensure that today. I could well imagine that we try to reduce that in future (given for most configurations we're reserving around double the space we actually need), and it would be nice if we could avoid that going wrong. We need to make sure that PCI_IO_START and PCI_IO_END fall between VMEMMAP_END and the last page of the VA space (due to ERR_PTR). Could we add some comment and/or assertions to that effect? Mark. > > #if VA_BITS > 48 > diff --git a/arch/arm64/mm/ptdump.c b/arch/arm64/mm/ptdump.c > index e305b6593c4e..d1df56d44f8a 100644 > --- a/arch/arm64/mm/ptdump.c > +++ b/arch/arm64/mm/ptdump.c > @@ -47,10 +47,10 @@ static struct addr_marker address_markers[] = { > { VMALLOC_END, "vmalloc() end" }, > { FIXADDR_TOT_START, "Fixmap start" }, > { FIXADDR_TOP, "Fixmap end" }, > - { PCI_IO_START, "PCI I/O start" }, > - { PCI_IO_END, "PCI I/O end" }, > { VMEMMAP_START, "vmemmap start" }, > { VMEMMAP_START + VMEMMAP_SIZE, "vmemmap end" }, > + { PCI_IO_START, "PCI I/O start" }, > + { PCI_IO_END, "PCI I/O end" }, > { -1, NULL }, > }; > > -- > 2.43.0.rc1.413.gea7ed67945-goog > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel