MAX_PHYSMEM_BITS cannot be changed for that because the randomization
does not align with address bit boundaries and there are other places
which actually require to know the maximum number of address bits. All
remaining usage sites of MAX_PHYSMEM_BITS have been analyzed and found
to be correct.
Hi Thomas,
Cure this by exposing the end of the direct map via PHYSMEM_END and use
that for the memory hot-plug and resource management related places
instead of relying on MAX_PHYSMEM_BITS. In the KASLR case PHYSMEM_END
maps to a variable which is initialized by the KASLR initialization and
otherwise it is based on MAX_PHYSMEM_BITS as before.
Skimming this patch, I got confused why physmem_end is introduced.
I can see a single modification of physmem_end:
physmem_end = ((1ULL << MAX_PHYSMEM_BITS) - 1);
Which is exactly the same as
#ifndef PHYSMEM_END
# define PHYSMEM_END ((1ULL << MAX_PHYSMEM_BITS) - 1)
#endif
And that left me confused why that is required. So we can catch the
transition "physmem_end == 0" -> "physmem_end != 0"?
I'm probably missing something important, so sorry for the (likely)
stupid question.
Apart from that, nothing jumped at me.
--
Cheers,
David / dhildenb
