lkml.org 
[lkml]   [2021]   [Sep]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [RFC] arm64: mm: update max_pfn after memory hotplug
From


On 9/23/2021 3:54 PM, Chris Goldsworthy wrote:
> From: Sudarshan Rajagopalan <quic_sudaraja@quicinc.com>
>
> After new memory blocks have been hotplugged, max_pfn and max_low_pfn
> needs updating to reflect on new PFNs being hot added to system.
>
> Signed-off-by: Sudarshan Rajagopalan <quic_sudaraja@quicinc.com>
> Signed-off-by: Chris Goldsworthy <quic_cgoldswo@quicinc.com>
> ---
> arch/arm64/mm/mmu.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index cfd9deb..fd85b51 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -1499,6 +1499,11 @@ int arch_add_memory(int nid, u64 start, u64 size,
> if (ret)
> __remove_pgd_mapping(swapper_pg_dir,
> __phys_to_virt(start), size);
> + else {
> + max_pfn = PFN_UP(start + size);
> + max_low_pfn = max_pfn;
> + }

This is a drive by review, but it got me thinking about your changes a bit:

- if you raise max_pfn when you hotplug memory, don't you need to lower
it when you hot unplug memory as well?

- suppose that you have a platform which maps physical memory into the
CPU's address space at 0x00_4000_0000 (1GB offset) and the kernel boots
with 2GB of DRAM plugged by default. At that point we have not
registered a swiotlb because we have less than 4GB of addressable
physical memory, there is no IOMMU in that system, it's a happy world.
Now assume that we plug an additional 2GB of DRAM into that system
adjacent to the previous 2GB, from 0x00_C0000_0000 through
0x14_0000_0000, now we have physical addresses above 4GB, but we still
don't have a swiotlb, some of our DMA_BIT_MASK(32) peripherals are going
to be unable to DMA from that hot plugged memory, but they could if we
had a swiotlb.

- now let's go even further but this is very contrived. Assume that the
firmware has somewhat created a reserved memory region with a 'no-map'
attribute thus indicating it does not want a struct page to be created
for a specific PFN range, is it valid to "blindly" raise max_pfn if that
region were to be at the end of the just hot-plugged memory?
--
Florian

\
 
 \ /
  Last update: 2021-09-24 04:47    [W:0.128 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site