From: David Hildenbrand <david@redhat.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Mike Rapoport <rppt@kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Anshuman Khandual <anshuman.khandual@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Marc Zyngier <maz@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Mike Rapoport <rppt@linux.ibm.com>, Will Deacon <will@kernel.org>,
kvmarm <kvmarm@lists.cs.columbia.edu>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Memory Management List <linux-mm@kvack.org>
Subject: Re: [RFC/RFT PATCH 1/3] memblock: update initialization of reserved pages
Date: Wed, 14 Apr 2021 17:52:57 +0200 [thread overview]
Message-ID: <3811547a-9057-3c80-3805-2e658488ac99@redhat.com> (raw)
In-Reply-To: <CAMj1kXGw97epyP2HdHjA8Yp6+VF1j5xmd0AgVBBv3k+h_B610w@mail.gmail.com>
On 14.04.21 17:27, Ard Biesheuvel wrote:
> On Wed, 14 Apr 2021 at 17:14, David Hildenbrand <david@redhat.com> wrote:
>>
>> On 07.04.21 19:26, Mike Rapoport wrote:
>>> From: Mike Rapoport <rppt@linux.ibm.com>
>>>
>>> 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)
Using generically sounding NOMAP ("don't create direct mapping") to
identify device regions feels like a hack. I know, it was introduced
just for that purpose.
Looking at memblock_mark_nomap(), we consider "device regions"
1) ACPI tables
2) VIDEO_TYPE_EFI memory
3) some device-tree regions in of/fdt.c
IIUC, right now we end up creating a memmap for this NOMAP memory, but
hide it away in pfn_valid(). This patch set at least fixes that.
Assuming these pages are never mapped to user space via the struct page
(which better be the case), we could further use a new pagetype to mark
these pages in a special way, such that we can identify them directly
via pfn_to_page().
Then, we could mostly avoid having to query memblock at runtime to
figure out that this is special memory. This would obviously be an
extension to this series. Just a thought.
--
Thanks,
David / dhildenb
WARNING: multiple messages have this Message-ID (diff)
From: David Hildenbrand <david@redhat.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Mike Rapoport <rppt@linux.ibm.com>,
Linux Memory Management List <linux-mm@kvack.org>,
Mike Rapoport <rppt@kernel.org>, Marc Zyngier <maz@kernel.org>,
Will Deacon <will@kernel.org>,
kvmarm <kvmarm@lists.cs.columbia.edu>,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC/RFT PATCH 1/3] memblock: update initialization of reserved pages
Date: Wed, 14 Apr 2021 17:52:57 +0200 [thread overview]
Message-ID: <3811547a-9057-3c80-3805-2e658488ac99@redhat.com> (raw)
In-Reply-To: <CAMj1kXGw97epyP2HdHjA8Yp6+VF1j5xmd0AgVBBv3k+h_B610w@mail.gmail.com>
On 14.04.21 17:27, Ard Biesheuvel wrote:
> On Wed, 14 Apr 2021 at 17:14, David Hildenbrand <david@redhat.com> wrote:
>>
>> On 07.04.21 19:26, Mike Rapoport wrote:
>>> From: Mike Rapoport <rppt@linux.ibm.com>
>>>
>>> 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)
Using generically sounding NOMAP ("don't create direct mapping") to
identify device regions feels like a hack. I know, it was introduced
just for that purpose.
Looking at memblock_mark_nomap(), we consider "device regions"
1) ACPI tables
2) VIDEO_TYPE_EFI memory
3) some device-tree regions in of/fdt.c
IIUC, right now we end up creating a memmap for this NOMAP memory, but
hide it away in pfn_valid(). This patch set at least fixes that.
Assuming these pages are never mapped to user space via the struct page
(which better be the case), we could further use a new pagetype to mark
these pages in a special way, such that we can identify them directly
via pfn_to_page().
Then, we could mostly avoid having to query memblock at runtime to
figure out that this is special memory. This would obviously be an
extension to this series. Just a thought.
--
Thanks,
David / dhildenb
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
WARNING: multiple messages have this Message-ID (diff)
From: David Hildenbrand <david@redhat.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Mike Rapoport <rppt@kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Anshuman Khandual <anshuman.khandual@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Marc Zyngier <maz@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Mike Rapoport <rppt@linux.ibm.com>, Will Deacon <will@kernel.org>,
kvmarm <kvmarm@lists.cs.columbia.edu>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Memory Management List <linux-mm@kvack.org>
Subject: Re: [RFC/RFT PATCH 1/3] memblock: update initialization of reserved pages
Date: Wed, 14 Apr 2021 17:52:57 +0200 [thread overview]
Message-ID: <3811547a-9057-3c80-3805-2e658488ac99@redhat.com> (raw)
In-Reply-To: <CAMj1kXGw97epyP2HdHjA8Yp6+VF1j5xmd0AgVBBv3k+h_B610w@mail.gmail.com>
On 14.04.21 17:27, Ard Biesheuvel wrote:
> On Wed, 14 Apr 2021 at 17:14, David Hildenbrand <david@redhat.com> wrote:
>>
>> On 07.04.21 19:26, Mike Rapoport wrote:
>>> From: Mike Rapoport <rppt@linux.ibm.com>
>>>
>>> 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)
Using generically sounding NOMAP ("don't create direct mapping") to
identify device regions feels like a hack. I know, it was introduced
just for that purpose.
Looking at memblock_mark_nomap(), we consider "device regions"
1) ACPI tables
2) VIDEO_TYPE_EFI memory
3) some device-tree regions in of/fdt.c
IIUC, right now we end up creating a memmap for this NOMAP memory, but
hide it away in pfn_valid(). This patch set at least fixes that.
Assuming these pages are never mapped to user space via the struct page
(which better be the case), we could further use a new pagetype to mark
these pages in a special way, such that we can identify them directly
via pfn_to_page().
Then, we could mostly avoid having to query memblock at runtime to
figure out that this is special memory. This would obviously be an
extension to this series. Just a thought.
--
Thanks,
David / dhildenb
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-04-14 15:54 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-07 17:26 [RFC/RFT PATCH 0/3] arm64: drop pfn_valid_within() and simplify pfn_valid() Mike Rapoport
2021-04-07 17:26 ` Mike Rapoport
2021-04-07 17:26 ` Mike Rapoport
2021-04-07 17:26 ` [RFC/RFT PATCH 1/3] memblock: update initialization of reserved pages Mike Rapoport
2021-04-07 17:26 ` Mike Rapoport
2021-04-07 17:26 ` Mike Rapoport
2021-04-08 5:16 ` Anshuman Khandual
2021-04-08 5:16 ` Anshuman Khandual
2021-04-08 5:16 ` Anshuman Khandual
2021-04-08 5:48 ` Mike Rapoport
2021-04-08 5:48 ` Mike Rapoport
2021-04-08 5:48 ` Mike Rapoport
2021-04-14 15:12 ` David Hildenbrand
2021-04-14 15:12 ` David Hildenbrand
2021-04-14 15:12 ` David Hildenbrand
2021-04-14 15:27 ` Ard Biesheuvel
2021-04-14 15:27 ` Ard Biesheuvel
2021-04-14 15:27 ` Ard Biesheuvel
2021-04-14 15:27 ` Ard Biesheuvel
2021-04-14 15:52 ` David Hildenbrand [this message]
2021-04-14 15:52 ` David Hildenbrand
2021-04-14 15:52 ` David Hildenbrand
2021-04-14 20:24 ` Mike Rapoport
2021-04-14 20:24 ` Mike Rapoport
2021-04-14 20:24 ` Mike Rapoport
2021-04-15 9:30 ` David Hildenbrand
2021-04-15 9:30 ` David Hildenbrand
2021-04-15 9:30 ` David Hildenbrand
2021-04-16 11:44 ` Mike Rapoport
2021-04-16 11:44 ` Mike Rapoport
2021-04-16 11:44 ` Mike Rapoport
2021-04-16 11:54 ` David Hildenbrand
2021-04-16 11:54 ` David Hildenbrand
2021-04-16 11:54 ` David Hildenbrand
2021-04-14 20:11 ` Mike Rapoport
2021-04-14 20:11 ` Mike Rapoport
2021-04-14 20:11 ` Mike Rapoport
2021-04-14 20:06 ` Mike Rapoport
2021-04-14 20:06 ` Mike Rapoport
2021-04-14 20:06 ` Mike Rapoport
2021-04-14 20:09 ` David Hildenbrand
2021-04-14 20:09 ` David Hildenbrand
2021-04-07 17:26 ` [RFC/RFT PATCH 2/3] arm64: decouple check whether pfn is normal memory from pfn_valid() Mike Rapoport
2021-04-07 17:26 ` Mike Rapoport
2021-04-07 17:26 ` Mike Rapoport
2021-04-08 5:14 ` Anshuman Khandual
2021-04-08 5:14 ` Anshuman Khandual
2021-04-08 5:14 ` Anshuman Khandual
2021-04-08 6:00 ` Mike Rapoport
2021-04-08 6:00 ` Mike Rapoport
2021-04-08 6:00 ` Mike Rapoport
2021-04-14 15:58 ` David Hildenbrand
2021-04-14 15:58 ` David Hildenbrand
2021-04-14 15:58 ` David Hildenbrand
2021-04-14 20:29 ` Mike Rapoport
2021-04-14 20:29 ` Mike Rapoport
2021-04-14 20:29 ` Mike Rapoport
2021-04-15 9:31 ` David Hildenbrand
2021-04-15 9:31 ` David Hildenbrand
2021-04-15 9:31 ` David Hildenbrand
2021-04-16 11:40 ` Mike Rapoport
2021-04-16 11:40 ` Mike Rapoport
2021-04-16 11:40 ` Mike Rapoport
2021-04-07 17:26 ` [RFC/RFT PATCH 3/3] arm64: drop pfn_valid_within() and simplify pfn_valid() Mike Rapoport
2021-04-07 17:26 ` Mike Rapoport
2021-04-07 17:26 ` Mike Rapoport
2021-04-08 5:12 ` Anshuman Khandual
2021-04-08 5:12 ` Anshuman Khandual
2021-04-08 5:12 ` Anshuman Khandual
2021-04-08 6:17 ` Mike Rapoport
2021-04-08 6:17 ` Mike Rapoport
2021-04-08 6:17 ` Mike Rapoport
2021-04-08 5:19 ` [RFC/RFT PATCH 0/3] " Anshuman Khandual
2021-04-08 5:19 ` Anshuman Khandual
2021-04-08 5:19 ` Anshuman Khandual
2021-04-08 6:27 ` Mike Rapoport
2021-04-08 6:27 ` Mike Rapoport
2021-04-08 6:27 ` Mike Rapoport
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3811547a-9057-3c80-3805-2e658488ac99@redhat.com \
--to=david@redhat.com \
--cc=anshuman.khandual@arm.com \
--cc=ardb@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=rppt@kernel.org \
--cc=rppt@linux.ibm.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.