All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sven Schnelle <svens@stackframe.org>
To: Steven Price <steven.price@arm.com>
Cc: "Anshuman Khandual" <anshuman.khandual@arm.com>,
	linux-mm@kvack.org, "Helge Deller" <deller@gmx.de>,
	"Mark Rutland" <Mark.Rutland@arm.com>,
	x86@kernel.org, "Arnd Bergmann" <arnd@arndb.de>,
	"Ard Biesheuvel" <ard.biesheuvel@linaro.org>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Dave Hansen" <dave.hansen@linux.intel.com>,
	linux-kernel@vger.kernel.org,
	"Jérôme Glisse" <jglisse@redhat.com>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Borislav Petkov" <bp@alien8.de>,
	"Andy Lutomirski" <luto@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"James Morse" <james.morse@arm.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Will Deacon" <will@kernel.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	linux-arm-kernel@lists.infradead.org, "Liang,
	Kan" <kan.liang@linux.intel.com>
Subject: Re: [PATCH v9 00/21] Generic page walk and ptdump
Date: Wed, 31 Jul 2019 11:27:03 +0200	[thread overview]
Message-ID: <20190731092703.GA31316@t470p.stackframe.org> (raw)
In-Reply-To: <270ce719-49f9-7c61-8b25-bc9548a2f478@arm.com>

Hi Steven,

On Mon, Jul 29, 2019 at 12:32:25PM +0100, Steven Price wrote:
> 
> parisc is more interesting and I'm not sure if this is necessarily
> correct. I originally proposed a patch with the line "For parisc, we
> don't support large pages, so add stubs returning 0" which got Acked by
> Helge Deller. However going back to look at that again I see there was a
> follow up thread[2] which possibly suggests I was wrong?

I just started a week ago implementing ptdump for PA-RISC. Didn't notice that
you're working on making it generic, which is nice. I'll adjust my code
to use the infrastructure you're currently developing.

> Can anyone shed some light on whether parisc does support leaf entries
> of the page table tree at a higher than the normal depth?
> 
> [1] https://lkml.org/lkml/2019/2/27/572
> [2] https://lkml.org/lkml/2019/3/5/610

My understanding is that PA-RISC only has leaf entries on PTE level.

> The intention is that the page table walker would be available for all
> architectures so that it can be used in any generic code - PTDUMP simply
> seemed like a good place to start.
> 
> > Now that pmd_leaf() and pud_leaf() are getting used in walk_page_range() these
> > functions need to be defined on all arch irrespective if they use PTDUMP or not
> > or otherwise just define it for archs which need them now for sure i.e x86 and
> > arm64 (which are moving to new generic PTDUMP framework). Other archs can
> > implement these later.

I'll take care of the PA-RISC part - for 32 bit your generic code works, for 64Bit
i need to learn a bit more about the following hack:

arch/parisc/include/asm/pgalloc.h:15
/* Allocate the top level pgd (page directory)
 *
 * Here (for 64 bit kernels) we implement a Hybrid L2/L3 scheme: we
 * allocate the first pmd adjacent to the pgd.  This means that we can
 * subtract a constant offset to get to it.  The pmd and pgd sizes are
 * arranged so that a single pmd covers 4GB (giving a full 64-bit
 * process access to 8TB) so our lookups are effectively L2 for the
 * first 4GB of the kernel (i.e. for all ILP32 processes and all the
 * kernel for machines with under 4GB of memory)
 */

I see that your change clear P?D entries when p?d_bad() returns true, which - i think -
would be the case with the PA-RISC implementation.

Regards
Sven

WARNING: multiple messages have this Message-ID (diff)
From: Sven Schnelle <svens@stackframe.org>
To: Steven Price <steven.price@arm.com>
Cc: "Mark Rutland" <Mark.Rutland@arm.com>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Dave Hansen" <dave.hansen@linux.intel.com>,
	linux-mm@kvack.org, "H. Peter Anvin" <hpa@zytor.com>,
	"Will Deacon" <will@kernel.org>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	"Helge Deller" <deller@gmx.de>,
	x86@kernel.org, "Ingo Molnar" <mingo@redhat.com>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Anshuman Khandual" <anshuman.khandual@arm.com>,
	"Jérôme Glisse" <jglisse@redhat.com>,
	"Borislav Petkov" <bp@alien8.de>,
	"Andy Lutomirski" <luto@kernel.org>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	linux-arm-kernel@lists.infradead.org,
	"Ard Biesheuvel" <ard.biesheuvel@linaro.org>,
	linux-kernel@vger.kernel.org, "James Morse" <james.morse@arm.com>,
	"Andrew Morton" <akpm@linux-foundation.org>
Subject: Re: [PATCH v9 00/21] Generic page walk and ptdump
Date: Wed, 31 Jul 2019 11:27:03 +0200	[thread overview]
Message-ID: <20190731092703.GA31316@t470p.stackframe.org> (raw)
In-Reply-To: <270ce719-49f9-7c61-8b25-bc9548a2f478@arm.com>

Hi Steven,

On Mon, Jul 29, 2019 at 12:32:25PM +0100, Steven Price wrote:
> 
> parisc is more interesting and I'm not sure if this is necessarily
> correct. I originally proposed a patch with the line "For parisc, we
> don't support large pages, so add stubs returning 0" which got Acked by
> Helge Deller. However going back to look at that again I see there was a
> follow up thread[2] which possibly suggests I was wrong?

I just started a week ago implementing ptdump for PA-RISC. Didn't notice that
you're working on making it generic, which is nice. I'll adjust my code
to use the infrastructure you're currently developing.

> Can anyone shed some light on whether parisc does support leaf entries
> of the page table tree at a higher than the normal depth?
> 
> [1] https://lkml.org/lkml/2019/2/27/572
> [2] https://lkml.org/lkml/2019/3/5/610

My understanding is that PA-RISC only has leaf entries on PTE level.

> The intention is that the page table walker would be available for all
> architectures so that it can be used in any generic code - PTDUMP simply
> seemed like a good place to start.
> 
> > Now that pmd_leaf() and pud_leaf() are getting used in walk_page_range() these
> > functions need to be defined on all arch irrespective if they use PTDUMP or not
> > or otherwise just define it for archs which need them now for sure i.e x86 and
> > arm64 (which are moving to new generic PTDUMP framework). Other archs can
> > implement these later.

I'll take care of the PA-RISC part - for 32 bit your generic code works, for 64Bit
i need to learn a bit more about the following hack:

arch/parisc/include/asm/pgalloc.h:15
/* Allocate the top level pgd (page directory)
 *
 * Here (for 64 bit kernels) we implement a Hybrid L2/L3 scheme: we
 * allocate the first pmd adjacent to the pgd.  This means that we can
 * subtract a constant offset to get to it.  The pmd and pgd sizes are
 * arranged so that a single pmd covers 4GB (giving a full 64-bit
 * process access to 8TB) so our lookups are effectively L2 for the
 * first 4GB of the kernel (i.e. for all ILP32 processes and all the
 * kernel for machines with under 4GB of memory)
 */

I see that your change clear P?D entries when p?d_bad() returns true, which - i think -
would be the case with the PA-RISC implementation.

Regards
Sven

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-07-31  9:27 UTC|newest]

Thread overview: 129+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-22 15:41 [PATCH v9 00/21] Generic page walk and ptdump Steven Price
2019-07-22 15:41 ` Steven Price
2019-07-22 15:41 ` [PATCH v9 01/21] arc: mm: Add p?d_leaf() definitions Steven Price
2019-07-22 15:41   ` Steven Price
2019-07-22 15:41   ` Steven Price
2019-07-22 15:41 ` [PATCH v9 02/21] arm: " Steven Price
2019-07-22 15:41   ` Steven Price
2019-07-22 15:41 ` [PATCH v9 03/21] arm64: " Steven Price
2019-07-22 15:41   ` Steven Price
2019-07-22 15:41 ` [PATCH v9 04/21] mips: " Steven Price
2019-07-22 15:41   ` Steven Price
2019-07-22 21:47   ` Paul Burton
2019-07-22 21:47     ` Paul Burton
2019-07-24 13:03     ` Steven Price
2019-07-24 13:03       ` Steven Price
2019-07-22 15:41 ` [PATCH v9 05/21] powerpc: " Steven Price
2019-07-22 15:41   ` Steven Price
2019-07-22 15:41   ` Steven Price
2019-07-22 15:41   ` Steven Price
2019-07-22 15:41 ` [PATCH v9 06/21] riscv: " Steven Price
2019-07-22 15:41   ` Steven Price
2019-07-22 15:41   ` Steven Price
2019-07-22 15:41 ` [PATCH v9 07/21] s390: " Steven Price
2019-07-22 15:41   ` Steven Price
2019-07-22 15:41 ` [PATCH v9 08/21] sparc: " Steven Price
2019-07-22 15:41   ` Steven Price
2019-07-22 15:41   ` Steven Price
2019-07-22 15:41 ` [PATCH v9 09/21] x86: " Steven Price
2019-07-22 15:41   ` Steven Price
2019-07-22 15:41 ` [PATCH v9 10/21] mm: Add generic p?d_leaf() macros Steven Price
2019-07-22 15:41   ` Steven Price
2019-07-23  9:41   ` Mark Rutland
2019-07-23  9:41     ` Mark Rutland
2019-07-24 13:48     ` Steven Price
2019-07-24 13:48       ` Steven Price
2019-07-28 11:44     ` Anshuman Khandual
2019-07-28 11:44       ` Anshuman Khandual
2019-07-29 11:38       ` Steven Price
2019-07-29 11:38         ` Steven Price
2019-08-01  6:09         ` Anshuman Khandual
2019-08-01  6:09           ` Anshuman Khandual
2019-08-01 12:22           ` Steven Price
2019-08-01 12:22             ` Steven Price
2019-07-29 12:50       ` Mark Rutland
2019-07-29 12:50         ` Mark Rutland
2019-08-01  6:13         ` Anshuman Khandual
2019-08-01  6:13           ` Anshuman Khandual
2019-07-22 15:42 ` [PATCH v9 11/21] mm: pagewalk: Add p4d_entry() and pgd_entry() Steven Price
2019-07-22 15:42   ` Steven Price
2019-07-23 10:14   ` Mark Rutland
2019-07-23 10:14     ` Mark Rutland
2019-07-24 13:53     ` Steven Price
2019-07-24 13:53       ` Steven Price
2019-07-24 14:09       ` Mark Rutland
2019-07-24 14:09         ` Mark Rutland
2019-07-28 12:33   ` Anshuman Khandual
2019-07-28 12:33     ` Anshuman Khandual
2019-07-29 12:17     ` Steven Price
2019-07-29 12:17       ` Steven Price
2019-07-22 15:42 ` [PATCH v9 12/21] mm: pagewalk: Allow walking without vma Steven Price
2019-07-22 15:42   ` Steven Price
2019-07-28 14:20   ` Anshuman Khandual
2019-07-28 14:20     ` Anshuman Khandual
2019-07-29 12:29     ` Steven Price
2019-07-29 12:29       ` Steven Price
2019-08-01  6:41       ` Anshuman Khandual
2019-08-01  6:41         ` Anshuman Khandual
2019-07-22 15:42 ` [PATCH v9 13/21] mm: pagewalk: Add test_p?d callbacks Steven Price
2019-07-22 15:42   ` Steven Price
2019-07-28 13:41   ` Anshuman Khandual
2019-07-28 13:41     ` Anshuman Khandual
2019-07-29 12:34     ` Steven Price
2019-07-29 12:34       ` Steven Price
2019-07-22 15:42 ` [PATCH v9 14/21] x86: mm: Don't display pages which aren't present in debugfs Steven Price
2019-07-22 15:42   ` Steven Price
2019-07-22 15:42 ` [PATCH v9 15/21] x86: mm: Point to struct seq_file from struct pg_state Steven Price
2019-07-22 15:42   ` Steven Price
2019-07-22 15:42 ` [PATCH v9 16/21] x86: mm+efi: Convert ptdump_walk_pgd_level() to take a mm_struct Steven Price
2019-07-22 15:42   ` Steven Price
2019-07-22 15:42 ` [PATCH v9 17/21] x86: mm: Convert ptdump_walk_pgd_level_debugfs() to take an mm_struct Steven Price
2019-07-22 15:42   ` Steven Price
2019-07-22 15:42 ` [PATCH v9 18/21] x86: mm: Convert ptdump_walk_pgd_level_core() " Steven Price
2019-07-22 15:42   ` Steven Price
2019-07-22 15:42 ` [PATCH v9 19/21] mm: Add generic ptdump Steven Price
2019-07-22 15:42   ` Steven Price
2019-07-23  9:57   ` Mark Rutland
2019-07-23  9:57     ` Mark Rutland
2019-07-24 16:36     ` Steven Price
2019-07-24 16:36       ` Steven Price
2019-07-29  2:59   ` Anshuman Khandual
2019-07-29  2:59     ` Anshuman Khandual
2019-07-29 13:56     ` Steven Price
2019-07-29 13:56       ` Steven Price
2019-07-22 15:42 ` [PATCH v9 20/21] x86: mm: Convert dump_pagetables to use walk_page_range Steven Price
2019-07-22 15:42   ` Steven Price
2019-07-22 15:42 ` [PATCH v9 21/21] arm64: mm: Convert mm/dump.c to use walk_page_range() Steven Price
2019-07-22 15:42   ` Steven Price
2019-07-23  6:39 ` [PATCH v9 00/21] Generic page walk and ptdump Anshuman Khandual
2019-07-23  6:39   ` Anshuman Khandual
2019-07-24 13:35   ` Steven Price
2019-07-24 13:35     ` Steven Price
2019-07-25  9:09     ` Anshuman Khandual
2019-07-25  9:09       ` Anshuman Khandual
2019-07-25  9:30       ` Will Deacon
2019-07-25  9:30         ` Will Deacon
2019-07-26  6:03         ` Anshuman Khandual
2019-07-26  6:03           ` Anshuman Khandual
2019-07-25 10:15       ` Steven Price
2019-07-25 10:15         ` Steven Price
2019-07-23 10:16 ` Mark Rutland
2019-07-23 10:16   ` Mark Rutland
2019-07-24 13:35   ` Steven Price
2019-07-24 13:35     ` Steven Price
2019-07-24 13:57     ` Thomas Gleixner
2019-07-24 13:57       ` Thomas Gleixner
2019-07-24 14:07       ` Mark Rutland
2019-07-24 14:07         ` Mark Rutland
2019-07-24 14:18       ` Steven Price
2019-07-24 14:18         ` Steven Price
2019-07-24 14:37         ` Thomas Gleixner
2019-07-24 14:37           ` Thomas Gleixner
2019-07-28 11:20 ` Anshuman Khandual
2019-07-28 11:20   ` Anshuman Khandual
2019-07-29 11:32   ` Steven Price
2019-07-29 11:32     ` Steven Price
2019-07-31  9:27     ` Sven Schnelle [this message]
2019-07-31  9:27       ` Sven Schnelle
2019-07-31 11:18       ` Steven Price
2019-07-31 11:18         ` Steven Price

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190731092703.GA31316@t470p.stackframe.org \
    --to=svens@stackframe.org \
    --cc=Mark.Rutland@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=anshuman.khandual@arm.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=arnd@arndb.de \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=deller@gmx.de \
    --cc=hpa@zytor.com \
    --cc=james.morse@arm.com \
    --cc=jglisse@redhat.com \
    --cc=kan.liang@linux.intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=steven.price@arm.com \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.