diff options
author | Kirill A. Shutemov <kirill.shutemov@linux.intel.com> | 2023-09-15 10:02:21 +0300 |
---|---|---|
committer | Ingo Molnar <mingo@kernel.org> | 2023-09-17 09:48:57 +0200 |
commit | f530ee95b72e77b09c141c4b1a4b94d1199ffbd9 (patch) | |
tree | b2119257d79e018544ac9227cd21fd65b6149bef /drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | |
parent | 7575e5a35267983dcbeb1e0d3a49d21ae3cf0b82 (diff) |
x86/boot/compressed: Reserve more memory for page tables
The decompressor has a hard limit on the number of page tables it can
allocate. This limit is defined at compile-time and will cause boot
failure if it is reached.
The kernel is very strict and calculates the limit precisely for the
worst-case scenario based on the current configuration. However, it is
easy to forget to adjust the limit when a new use-case arises. The
worst-case scenario is rarely encountered during sanity checks.
In the case of enabling 5-level paging, a use-case was overlooked. The
limit needs to be increased by one to accommodate the additional level.
This oversight went unnoticed until Aaron attempted to run the kernel
via kexec with 5-level paging and unaccepted memory enabled.
Update wost-case calculations to include 5-level paging.
To address this issue, let's allocate some extra space for page tables.
128K should be sufficient for any use-case. The logic can be simplified
by using a single value for all kernel configurations.
[ Also add a warning, should this memory run low - by Dave Hansen. ]
Fixes: 34bbb0009f3b ("x86/boot/compressed: Enable 5-level paging during decompression stage")
Reported-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20230915070221.10266-1-kirill.shutemov@linux.intel.com
Diffstat (limited to 'drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c')
0 files changed, 0 insertions, 0 deletions