Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp738428ybl; Tue, 13 Aug 2019 01:42:31 -0700 (PDT) X-Google-Smtp-Source: APXvYqxrZUkrFYVy8pmy32Mls2JBs/NprKY2tkNuVRSQtLIOLp17QZjh395gcel7f55kA+CZ9nLG X-Received: by 2002:a17:902:b202:: with SMTP id t2mr8761666plr.303.1565685751672; Tue, 13 Aug 2019 01:42:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565685751; cv=none; d=google.com; s=arc-20160816; b=lEeKx5q5Cq+PpQuMbBfNHomM7zdBTgj+UhAqmAruF18jYPdEKLTlGFjfqLU7SNwOGx YzT0uAVMgu6JtzdbjQ/DP58ti7ljCh8aXFr3GQVOYHF8RJCs15r4K7e4rWLujCheDDYo g7FetBi+JIUIHvJr4yDryMDmF0kVjgtBk+RJowaMeI4by7J8W+AD5sud+Mqttxh0pA1X nUNKn5ixJ121XxHQdT+VbAabhoC5Ygq6869pe8lbV91cfhR95HlR+2mjqvPz7NaAPCRi mFcfm1tFyX/Bb1hPJs+IW4L5VVCh2ldyPzX6in8KzwHFtYG7Py+3GD6H7txyQ+2NpUyJ dX3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=kCmBiJ0kCEzEIDZtsH26fXgwFDBAorRDLIt0W+si88A=; b=dVTWhETEZE09t0wjzpXkGH9CedsGGXreLW/A5736ltgUYJp7krWEtfNp7IwuTvA1xE 9AZvxjGncumi6mOgnxf65I8JO/WmyukAYbxLsUtvh0WZDq8LpboLD5zNzQipA2iweaS4 GFQZbVTRI3z2G1RnD2faerdqiqEIfOo8sBNpE4cMxPy6gGN5YiKFXd3W3XTwV4a/fIZk BTabzZHX2uOfCoOaBDQa4b9f+ceNgvjqaQnzq2g0IZ5zCRjeWL6Ei4Kgvs0dKjjpmrma EXHTu/78cXu3Q1oKhxk8gsczoaabDFENNT/K0V4wSmq0zHwUQJeMl8GZtaY2znlShwQo 8hyw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="AZA3B/v1"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o3si34230461plb.238.2019.08.13.01.42.15; Tue, 13 Aug 2019 01:42:31 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="AZA3B/v1"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727223AbfHMGEx (ORCPT + 99 others); Tue, 13 Aug 2019 02:04:53 -0400 Received: from mail-qk1-f195.google.com ([209.85.222.195]:45263 "EHLO mail-qk1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725815AbfHMGEx (ORCPT ); Tue, 13 Aug 2019 02:04:53 -0400 Received: by mail-qk1-f195.google.com with SMTP id m2so4978757qki.12 for ; Mon, 12 Aug 2019 23:04:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=kCmBiJ0kCEzEIDZtsH26fXgwFDBAorRDLIt0W+si88A=; b=AZA3B/v1Xtb9RwFK5FrEZ1HH/uPKBwg6B249Hgj8mRlr+RjXmOu31q/faX9H3fqrZk t4Dq0wYMAjBkvKAZLHVXKA3nUo6J3FnpxqZWgNzZaLEcOQ3kVovOmDmHR9WXXltUq42W Bwt0g0WvZRkXKlUvms8qz0IbkWQHlrjt+tmGMKyYfRHhEGsjityf/VCI7LXmLTQpDq6o WACJQi3YKIPho2UFt/ZodbCBZ/np8GkDDLWF/YMJMTARaVmCTH+lYO7ZJbv5bTRaSQGi Q5mh1YVkwVI3dpLzIVX7iPYvvjVIdUqQqWcVY8XvGEPkyFuLAW2T9W6yJAtEVKuBx9bv WPCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=kCmBiJ0kCEzEIDZtsH26fXgwFDBAorRDLIt0W+si88A=; b=tQUNkBUEdjqWcCzc+Sy7Y6l9n1DfcTv0FmyNVGREaLRSnFPsGrRXwhC6/CGS2cvkAD IrjacfVpYJkHC5XlRtywDZMadJp2zanNvJob5TX87vGKzHm7IH+3fdCJNfLn2IkiTRRT HGbinBRkoVRqKROLUH1cAfCwn96qa+d/u4D3TI+dl3PdtmZPjtAI94cXTzgL+vERjOco XpSTBKPd6CcwYsCQUioaPsFKRZ09c++pb+RIX5rAJ/EuDgmSvUrKKJeXCIEesO5bzJqo I9lF2dmQq5rFLnEdvLXQPhSdHkxDnjPPDRyVmTw/dFkwAMuxGIsTUw+Kt+SDGgmOMSKT Ngpg== X-Gm-Message-State: APjAAAXIu9/tqkowJbW4OusX4+IPRoLbmTDRuHn3tNBdmsTBPZ7tbV3j AF9QUoutHH8IzJHdNDJZNnCCNsEAEx5CdR46QMI= X-Received: by 2002:a05:620a:696:: with SMTP id f22mr27745166qkh.232.1565676291623; Mon, 12 Aug 2019 23:04:51 -0700 (PDT) MIME-Version: 1.0 References: <20190109203911.7887-1-logang@deltatee.com> <20190109203911.7887-3-logang@deltatee.com> <0926a261-520e-4c40-f926-ddd40bb8ce44@deltatee.com> <96156909-1453-d487-ff66-a041d67c74d6@deltatee.com> In-Reply-To: <96156909-1453-d487-ff66-a041d67c74d6@deltatee.com> From: Greentime Hu Date: Tue, 13 Aug 2019 14:04:14 +0800 Message-ID: Subject: Re: [PATCH v4 2/2] RISC-V: Implement sparsemem To: Logan Gunthorpe Cc: greentime.hu@sifive.com, paul.walmsley@sifive.com, Rob Herring , Albert Ou , Andrew Waterman , Palmer Dabbelt , Linux Kernel Mailing List , Stephen Bates , Olof Johansson , linux-riscv@lists.infradead.org, Michael Clark , Christoph Hellwig Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Logan, Logan Gunthorpe =E6=96=BC 2019=E5=B9=B48=E6=9C=8812= =E6=97=A5 =E9=80=B1=E4=B8=80 =E4=B8=8B=E5=8D=8811:52=E5=AF=AB=E9=81=93=EF= =BC=9A > > > > On 2019-08-11 10:01 p.m., Greentime Hu wrote: > > Hi Logan, > > > > Logan Gunthorpe =E6=96=BC 2019=E5=B9=B48=E6=9C=88= 10=E6=97=A5 =E9=80=B1=E5=85=AD =E4=B8=8A=E5=8D=883:03=E5=AF=AB=E9=81=93=EF= =BC=9A > >> > >> > >> > >> On 2019-08-09 11:01 a.m., Greentime Hu wrote: > >>> Hi Logan, > >>> > >>> Logan Gunthorpe =E6=96=BC 2019=E5=B9=B48=E6=9C= =889=E6=97=A5 =E9=80=B1=E4=BA=94 =E4=B8=8B=E5=8D=8811:47=E5=AF=AB=E9=81=93= =EF=BC=9A > >>>> > >>>> > >>>> > >>>> On 2019-08-08 10:23 p.m., Greentime Hu wrote: > >>>>> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > >>>>> index 3f12b069af1d..208b3e14ccd8 100644 > >>>>> --- a/arch/riscv/Kconfig > >>>>> +++ b/arch/riscv/Kconfig > >>>>> @@ -116,7 +116,8 @@ config PGTABLE_LEVELS > >>>>> default 2 > >>>>> > >>>>> config HAVE_ARCH_PFN_VALID > >>>>> - def_bool y > >>>>> + bool > >>>>> + default !SPARSEMEM_VMEMMAP > >>>>> > >>>>> menu "Platform type" > >>>>> > >>>>> diff --git a/arch/riscv/include/asm/page.h b/arch/riscv/include/asm= /page.h > >>>>> index 8ddb6c7fedac..6991f7a5a4a7 100644 > >>>>> --- a/arch/riscv/include/asm/page.h > >>>>> +++ b/arch/riscv/include/asm/page.h > >>>>> @@ -93,16 +93,20 @@ extern unsigned long min_low_pfn; > >>>>> #define virt_to_pfn(vaddr) (phys_to_pfn(__pa(vaddr))) > >>>>> #define pfn_to_virt(pfn) (__va(pfn_to_phys(pfn))) > >>>>> > >>>>> +#if !defined(CONFIG_SPARSEMEM_VMEMMAP) > >>>>> +#define pfn_valid(pfn) \ > >>>>> + (((pfn) >=3D pfn_base) && (((pfn)-pfn_base) < max_mapnr)) > >>>>> #define virt_to_page(vaddr) (pfn_to_page(virt_to_pfn(vaddr))) > >>>>> #define page_to_virt(page) (pfn_to_virt(page_to_pfn(page))) > >>>>> +#else > >>>>> +#define virt_to_page(vaddr) ((struct page *)((((u64)vaddr - > >>>>> va_pa_offset) / PAGE_SIZE) * sizeof(struct page) + VMEMMAP_START)) > >>>>> +#define page_to_virt(pg) ((void *)(((((u64)pg - VMEMMAP_STAR= T) / > >>>>> sizeof(struct page)) * PAGE_SIZE) + va_pa_offset)) > >>>>> +#endif > >>>> > >>>> This doesn't make sense to me at all. It should always use pfn_to_pa= ge() > >>>> for virt_to_page() and the generic pfn_to_page()/page_to_pfn() > >>>> implementations essentially already do what you are doing in a clean= er > >>>> way. So I'd be really surprised if this does anything at all. > >>>> > >>> > >>> Thank you for point me out that. I just checked the generic > >>> implementation and I should use that one. > >>> Sorry I didn't check the generic one and just implement it again. > >>> I think the only patch we need is the first part to use generic > >>> pfn_valid(). I just tested it and yes it can boot successfully in dts > >>> with hole. > >>> > >>> It will fail in this check ((pfn)-pfn_base) < max_mapnr. > >> > >> Sounds to me like max_mapnr is not set correctly. See the code in > >> setup_bootmem(). Seems like 'mem_size' should be set to the largest > >> memory block, not just the one that contains the kernel... > >> > >> > >>> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > >>> index 3f12b069af1d..208b3e14ccd8 100644 > >>> --- a/arch/riscv/Kconfig > >>> +++ b/arch/riscv/Kconfig > >>> @@ -116,7 +116,8 @@ config PGTABLE_LEVELS > >>> default 2 > >>> > >>> config HAVE_ARCH_PFN_VALID > >>> - def_bool y > >>> + bool > >>> + default !SPARSEMEM_VMEMMAP > >>> > >>> menu "Platform type" > >>> > >>> diff --git a/arch/riscv/include/asm/page.h b/arch/riscv/include/asm/p= age.h > >>> index 8ddb6c7fedac..80d28fa1e2eb 100644 > >>> --- a/arch/riscv/include/asm/page.h > >>> +++ b/arch/riscv/include/asm/page.h > >>> @@ -100,8 +100,10 @@ extern unsigned long min_low_pfn; > >>> #define page_to_bus(page) (page_to_phys(page)) > >>> #define phys_to_page(paddr) (pfn_to_page(phys_to_pfn(paddr))) > >>> > >>> +#if !defined(CONFIG_SPARSEMEM_VMEMMAP) > >>> #define pfn_valid(pfn) \ > >>> (((pfn) >=3D pfn_base) && (((pfn)-pfn_base) < max_mapnr)) > >>> +#endif > >>> > >>> #define ARCH_PFN_OFFSET (pfn_base) > >> > >> > >> This patch still makes no sense. I'm not sure why we have an arch > >> specific pfn_valid() because it's very similar to the generic one. But > >> my guess is there's a reason for it and it's not doing what it is > >> supposed when you remove it for the sparsemem case. > > > > It will use another pfn_valid() implementation in > > include/linux/mmzone.h if CONFIG_SPARSEMEM and > > !CONFIG_HAVE_ARCH_PFN_VALID > > It will be this one. > > > > static inline int pfn_valid(unsigned long pfn) > > { > > if (pfn_to_section_nr(pfn) >=3D NR_MEM_SECTIONS) > > return 0; > > return valid_section(__nr_to_section(pfn_to_section_nr(pfn))); > > } > > Ah, ok I see. "page.h" is only included in no-mmu arches. Which explains > why riscv re-implements that macro. Couple follow up questions then: > > * Did you test the memory-with-hole scenario without the sparsemem > patches? It seems pfn_valid() will be wrong regardless of sparse/flat mem= . > > * Any chance we can just use the generic pfn_valid() function in all > cases not just sparsemem? Can you test that? > I think flat mem doesn't support memory-with-hole scenario. In mm/Kconfig, it says " For systems that have holes in their physical address spaces and for features like NUMA and memory hotplug, choose "Sparse Memory" " IMHO, the memory-with-hole scenario should only be tested for sparse mem but flat mem. The generic pfn_valid() is just for non-mmu arches. Every architecture with mmu defines their own pfn_valid(). This is supposed to be another separate patch that do we need to implement a generic pfn_valid().