Messages in this thread | | | Subject | Re: [PATCH] x86/mm: Fix boot with some memory above MAXMEM | From | Dave Hansen <> | Date | Wed, 3 Jun 2020 12:18:57 -0700 |
| |
On 6/2/20 4:18 PM, Kirill A. Shutemov wrote: > On Tue, May 26, 2020 at 07:27:15AM -0700, Dave Hansen wrote: >> On 5/25/20 8:08 AM, Kirill A. Shutemov wrote: >>>>>> + if (not_addressable) { >>>>>> + pr_err("%lldGB of physical memory is not addressable in the paging mode\n", >>>>>> + not_addressable >> 30); >>>>>> + if (!pgtable_l5_enabled()) >>>>>> + pr_err("Consider enabling 5-level paging\n"); >>>> Could this happen at all when l5 is enabled? >>>> Does it mean we need kmap() for 64-bit? >>> It's future-profing. Who knows what paging modes we would have in the >>> future. >> >> Future-proofing and firmware-proofing. :) >> >> In any case, are we *really* limited to 52 bits of physical memory with >> 5-level paging? > > Yes. It's architectural. SDM says "MAXPHYADDR is at most 52" (Vol 3A, > 4.1.4).
Right you are.
I'm glad it's in the architecture. Makes all of this a lot easier!
>> So shouldn't it technically be this: >> >> #define MAX_PHYSMEM_BITS (pgtable_l5_enabled() ? 55 : 46) >> >> ? > > Bits above 52 are ignored in the page table entries and accessible to > software. Some of them got claimed by HW features (XD-bit, protection > keys), but such features require explicit opt-in on software side. > > Kernel could claim bits 53-55 for the physical address, but it doesn't get > us anything: if future HW would provide such feature it would require > opt-in. On other hand claiming them now means we cannot use them for other > purposes as SW bit. I don't see a point.
Yep, agreed.
| |