From: ard.biesheuvel@linaro.org (Ard Biesheuvel)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/8] arm64: improved memory map handling for /dev/mem, ACPI etc
Date: Mon, 22 Dec 2014 19:08:34 +0000 [thread overview]
Message-ID: <1419275322-29811-1-git-send-email-ard.biesheuvel@linaro.org> (raw)
This series was split off from the UEFI virtmap for kexec series that I posted
earlier today. The main purpose is to deal with the need to classify memory
ranges as RAM or non-RAM in a consistent and comprehensive manner. This series
applies on top of the other series.
Patch #1 avoids an early panic if the UEFI memory map is available but UEFI
support itself fails to initialize. In this case, there is no need to panic
early, and we have a better chance of being able to inform the user if we deal
with this error condition at a later time.
Patch #2 adds iomem resource registration of UEFI memory regions. This is
necessary because otherwise, drivers could potentially claim regions that
are in active use by the firmware. This applies to both MMIO (NOR flash, RTC)
and RAM ranges (runtime services code and data).
Patch #3-6 adds support to UEFI and non-UEFI code paths to record all memory
known to the system in the 'physmem' memblock table (if enabled). This fulfils
a need in the /dev/mem and (upcoming) ACPI layers to be able to classify ranges
as being backed by normal RAM even if they are not covered by the 'memory'
memblock table, and are hence not covered by the linear direct mapping.
The physmem code is pre-existing code that only needs minor tweaking to be made
suitable for this purpose.
Patch #7 enables the 'physmem' memblock table for arm64, and wires it into the
handling of /dev/mem mappings, both to decide whether it should be mapped as
MT_NORMAL, and whether read-write access can be allowed. (Non-RAM regions can
be mapped read-write as long as they are not claimed by a driver in the iomem
resource table. RAM regions can only be mapped read-only, and only if they are
not covered by the 'memory' memblock table, and hence not covered by the linear
mapping)
Finally, patch #8 changes the way the virtual memory map is handled by the
early UEFI code. Specifically, it memblock_remove()s rather than _reserves()
UEFI reserved RAM regions, so that they are removed entirely from the linear
mapping.
Ard Biesheuvel (8):
arm64/efi: use UEFI memory map unconditionally if available
arm64/efi: register UEFI reserved regions as iomem resources
memblock: add physmem to memblock_dump_all() output
memblock: introduce memblock_add_phys() and memblock_is_physmem()
of: fdt: register physmem in early_init_dt_scan_memory()
arm64/efi: register physmem in reserve_regions()
arm64: use 'physmem' memblock to improve CONFIG_STRICT_DEVMEM handling
arm64/efi: memblock_remove rather than _reserve UEFI reserved RAM
arch/arm64/Kconfig | 1 +
arch/arm64/kernel/efi.c | 82 +++++++++++++++++++++++++++++++++++++++---------
arch/arm64/mm/mmap.c | 2 +-
arch/arm64/mm/mmu.c | 15 ++++++++-
drivers/of/fdt.c | 1 +
include/linux/memblock.h | 10 ++++++
mm/memblock.c | 18 +++++++++++
7 files changed, 113 insertions(+), 16 deletions(-)
--
1.8.3.2
next reply other threads:[~2014-12-22 19:08 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-22 19:08 Ard Biesheuvel [this message]
2014-12-22 19:08 ` [PATCH 1/8] arm64/efi: use UEFI memory map unconditionally if available Ard Biesheuvel
2015-01-06 9:04 ` Matt Fleming
2015-01-07 11:48 ` Ard Biesheuvel
2015-01-12 10:46 ` Matt Fleming
2015-01-09 15:41 ` Will Deacon
2014-12-22 19:08 ` [PATCH 2/8] arm64/efi: register UEFI reserved regions as iomem resources Ard Biesheuvel
2015-01-06 9:13 ` Matt Fleming
2015-01-07 11:53 ` Ard Biesheuvel
2014-12-22 19:08 ` [PATCH 3/8] memblock: add physmem to memblock_dump_all() output Ard Biesheuvel
2015-01-06 9:15 ` Matt Fleming
2014-12-22 19:08 ` [PATCH 4/8] memblock: introduce memblock_add_phys() and memblock_is_physmem() Ard Biesheuvel
2015-01-06 9:19 ` Matt Fleming
2014-12-22 19:08 ` [PATCH 5/8] of: fdt: register physmem in early_init_dt_scan_memory() Ard Biesheuvel
2014-12-22 19:08 ` [PATCH 6/8] arm64/efi: register physmem in reserve_regions() Ard Biesheuvel
2014-12-22 19:08 ` [PATCH 7/8] arm64: use 'physmem' memblock to improve CONFIG_STRICT_DEVMEM handling Ard Biesheuvel
2015-01-09 15:38 ` Will Deacon
2014-12-22 19:08 ` [PATCH 8/8] arm64/efi: memblock_remove rather than _reserve UEFI reserved RAM Ard Biesheuvel
2014-12-26 9:35 ` [PATCH 0/8] arm64: improved memory map handling for /dev/mem, ACPI etc Dave Young
2014-12-29 9:22 ` Ard Biesheuvel
2014-12-30 9:25 ` Dave Young
2014-12-30 13:21 ` Ard Biesheuvel
2015-01-04 8:19 ` Dave Young
2015-01-05 9:18 ` Ard Biesheuvel
2015-01-06 8:16 ` Dave Young
2015-01-07 11:41 ` Ard Biesheuvel
2015-01-08 1:29 ` Dave Young
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=1419275322-29811-1-git-send-email-ard.biesheuvel@linaro.org \
--to=ard.biesheuvel@linaro.org \
--cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).