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=-16.0 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 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 DECBEC433B4 for ; Wed, 14 Apr 2021 20:11:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C382961164 for ; Wed, 14 Apr 2021 20:11:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240549AbhDNUMM (ORCPT ); Wed, 14 Apr 2021 16:12:12 -0400 Received: from mail.kernel.org ([198.145.29.99]:47014 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232967AbhDNUMI (ORCPT ); Wed, 14 Apr 2021 16:12:08 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id B343461177; Wed, 14 Apr 2021 20:11:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1618431106; bh=sV4UNsutnMtYuaS2+nk74hUsFkm1slC1eZ4FtbZ6jo0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=asFVTglc/UE2ixV1HtH1d7/BBlvWoJYaUneXRwap3OZ6xQ9hZH/oFtbH4rHDsONdS tN3HJ5qayGSWguapJn3MqInCuYDVI4BT07/q57eBE8TDLvQ/fXb8+v5OjAHp+nmZ6w cVhANE/H/76i3uz5D1kU/ydwiYERhped/NnSFOoy/FtmipjzZR+FraDR6hl18bz+eE aufPXkShAuNZ5OLZo9KcMS53z1uTko0YBEonTS7j1uD8BmyCpyBM0gxHPa+zWgiO9+ P4WKLHRIQD4j1aL/hq8mlGPfSLBM3/sJlbH+N4eSWTkc14bHLhDKVyq/fe16U/OX8U es47AYGW2sdwA== Date: Wed, 14 Apr 2021 23:11:38 +0300 From: Mike Rapoport To: Ard Biesheuvel Cc: David Hildenbrand , Linux ARM , Anshuman Khandual , Catalin Marinas , Marc Zyngier , Mark Rutland , Mike Rapoport , Will Deacon , kvmarm , Linux Kernel Mailing List , Linux Memory Management List Subject: Re: [RFC/RFT PATCH 1/3] memblock: update initialization of reserved pages Message-ID: References: <20210407172607.8812-1-rppt@kernel.org> <20210407172607.8812-2-rppt@kernel.org> <0c48f98c-7454-1458-15a5-cc5a7e1fb7cd@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 14, 2021 at 05:27:53PM +0200, Ard Biesheuvel wrote: > On Wed, 14 Apr 2021 at 17:14, David Hildenbrand wrote: > > > > On 07.04.21 19:26, Mike Rapoport wrote: > > > From: Mike Rapoport > > > > > > The struct pages representing a reserved memory region are initialized > > > using reserve_bootmem_range() function. This function is called for each > > > reserved region just before the memory is freed from memblock to the buddy > > > page allocator. > > > > > > The struct pages for MEMBLOCK_NOMAP regions are kept with the default > > > values set by the memory map initialization which makes it necessary to > > > have a special treatment for such pages in pfn_valid() and > > > pfn_valid_within(). > > > > I assume these pages are never given to the buddy, because we don't have > > a direct mapping. So to the kernel, it's essentially just like a memory > > hole with benefits. > > > > I can spot that we want to export such memory like any special memory > > thingy/hole in /proc/iomem -- "reserved", which makes sense. > > > > I would assume that MEMBLOCK_NOMAP is a special type of *reserved* > > memory. IOW, that for_each_reserved_mem_range() should already succeed > > on these as well -- we should mark anything that is MEMBLOCK_NOMAP > > implicitly as reserved. Or are there valid reasons not to do so? What > > can anyone do with that memory? > > > > I assume they are pretty much useless for the kernel, right? Like other > > reserved memory ranges. > > > > On ARM, we need to know whether any physical regions that do not > contain system memory contain something with device semantics or not. > One of the examples is ACPI tables: these are in reserved memory, and > so they are not covered by the linear region. However, when the ACPI > core ioremap()s an arbitrary memory region, we don't know whether it > is mapping a memory region or a device region unless we keep track of > this in some way. (Device mappings require device attributes, but > firmware tables require memory attributes, as they might be accessed > using misaligned reads) I mostly agree, but my understanding is that regions of *physical* memory that are occupied by various pieces of EFI/ACPI information require special treatment because it was defined this way in the APCI spec. And since ARM cannot tolerate aliased mappings with different caching mode the whole bunch of firmware memory should be ioremap()ed to access it. > > > Split out initialization of the reserved pages to a function with a > > > meaningful name and treat the MEMBLOCK_NOMAP regions the same way as the > > > reserved regions and mark struct pages for the NOMAP regions as > > > PageReserved. > > > > > > Signed-off-by: Mike Rapoport > > > --- > > > mm/memblock.c | 23 +++++++++++++++++++++-- > > > 1 file changed, 21 insertions(+), 2 deletions(-) > > > > > > diff --git a/mm/memblock.c b/mm/memblock.c > > > index afaefa8fc6ab..6b7ea9d86310 100644 > > > --- a/mm/memblock.c > > > +++ b/mm/memblock.c > > > @@ -2002,6 +2002,26 @@ static unsigned long __init __free_memory_core(phys_addr_t start, > > > return end_pfn - start_pfn; > > > } > > > > > > +static void __init memmap_init_reserved_pages(void) > > > +{ > > > + struct memblock_region *region; > > > + phys_addr_t start, end; > > > + u64 i; > > > + > > > + /* initialize struct pages for the reserved regions */ > > > + for_each_reserved_mem_range(i, &start, &end) > > > + reserve_bootmem_region(start, end); > > > + > > > + /* and also treat struct pages for the NOMAP regions as PageReserved */ > > > + for_each_mem_region(region) { > > > + if (memblock_is_nomap(region)) { > > > + start = region->base; > > > + end = start + region->size; > > > + reserve_bootmem_region(start, end); > > > + } > > > + } > > > +} > > > + > > > static unsigned long __init free_low_memory_core_early(void) > > > { > > > unsigned long count = 0; > > > @@ -2010,8 +2030,7 @@ static unsigned long __init free_low_memory_core_early(void) > > > > > > memblock_clear_hotplug(0, -1); > > > > > > - for_each_reserved_mem_range(i, &start, &end) > > > - reserve_bootmem_region(start, end); > > > + memmap_init_reserved_pages(); > > > > > > /* > > > * We need to use NUMA_NO_NODE instead of NODE_DATA(0)->node_id > > > > > > > > > -- > > Thanks, > > > > David / dhildenb > > > > > > _______________________________________________ > > linux-arm-kernel mailing list > > linux-arm-kernel@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Sincerely yours, Mike. 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=-13.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 BA337C433ED for ; Wed, 14 Apr 2021 20:11:52 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 33FA561179 for ; Wed, 14 Apr 2021 20:11:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 33FA561179 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 B34AA4B6A2; Wed, 14 Apr 2021 16:11:51 -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=@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 77waEGI2SHKT; Wed, 14 Apr 2021 16:11:50 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 4EFBE4B648; Wed, 14 Apr 2021 16:11:50 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 5BD4F4B4BE for ; Wed, 14 Apr 2021 16:11:49 -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 9AxsvOobBAnq for ; Wed, 14 Apr 2021 16:11:48 -0400 (EDT) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id E296D4B4A0 for ; Wed, 14 Apr 2021 16:11:47 -0400 (EDT) Received: by mail.kernel.org (Postfix) with ESMTPSA id B343461177; Wed, 14 Apr 2021 20:11:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1618431106; bh=sV4UNsutnMtYuaS2+nk74hUsFkm1slC1eZ4FtbZ6jo0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=asFVTglc/UE2ixV1HtH1d7/BBlvWoJYaUneXRwap3OZ6xQ9hZH/oFtbH4rHDsONdS tN3HJ5qayGSWguapJn3MqInCuYDVI4BT07/q57eBE8TDLvQ/fXb8+v5OjAHp+nmZ6w cVhANE/H/76i3uz5D1kU/ydwiYERhped/NnSFOoy/FtmipjzZR+FraDR6hl18bz+eE aufPXkShAuNZ5OLZo9KcMS53z1uTko0YBEonTS7j1uD8BmyCpyBM0gxHPa+zWgiO9+ P4WKLHRIQD4j1aL/hq8mlGPfSLBM3/sJlbH+N4eSWTkc14bHLhDKVyq/fe16U/OX8U es47AYGW2sdwA== Date: Wed, 14 Apr 2021 23:11:38 +0300 From: Mike Rapoport To: Ard Biesheuvel Subject: Re: [RFC/RFT PATCH 1/3] memblock: update initialization of reserved pages Message-ID: References: <20210407172607.8812-1-rppt@kernel.org> <20210407172607.8812-2-rppt@kernel.org> <0c48f98c-7454-1458-15a5-cc5a7e1fb7cd@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Cc: Anshuman Khandual , Catalin Marinas , David Hildenbrand , Linux Kernel Mailing List , Mike Rapoport , Linux Memory Management List , Marc Zyngier , Will Deacon , kvmarm , Linux ARM 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 Wed, Apr 14, 2021 at 05:27:53PM +0200, Ard Biesheuvel wrote: > On Wed, 14 Apr 2021 at 17:14, David Hildenbrand wrote: > > > > On 07.04.21 19:26, Mike Rapoport wrote: > > > From: Mike Rapoport > > > > > > The struct pages representing a reserved memory region are initialized > > > using reserve_bootmem_range() function. This function is called for each > > > reserved region just before the memory is freed from memblock to the buddy > > > page allocator. > > > > > > The struct pages for MEMBLOCK_NOMAP regions are kept with the default > > > values set by the memory map initialization which makes it necessary to > > > have a special treatment for such pages in pfn_valid() and > > > pfn_valid_within(). > > > > I assume these pages are never given to the buddy, because we don't have > > a direct mapping. So to the kernel, it's essentially just like a memory > > hole with benefits. > > > > I can spot that we want to export such memory like any special memory > > thingy/hole in /proc/iomem -- "reserved", which makes sense. > > > > I would assume that MEMBLOCK_NOMAP is a special type of *reserved* > > memory. IOW, that for_each_reserved_mem_range() should already succeed > > on these as well -- we should mark anything that is MEMBLOCK_NOMAP > > implicitly as reserved. Or are there valid reasons not to do so? What > > can anyone do with that memory? > > > > I assume they are pretty much useless for the kernel, right? Like other > > reserved memory ranges. > > > > On ARM, we need to know whether any physical regions that do not > contain system memory contain something with device semantics or not. > One of the examples is ACPI tables: these are in reserved memory, and > so they are not covered by the linear region. However, when the ACPI > core ioremap()s an arbitrary memory region, we don't know whether it > is mapping a memory region or a device region unless we keep track of > this in some way. (Device mappings require device attributes, but > firmware tables require memory attributes, as they might be accessed > using misaligned reads) I mostly agree, but my understanding is that regions of *physical* memory that are occupied by various pieces of EFI/ACPI information require special treatment because it was defined this way in the APCI spec. And since ARM cannot tolerate aliased mappings with different caching mode the whole bunch of firmware memory should be ioremap()ed to access it. > > > Split out initialization of the reserved pages to a function with a > > > meaningful name and treat the MEMBLOCK_NOMAP regions the same way as the > > > reserved regions and mark struct pages for the NOMAP regions as > > > PageReserved. > > > > > > Signed-off-by: Mike Rapoport > > > --- > > > mm/memblock.c | 23 +++++++++++++++++++++-- > > > 1 file changed, 21 insertions(+), 2 deletions(-) > > > > > > diff --git a/mm/memblock.c b/mm/memblock.c > > > index afaefa8fc6ab..6b7ea9d86310 100644 > > > --- a/mm/memblock.c > > > +++ b/mm/memblock.c > > > @@ -2002,6 +2002,26 @@ static unsigned long __init __free_memory_core(phys_addr_t start, > > > return end_pfn - start_pfn; > > > } > > > > > > +static void __init memmap_init_reserved_pages(void) > > > +{ > > > + struct memblock_region *region; > > > + phys_addr_t start, end; > > > + u64 i; > > > + > > > + /* initialize struct pages for the reserved regions */ > > > + for_each_reserved_mem_range(i, &start, &end) > > > + reserve_bootmem_region(start, end); > > > + > > > + /* and also treat struct pages for the NOMAP regions as PageReserved */ > > > + for_each_mem_region(region) { > > > + if (memblock_is_nomap(region)) { > > > + start = region->base; > > > + end = start + region->size; > > > + reserve_bootmem_region(start, end); > > > + } > > > + } > > > +} > > > + > > > static unsigned long __init free_low_memory_core_early(void) > > > { > > > unsigned long count = 0; > > > @@ -2010,8 +2030,7 @@ static unsigned long __init free_low_memory_core_early(void) > > > > > > memblock_clear_hotplug(0, -1); > > > > > > - for_each_reserved_mem_range(i, &start, &end) > > > - reserve_bootmem_region(start, end); > > > + memmap_init_reserved_pages(); > > > > > > /* > > > * We need to use NUMA_NO_NODE instead of NODE_DATA(0)->node_id > > > > > > > > > -- > > Thanks, > > > > David / dhildenb > > > > > > _______________________________________________ > > linux-arm-kernel mailing list > > linux-arm-kernel@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Sincerely yours, Mike. _______________________________________________ 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=-14.0 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 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 E35C6C433ED for ; Wed, 14 Apr 2021 20:13:51 +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 55E1961164 for ; Wed, 14 Apr 2021 20:13:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 55E1961164 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=W2eEnCngZMJvujBpuv+KUSvOMfrXr/wTCri5ah0EPaU=; b=Ky3SUD3zIMBhV3rOraJYGiA/r DSoGpcOXNOcDfGbbVoehHUaT7WyM4lLCXkz/pmCwyXuAv9nNy5Hjc35E4YzOzgxn2gdeKVZOjwzpj mx3KUaarhRYrtmvm5rB/hJABdfBGBY/WBrXI958Szowf7uu++p2J9G0nDA151xOKFAOxTNLMNEY6O UTMwvl8ED+tlWz+B0SXvdyIzm/fvsQiBZrJo2dLb20FtlRGrfG80o3s0Dg3K2yn6LLURxR5fmRU1O 5m50MVeeq5y3bkdieQmAy8aXIsKuaC63T+NH6JUTdx4+wRn09Pi33ybXmQTXX4xkjba/b3SU0roCj Oj2/NCXSQ==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lWlre-00Dfaq-N2; Wed, 14 Apr 2021 20:11:54 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lWlra-00DfaY-8n for linux-arm-kernel@desiato.infradead.org; Wed, 14 Apr 2021 20:11:50 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=OFAlk6T0H4OinLGKlGjbFG8WR0xR8oqZOxCi15ZO5qw=; b=jpX//YKBQlmouX8W7vTtegdBoN GQd/MITJ3dYbuGPlNlZ6veQOGtwUbCWdGFTt6RBW7q4fXpOSbUWzqmS9dWo2XD/w+4k/x7dy+0Oh3 y7yQ39jf+lUjoWk7hNWiQLY25DxVk4xfZI3uya0zPjDygsLWARxEfSiEnEyJprUC5XiJjn0Lq7asz z1w78TEadZVBPB7LKwNiTXnfom05sdzIe9ykwsY4fViBuEZFyl7T0UxxUeWtgW/8x8z2h1YbTylAf nCNmof7VSGcKTwxbyAGCzrHGP6AYaVTO3Rball03CdF8LyF6olIyaBFuJVqldLPmpw4Jdwx87HNqq TFOTy5fw==; Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lWlrX-00850R-AN for linux-arm-kernel@lists.infradead.org; Wed, 14 Apr 2021 20:11:48 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id B343461177; Wed, 14 Apr 2021 20:11:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1618431106; bh=sV4UNsutnMtYuaS2+nk74hUsFkm1slC1eZ4FtbZ6jo0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=asFVTglc/UE2ixV1HtH1d7/BBlvWoJYaUneXRwap3OZ6xQ9hZH/oFtbH4rHDsONdS tN3HJ5qayGSWguapJn3MqInCuYDVI4BT07/q57eBE8TDLvQ/fXb8+v5OjAHp+nmZ6w cVhANE/H/76i3uz5D1kU/ydwiYERhped/NnSFOoy/FtmipjzZR+FraDR6hl18bz+eE aufPXkShAuNZ5OLZo9KcMS53z1uTko0YBEonTS7j1uD8BmyCpyBM0gxHPa+zWgiO9+ P4WKLHRIQD4j1aL/hq8mlGPfSLBM3/sJlbH+N4eSWTkc14bHLhDKVyq/fe16U/OX8U es47AYGW2sdwA== Date: Wed, 14 Apr 2021 23:11:38 +0300 From: Mike Rapoport To: Ard Biesheuvel Cc: David Hildenbrand , Linux ARM , Anshuman Khandual , Catalin Marinas , Marc Zyngier , Mark Rutland , Mike Rapoport , Will Deacon , kvmarm , Linux Kernel Mailing List , Linux Memory Management List Subject: Re: [RFC/RFT PATCH 1/3] memblock: update initialization of reserved pages Message-ID: References: <20210407172607.8812-1-rppt@kernel.org> <20210407172607.8812-2-rppt@kernel.org> <0c48f98c-7454-1458-15a5-cc5a7e1fb7cd@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210414_131147_428857_4E927467 X-CRM114-Status: GOOD ( 44.88 ) 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 Wed, Apr 14, 2021 at 05:27:53PM +0200, Ard Biesheuvel wrote: > On Wed, 14 Apr 2021 at 17:14, David Hildenbrand wrote: > > > > On 07.04.21 19:26, Mike Rapoport wrote: > > > From: Mike Rapoport > > > > > > The struct pages representing a reserved memory region are initialized > > > using reserve_bootmem_range() function. This function is called for each > > > reserved region just before the memory is freed from memblock to the buddy > > > page allocator. > > > > > > The struct pages for MEMBLOCK_NOMAP regions are kept with the default > > > values set by the memory map initialization which makes it necessary to > > > have a special treatment for such pages in pfn_valid() and > > > pfn_valid_within(). > > > > I assume these pages are never given to the buddy, because we don't have > > a direct mapping. So to the kernel, it's essentially just like a memory > > hole with benefits. > > > > I can spot that we want to export such memory like any special memory > > thingy/hole in /proc/iomem -- "reserved", which makes sense. > > > > I would assume that MEMBLOCK_NOMAP is a special type of *reserved* > > memory. IOW, that for_each_reserved_mem_range() should already succeed > > on these as well -- we should mark anything that is MEMBLOCK_NOMAP > > implicitly as reserved. Or are there valid reasons not to do so? What > > can anyone do with that memory? > > > > I assume they are pretty much useless for the kernel, right? Like other > > reserved memory ranges. > > > > On ARM, we need to know whether any physical regions that do not > contain system memory contain something with device semantics or not. > One of the examples is ACPI tables: these are in reserved memory, and > so they are not covered by the linear region. However, when the ACPI > core ioremap()s an arbitrary memory region, we don't know whether it > is mapping a memory region or a device region unless we keep track of > this in some way. (Device mappings require device attributes, but > firmware tables require memory attributes, as they might be accessed > using misaligned reads) I mostly agree, but my understanding is that regions of *physical* memory that are occupied by various pieces of EFI/ACPI information require special treatment because it was defined this way in the APCI spec. And since ARM cannot tolerate aliased mappings with different caching mode the whole bunch of firmware memory should be ioremap()ed to access it. > > > Split out initialization of the reserved pages to a function with a > > > meaningful name and treat the MEMBLOCK_NOMAP regions the same way as the > > > reserved regions and mark struct pages for the NOMAP regions as > > > PageReserved. > > > > > > Signed-off-by: Mike Rapoport > > > --- > > > mm/memblock.c | 23 +++++++++++++++++++++-- > > > 1 file changed, 21 insertions(+), 2 deletions(-) > > > > > > diff --git a/mm/memblock.c b/mm/memblock.c > > > index afaefa8fc6ab..6b7ea9d86310 100644 > > > --- a/mm/memblock.c > > > +++ b/mm/memblock.c > > > @@ -2002,6 +2002,26 @@ static unsigned long __init __free_memory_core(phys_addr_t start, > > > return end_pfn - start_pfn; > > > } > > > > > > +static void __init memmap_init_reserved_pages(void) > > > +{ > > > + struct memblock_region *region; > > > + phys_addr_t start, end; > > > + u64 i; > > > + > > > + /* initialize struct pages for the reserved regions */ > > > + for_each_reserved_mem_range(i, &start, &end) > > > + reserve_bootmem_region(start, end); > > > + > > > + /* and also treat struct pages for the NOMAP regions as PageReserved */ > > > + for_each_mem_region(region) { > > > + if (memblock_is_nomap(region)) { > > > + start = region->base; > > > + end = start + region->size; > > > + reserve_bootmem_region(start, end); > > > + } > > > + } > > > +} > > > + > > > static unsigned long __init free_low_memory_core_early(void) > > > { > > > unsigned long count = 0; > > > @@ -2010,8 +2030,7 @@ static unsigned long __init free_low_memory_core_early(void) > > > > > > memblock_clear_hotplug(0, -1); > > > > > > - for_each_reserved_mem_range(i, &start, &end) > > > - reserve_bootmem_region(start, end); > > > + memmap_init_reserved_pages(); > > > > > > /* > > > * We need to use NUMA_NO_NODE instead of NODE_DATA(0)->node_id > > > > > > > > > -- > > Thanks, > > > > David / dhildenb > > > > > > _______________________________________________ > > linux-arm-kernel mailing list > > linux-arm-kernel@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Sincerely yours, Mike. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel