remove UEFI reserved regions from the linear mapping
Get series with b4
b4 am 20151112155523.GD26564@leverpostejVersions newest first
- v1 Latest1 of 3 patches 0 repliesNew
1 of 3 patches is in this archive. The cover letter announces 3.
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 2/3 | arm64: reimplement page_is_ram() using memblock and UEFI memory map | +0 | 1 reply |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/3] remove UEFI reserved regions from the linear mapping
Quoted 20 lines · Ard Biesheuvel
Quoted 19 lines · Mark Rutland
Quoted 7 lines · Ard Biesheuvel
This is yet another approach to solving the issues around removing RAM regions known to UEFI from the linear mapping while preserving the record of the fact that these regions are backed by memory.
The previous approach added a memblock flag called
MEMBLOCK_NOMAPto keep track of RAM regions that should be removed from the linear mapping.Quoted 6 lines
The primary motivation for the new approach is the observation that there is only a single use case that requires this, which is
acpi_os_ioremap(). Since ACPI implies UEFI on arm64 platforms, and sinceacpi_os_ioremap()usespage_is_ram()internally (which is a__weakgeneric function), we can simply reimplementpage_is_ram()to take the UEFI memory map into account if we are booted via UEFI.Just to check, is the above the only reason for this new approach? Or were there other issues with the
MEMBLOCK_NOMAPapproach other than the diffstat?
Quoted 5 lines
Quoted 2 lines
I quite liked the
MEMBLOCK_NOMAPapproach as it looked reusable.I think the
MEMBLOCK_NOMAPapproach is sound, but it is harder to prove that there are no corner cases that behave incorrectly.
Ok.
Quoted 7 lines
Quoted 3 lines
I take it there aren't any lurking instances of
page_is_ram()used to test if something exists in the linear mapping?Well, first of all, the linear mapping only covers lowmem, so that in itself would not be a portable use. In general,
pfn_valid()would be the correct test for that (possibly combined withPageHighmem())
Good point, I hadn't considered that.
Quoted 3 lines
page_is_ram()and the 'System RAM' iomem region are so poorly defined or documented that we may be better off just removing it in the first place and replace it with something meaningful.
I'd be very much in favour of tightening up and/or replacing page_is_ram with something well-defined.
I believe that some userspace depends on the 'System RAM' info (e.g. I think kexec tools parse that to decide a good location for the next kernel), but I would expect that users want to know about _usable_ RAM rather than anything that happens to be physical RAM.
Quoted 10 lines
Quoted 7 lines
Quoted 3 lines
Patch #1 slightly reorders the UEFI runtime services initialization routines so that the
EFI_MEMMAPflag is only set if the permanent mapping of the UEFI memory map is in place.This also means that the memory map is mapped even with EFI runtime support disabled, but I guess that's not a big problem.
Yes. You need that anyway if you are going to rely on it even when the runtime services are disabled.
Not with the MEMBLOCK_NOMAP approach.
I don't have a strong case for caring about that; I only imagine that being a problem if you're trying to track down extremely nasty memory corruption / bad pointer bugs and want the bare minimum VA space mapped. Even then the impact is minimal.
Quoted 7 lines
Quoted 4 lines
As a side thought, it would be nice if we could
memremap_rothe system table and memory map in future to prevent potential corruption, given they have fixed VAs and are always mapped.I agree, and I already have some local patches using
early_memremap_ro()for the EFI init code.
Ah, nice!
Quoted 3 lines
memremap_ro()does not actually exist yet, but I intend to proposeMEMREMAP_ROandMEMREMAP_NXflags to Dan Williams'smemremap()work once I get around to it.
That sounds good; I would certainly be in favour of that.
For some reason I thought the memremap arch changes had gone in for v4.3, but I see that's not the case. I'll take a look around.
Thanks,
Mark.