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 6F7F7C433B4 for ; Wed, 14 Apr 2021 15:28:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4CB8061158 for ; Wed, 14 Apr 2021 15:28:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235788AbhDNP2i (ORCPT ); Wed, 14 Apr 2021 11:28:38 -0400 Received: from mail.kernel.org ([198.145.29.99]:47896 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233670AbhDNP20 (ORCPT ); Wed, 14 Apr 2021 11:28:26 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 335F1611F2 for ; Wed, 14 Apr 2021 15:28:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1618414085; bh=LwQCTRWb7Rq4DqiUTefKtvt2QC/nEsSrSyc5Ht5pJyk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=jYLbWgtCHR/SP++hgXjyN7wsiKuNlKxfly5lcNNBft3+xf2v1jpLuQDj4Ner/KcK3 mNm39W5OUHNihuDvVOIns3IeaihceBebDx5+mgrqVLKqCdAjbOrEfEuTmBfDB0ssj5 /iU1bFA2VIoe4wz00BLTNtk1l+GImmY9ryyZvqVUimCHotaHD0qMAfWVbB3bzPxWUC oYHJTuuvl6t2Z4prUI0xsw61kA2tz0NDy1gCWPczMkEeReEimUb+HZU61tXDonHeIW pQDOcoHfaBagjhH6Ywvpip1iiWRUrzbXFhoO6j4NSsc3OaMnvI9RDB9zD9fKq8Y+Sj Z5DBaQ7cv8WvQ== Received: by mail-oo1-f52.google.com with SMTP id c12-20020a4ae24c0000b02901bad05f40e4so4686414oot.4 for ; Wed, 14 Apr 2021 08:28:05 -0700 (PDT) X-Gm-Message-State: AOAM530HYaTU+3BuMHKmv7g4uENY+8FW3D4uc5pGMsi/xevIJ00M3ksj 58YZLYt1Y+5c1qb2ACQzquTIhsN9DyNEgpeHFY8= X-Google-Smtp-Source: ABdhPJz+JSWz1Dqi1C/C62MRuoCEpRmSe86sqIrI/r3CxHcywLXtc82obRQrItgRzp6gBYbcXpltBvEt0/ghCzKR6Q8= X-Received: by 2002:a4a:a588:: with SMTP id d8mr126051oom.45.1618414084358; Wed, 14 Apr 2021 08:28:04 -0700 (PDT) MIME-Version: 1.0 References: <20210407172607.8812-1-rppt@kernel.org> <20210407172607.8812-2-rppt@kernel.org> <0c48f98c-7454-1458-15a5-cc5a7e1fb7cd@redhat.com> In-Reply-To: <0c48f98c-7454-1458-15a5-cc5a7e1fb7cd@redhat.com> From: Ard Biesheuvel Date: Wed, 14 Apr 2021 17:27:53 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC/RFT PATCH 1/3] memblock: update initialization of reserved pages To: David Hildenbrand Cc: Mike Rapoport , Linux ARM , Anshuman Khandual , Catalin Marinas , Marc Zyngier , Mark Rutland , Mike Rapoport , Will Deacon , kvmarm , Linux Kernel Mailing List , Linux Memory Management List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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) > > > > > 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 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=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 4B973C433B4 for ; Wed, 14 Apr 2021 15:28:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EA32B6100B for ; Wed, 14 Apr 2021 15:28:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EA32B6100B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8738F6B007B; Wed, 14 Apr 2021 11:28:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 84A776B007D; Wed, 14 Apr 2021 11:28:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 712B06B007E; Wed, 14 Apr 2021 11:28:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 555B66B007B for ; Wed, 14 Apr 2021 11:28:08 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id DF40E4DBD for ; Wed, 14 Apr 2021 15:28:07 +0000 (UTC) X-FDA: 78031353414.08.71AD0B9 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf27.hostedemail.com (Postfix) with ESMTP id 23D7680192E6 for ; Wed, 14 Apr 2021 15:27:56 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 089126100B for ; Wed, 14 Apr 2021 15:28:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1618414085; bh=LwQCTRWb7Rq4DqiUTefKtvt2QC/nEsSrSyc5Ht5pJyk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=jYLbWgtCHR/SP++hgXjyN7wsiKuNlKxfly5lcNNBft3+xf2v1jpLuQDj4Ner/KcK3 mNm39W5OUHNihuDvVOIns3IeaihceBebDx5+mgrqVLKqCdAjbOrEfEuTmBfDB0ssj5 /iU1bFA2VIoe4wz00BLTNtk1l+GImmY9ryyZvqVUimCHotaHD0qMAfWVbB3bzPxWUC oYHJTuuvl6t2Z4prUI0xsw61kA2tz0NDy1gCWPczMkEeReEimUb+HZU61tXDonHeIW pQDOcoHfaBagjhH6Ywvpip1iiWRUrzbXFhoO6j4NSsc3OaMnvI9RDB9zD9fKq8Y+Sj Z5DBaQ7cv8WvQ== Received: by mail-oo1-f46.google.com with SMTP id d11-20020a4a520b0000b02901e5e7013daaso2790763oob.10 for ; Wed, 14 Apr 2021 08:28:04 -0700 (PDT) X-Gm-Message-State: AOAM5330A8uWKjkECnLR+H+8E0J3zLHQj45N0/dqG6i/7C6Pwg1bfwba 7g4yQrr+RbMnOMBLJlLfk+Xe1Pw4kbQ3DgrW3DA= X-Google-Smtp-Source: ABdhPJz+JSWz1Dqi1C/C62MRuoCEpRmSe86sqIrI/r3CxHcywLXtc82obRQrItgRzp6gBYbcXpltBvEt0/ghCzKR6Q8= X-Received: by 2002:a4a:a588:: with SMTP id d8mr126051oom.45.1618414084358; Wed, 14 Apr 2021 08:28:04 -0700 (PDT) MIME-Version: 1.0 References: <20210407172607.8812-1-rppt@kernel.org> <20210407172607.8812-2-rppt@kernel.org> <0c48f98c-7454-1458-15a5-cc5a7e1fb7cd@redhat.com> In-Reply-To: <0c48f98c-7454-1458-15a5-cc5a7e1fb7cd@redhat.com> From: Ard Biesheuvel Date: Wed, 14 Apr 2021 17:27:53 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC/RFT PATCH 1/3] memblock: update initialization of reserved pages To: David Hildenbrand Cc: Mike Rapoport , Linux ARM , Anshuman Khandual , Catalin Marinas , Marc Zyngier , Mark Rutland , Mike Rapoport , Will Deacon , kvmarm , Linux Kernel Mailing List , Linux Memory Management List Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: spr8kduwfew3tnwprpd6z9wxf3phoryw X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 23D7680192E6 Received-SPF: none (kernel.org>: No applicable sender policy available) receiver=imf27; identity=mailfrom; envelope-from=""; helo=mail.kernel.org; client-ip=198.145.29.99 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1618414076-16955 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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) > > > > > 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 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 2F5A7C43460 for ; Wed, 14 Apr 2021 15:28:11 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 92E2261164 for ; Wed, 14 Apr 2021 15:28:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 92E2261164 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 25C924B6C2; Wed, 14 Apr 2021 11:28:10 -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 bLUEwZ6msZE2; Wed, 14 Apr 2021 11:28:08 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id EE60E4B685; Wed, 14 Apr 2021 11:28:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 92FCC4B673 for ; Wed, 14 Apr 2021 11:28:07 -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 dbpE4K6pmCJ2 for ; Wed, 14 Apr 2021 11:28:06 -0400 (EDT) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 2D3F44B5A9 for ; Wed, 14 Apr 2021 11:28:06 -0400 (EDT) Received: by mail.kernel.org (Postfix) with ESMTPSA id 2A398611C9 for ; Wed, 14 Apr 2021 15:28:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1618414085; bh=LwQCTRWb7Rq4DqiUTefKtvt2QC/nEsSrSyc5Ht5pJyk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=jYLbWgtCHR/SP++hgXjyN7wsiKuNlKxfly5lcNNBft3+xf2v1jpLuQDj4Ner/KcK3 mNm39W5OUHNihuDvVOIns3IeaihceBebDx5+mgrqVLKqCdAjbOrEfEuTmBfDB0ssj5 /iU1bFA2VIoe4wz00BLTNtk1l+GImmY9ryyZvqVUimCHotaHD0qMAfWVbB3bzPxWUC oYHJTuuvl6t2Z4prUI0xsw61kA2tz0NDy1gCWPczMkEeReEimUb+HZU61tXDonHeIW pQDOcoHfaBagjhH6Ywvpip1iiWRUrzbXFhoO6j4NSsc3OaMnvI9RDB9zD9fKq8Y+Sj Z5DBaQ7cv8WvQ== Received: by mail-oo1-f47.google.com with SMTP id i25-20020a4aa1190000b02901bbd9429832so4704878ool.0 for ; Wed, 14 Apr 2021 08:28:05 -0700 (PDT) X-Gm-Message-State: AOAM532OePdgpkalOpGA4bXaTTyWUs5G6iHErPt4c1RFbvhM0s9TP5Eb jnIdajcMZ/obB/Bb82H4iL81Dve+AW5DgzXgqaA= X-Google-Smtp-Source: ABdhPJz+JSWz1Dqi1C/C62MRuoCEpRmSe86sqIrI/r3CxHcywLXtc82obRQrItgRzp6gBYbcXpltBvEt0/ghCzKR6Q8= X-Received: by 2002:a4a:a588:: with SMTP id d8mr126051oom.45.1618414084358; Wed, 14 Apr 2021 08:28:04 -0700 (PDT) MIME-Version: 1.0 References: <20210407172607.8812-1-rppt@kernel.org> <20210407172607.8812-2-rppt@kernel.org> <0c48f98c-7454-1458-15a5-cc5a7e1fb7cd@redhat.com> In-Reply-To: <0c48f98c-7454-1458-15a5-cc5a7e1fb7cd@redhat.com> From: Ard Biesheuvel Date: Wed, 14 Apr 2021 17:27:53 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC/RFT PATCH 1/3] memblock: update initialization of reserved pages To: David Hildenbrand Cc: Anshuman Khandual , Catalin Marinas , Linux Kernel Mailing List , Mike Rapoport , Linux Memory Management List , Mike Rapoport , 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, 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) > > > > > 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 _______________________________________________ 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 28652C433ED for ; Wed, 14 Apr 2021 15:30:17 +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 A907761158 for ; Wed, 14 Apr 2021 15:30:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A907761158 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:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=+gqs+KwO2fZJ5YhxfbXVBq5CpGI2D0iziu44vRUEk9I=; b=Er4nb0YlULuyC1FWLo+2cygWR ljhrm73CgXco84LWj7b6ZN84whYguXaIbUIYfvVeNLgI9LRVYyub2MqEbDJesG9+ZxxFgAA7Y8m+e xd5dOgzTmHczDtQHX6GFVfUGwUdShv++3bOTZSG2qYSS60Vg+4DQFPqlL7XfDy4Mq8httkajEjydD BsayctqlKTq4z0+hBm2NS+5jeZFuRzHcCnlVH67E92EpM2H6gh+oxfa56qtJHI8ML1IMEpiFqMw7V uKGsrZBfkEWRhG4qAWfLtv3tZ4ObNEkHE7E1SS8dDoks9YFNXwCIeQxTvjM7lmpEWcsb4vLadFB+8 fe757zZIg==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lWhR6-00D1FA-F0; Wed, 14 Apr 2021 15:28:12 +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 1lWhR2-00D1F4-Rr for linux-arm-kernel@desiato.infradead.org; Wed, 14 Apr 2021 15:28:09 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Type:Cc:To:Subject:Message-ID :Date:From:In-Reply-To:References:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=VvD5vyMOTfX2H/eNPUjECbuN+RVTvEaI8O+5xTf4FwI=; b=jyzLlng7yEF17MIiQs9HZWFKid 5OTjgqgM/IIH5qbR4gBYKfLWPHqCp0C0xGs12nb2gdbeJCliOcEHbzX4tuEbGQyOXl7i4BYw9o8d4 1XdAIrjWNDD5IUUvDTx7HJdsUlhMKw16H0vEdDPtYGnNIOve6SRx84J1FmI2C5eIEVl8J+eHBS1vP rJRTGtS5hWqWK8HhJCiEGjNW3KcnFrERMknGj2dJu9+oxNv0plAby7GoBqN0HSxo4B+NPJGPX+oZk bZPbJ2sayuJBkxIJc9f5j9pOF3WPVLYkDEG7HPKmQulB693oNedJEMqazH2INSqev6rHKlfFtCh+0 I/4r69RA==; Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lWhR0-007td8-18 for linux-arm-kernel@lists.infradead.org; Wed, 14 Apr 2021 15:28:07 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 1358C61158 for ; Wed, 14 Apr 2021 15:28:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1618414085; bh=LwQCTRWb7Rq4DqiUTefKtvt2QC/nEsSrSyc5Ht5pJyk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=jYLbWgtCHR/SP++hgXjyN7wsiKuNlKxfly5lcNNBft3+xf2v1jpLuQDj4Ner/KcK3 mNm39W5OUHNihuDvVOIns3IeaihceBebDx5+mgrqVLKqCdAjbOrEfEuTmBfDB0ssj5 /iU1bFA2VIoe4wz00BLTNtk1l+GImmY9ryyZvqVUimCHotaHD0qMAfWVbB3bzPxWUC oYHJTuuvl6t2Z4prUI0xsw61kA2tz0NDy1gCWPczMkEeReEimUb+HZU61tXDonHeIW pQDOcoHfaBagjhH6Ywvpip1iiWRUrzbXFhoO6j4NSsc3OaMnvI9RDB9zD9fKq8Y+Sj Z5DBaQ7cv8WvQ== Received: by mail-oo1-f45.google.com with SMTP id 125-20020a4a1a830000b02901b6a144a417so4683199oof.13 for ; Wed, 14 Apr 2021 08:28:04 -0700 (PDT) X-Gm-Message-State: AOAM532zZg/fVhRgWx5XB9pAFf8N/50GLXTEn/X50/XS8YijUWsEWUta B2y3DFykHWlF32jsgvdRsH9JsIw16WAavEwQOgc= X-Google-Smtp-Source: ABdhPJz+JSWz1Dqi1C/C62MRuoCEpRmSe86sqIrI/r3CxHcywLXtc82obRQrItgRzp6gBYbcXpltBvEt0/ghCzKR6Q8= X-Received: by 2002:a4a:a588:: with SMTP id d8mr126051oom.45.1618414084358; Wed, 14 Apr 2021 08:28:04 -0700 (PDT) MIME-Version: 1.0 References: <20210407172607.8812-1-rppt@kernel.org> <20210407172607.8812-2-rppt@kernel.org> <0c48f98c-7454-1458-15a5-cc5a7e1fb7cd@redhat.com> In-Reply-To: <0c48f98c-7454-1458-15a5-cc5a7e1fb7cd@redhat.com> From: Ard Biesheuvel Date: Wed, 14 Apr 2021 17:27:53 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC/RFT PATCH 1/3] memblock: update initialization of reserved pages To: David Hildenbrand Cc: Mike Rapoport , Linux ARM , Anshuman Khandual , Catalin Marinas , Marc Zyngier , Mark Rutland , Mike Rapoport , Will Deacon , kvmarm , Linux Kernel Mailing List , Linux Memory Management List X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210414_082806_136437_763E9F8D X-CRM114-Status: GOOD ( 39.44 ) 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, 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) > > > > > 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel