On Thu, 2016-02-18 at 14:32 +1100, Michael Neuling wrote:
> On Wed, 2016-02-17 at 22:09 +1100, Michael Ellerman wrote:
> > On Wed, 2016-02-17 at 16:07 +1100, Michael Neuling wrote:
> >
> > > Add a cputable entry for POWER9. More code is required to actually
> > > boot and run on a POWER9 but this
On Wed, 2016-02-17 at 20:22 +0530, Aneesh Kumar K.V wrote:
> Anshuman Khandual writes:
>
> > The structure to track single virtual to physical mapping has
> > been renamed from vmemmap_backing to vmemmap_hw_map which sounds
> > more appropriate. This forms a single entry of the global linked
> >
On Wed, 2016-02-17 at 17:42 +0530, Anshuman Khandual wrote:
> Add some explaination to the layout of vmemmap virtual address
> space and how physical page mapping is only used for valid PFNs
> present at any point on the system.
>
> Signed-off-by: Anshuman Khandual
> ---
> arch/powerpc/include/
On Wed, 2016-02-17 at 17:42 +0530, Anshuman Khandual wrote:
> The commit (16a05bff1: powerpc: start loop at section start of
> start in vmemmap_populated()) reused 'start' variable to compute
> the starting address of the memory section where the given address
> belongs. Then the same variable is
On Wed, 2016-02-17 at 17:42 +0530, Anshuman Khandual wrote:
> This renames the global list which tracks all the virtual to physical
> mapping and also the global list which tracks all the available unused
> vmemmap_hw_map node structures.
But why? Why are the new names *so* much better that we wo
On Thu, 18 Feb 2016 01:58:08 +0200
"Kirill A. Shutemov" wrote:
> On Wed, Feb 17, 2016 at 08:13:40PM +0100, Gerald Schaefer wrote:
> > On Sat, 13 Feb 2016 12:58:31 +0100 (CET)
> > Sebastian Ott wrote:
> >
> > > [ 59.875935] [ cut here ]
> > > [ 59.875937] kernel BUG a
We can get a hash pte fault with 4k base page size and find the pte
already inserted with 64K base page size. In that case we need to clear
the existing slot information from the old pte. Fix this correctly
With THP, we also clear the slot information with respect to all
the 64K hash pte mapping t
On 2016-02-17 23:30, Stewart Smith wrote:
Steven Royer writes:
On 2016-02-17 16:31, Greg Kroah-Hartman wrote:
On Wed, Feb 17, 2016 at 03:18:26PM -0600, Steven Royer wrote:
On 2016-02-16 16:18, Greg Kroah-Hartman wrote:
>On Tue, Feb 16, 2016 at 02:43:13PM -0600, Steven Royer wrote:
>>From: Ste
Hello,
This is a large series, mostly consisting of code movement. No new features
are done in this series. The changes are done to accomodate the upcoming new
memory
model in future powerpc chips. The details of the new MMU model can be found at
http://ibm.biz/power-isa3 (Needs registration).
With next generation power processor, we are having a new mmu model
[1] that require us to maintain a different linux page table format.
Inorder to support both current and future ppc64 systems with a single
kernel we need to make sure kernel can select between different page
table format at runti
From: "Kirill A. Shutemov"
With next generation power processor, we are having a new mmu model
[1] that require us to maintain a different linux page table format.
Inorder to support both current and future ppc64 systems with a single
kernel we need to make sure kernel can select between differe
The difference between 64K and 4K hash fault handling is confusing
with respect to when we set _PAGE_HASHPTE in the linux pte.
I was trying to find out whether we miss a hpte flush in any
scenario because of this. ie, a pte update on a linux pte, for which we
are doing a parallel hash pte insert. A
We move the page table accessors into a separate header. We will
later add a big endian variant of the table which is needed for radix.
No functionality change only code movement.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/page.h | 104 +
ar
We remove real_pte_t out of STRICT_MM_TYPESCHECK.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/book3s/64/pgtable.h | 5 -
arch/powerpc/include/asm/pgtable-types.h | 26 +-
2 files changed, 9 insertions(+), 22 deletions(-)
diff --git a/arch/powerp
This is needed so that we can support both hash and radix page table
using single kernel. Radix kernel uses a 4 level table.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/book3s/64/hash-4k.h | 33 +--
a
This patch make a copy of pgalloc routines for book3s. The idea is to
enable a hash64 copy of these pgalloc routines which can be later
updated to have a radix conditional. Radix introduce a new page table
format with different page table size.
This mostly does:
cp pgalloc-32.h book3s/32/pgalloc.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/book3s/32/pgalloc.h | 6 +++---
arch/powerpc/include/asm/book3s/64/pgalloc.h | 23 +++---
arch/powerpc/include/asm/book3s/pgalloc.h | 19 ++
.../asm/{pgalloc-32.h => nohash/32/pgallo
64bit book3s now always have 4 level page table irrespective of linux
page size. Move the related code out of #ifdef
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/book3s/64/pgalloc.h | 55 +---
1 file changed, 18 insertions(+), 37 deletions(-)
diff --git a
We move large part of fsl related code to hugetlbpage-book3e.c.
Only code movement. This also avoid #ifdef in the code.
Eventhough we allow hugetlbfs only for book3s 64 and fsl book3e, I am
still retaining the #ifdef in hugetlbpage-book3e.c. It looks like there
was an attempt to support hugetlbfs
We strictly don't need to do this. But enables us to not depend on
pgtable_free_tlb for radix.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/mm/hugetlbpage-book3e.c | 187 ++
arch/powerpc/mm/hugetlbpage-hash64.c | 150
arch/powerpc/
We will be adding a radix variant of these routines in the followup
patches. Move the hash64 variant into its own header so that we can
rename them easily later. Also split pgalloc 64k and 4k headers
Reviewed-by: Paul Mackerras
Signed-off-by: Aneesh Kumar K.V
---
.../include/asm/book3s/64/pgall
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/book3s/64/pgalloc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/book3s/64/pgalloc.h
b/arch/powerpc/include/asm/book3s/64/pgalloc.h
index f06ad7354d68..23b0dd07f9ae 100644
--- a/arch/powe
They are dependent on hash pte bits, so move them to hash64 header
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/book3s/64/hash.h| 50
arch/powerpc/include/asm/book3s/64/pgtable.h | 50
2 files changed, 50 insertions(+)
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/book3s/64/hash.h| 1 +
arch/powerpc/include/asm/nohash/64/pgtable.h | 2 +
arch/powerpc/mm/Makefile | 3 +-
arch/powerpc/mm/init_64.c| 114 +
arch/powerpc/mm/mem.c
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/mm/pgtable-hash64.c | 374 +++
arch/powerpc/mm/pgtable_64.c | 374 ---
2 files changed, 374 insertions(+), 374 deletions(-)
diff --git a/arch/powerpc/mm/pgtable-hash64.c b
The radix variant is going to require a flush_tlb_range. We can't then
have this as static inline because of the usage of HPAGE_PMD_SIZE. So
we are forced to make it a function in which case we can use the generic
version.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/book3s/64/p
This should not have any impact for hash linux implementation. But radix
would require us to flush tlb after clearing accessed bit. Also move
code that is not dependent on pte bits to generic header.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/book3s/64/hash.h| 45 +-
This patch renames _PAGE* -> H_PAGE*. This enables us to support
different page table format in the same kernel. Between radix and
hash we will have different bit position to indicate different pte
states like dirty, present etc. Inorder to enable single kernel to
support both radix and hash page t
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/book3s/64/tlbflush-hash.h | 94 ++
arch/powerpc/include/asm/tlbflush.h| 92 +
2 files changed, 95 insertions(+), 91 deletions(-)
create mode 100644 arch/powerpc/include/asm/book3s
We will later make the generic functions do conditial radix or hash
page table access. This patch doesn't do hugepage api update yet.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/book3s/64/hash.h| 133 +++---
arch/powerpc/include/asm/book3s/64/pgtable.h | 251
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/mmu_context.h | 63 +++---
arch/powerpc/kernel/swsusp.c | 2 +-
arch/powerpc/mm/mmu_context_hash64.c | 16 -
arch/powerpc/mm/mmu_context_nohash.c | 3 +-
drivers/cpufreq/pmac32-cpufreq
We will later make the generic functions do conditial radix or hash
page table access. This patch doesn't do hugepage api update yet.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/book3s/32/pgtable.h | 13
arch/powerpc/include/asm/book3s/64/hash.h| 12 ++-
arch/po
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/{mmu-hash32.h => book3s/32/mmu-hash.h} | 0
arch/powerpc/include/asm/{mmu-hash64.h => book3s/64/mmu-hash.h} | 0
arch/powerpc/include/asm/mmu.h | 4 ++--
arch/powerpc/kernel/idle_power7.S
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/book3s/32/mmu-hash.h | 6 +-
arch/powerpc/include/asm/book3s/64/mmu-hash.h | 61 +-
arch/powerpc/include/asm/book3s/64/mmu.h | 92 +++
arch/powerpc/include/asm/mmu.h| 25
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/book3s/64/hash-64k.h | 42 ---
arch/powerpc/include/asm/book3s/64/hash.h | 16 +++
arch/powerpc/include/asm/book3s/64/pgtable.h | 161 +-
arch/powerpc/mm/pgtable-hash64.c | 64 +-
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/book3s/64/hash-4k.h | 10
arch/powerpc/include/asm/book3s/64/hash-64k.h | 14 +--
arch/powerpc/include/asm/book3s/64/pgalloc-hash.h | 7 ++
arch/powerpc/include/asm/book3s/64/pgalloc.h | 9 +++
a
Signed-off-by: Aneesh Kumar K.V
---
.../include/asm/book3s/64/pgalloc-hash-4k.h| 26 ++---
.../include/asm/book3s/64/pgalloc-hash-64k.h | 23 ++--
arch/powerpc/include/asm/book3s/64/pgalloc-hash.h | 36 +--
arch/powerpc/include/asm/book3s/64/pgalloc.h | 118 +++
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/book3s/64/hash.h| 35 +++--
arch/powerpc/include/asm/book3s/64/pgtable.h | 57
arch/powerpc/mm/slb.c| 1 -
3 files changed, 70 insertions(+), 23 deletions(-)
diff --
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/book3s/64/tlbflush-hash.h | 28 ++-
arch/powerpc/include/asm/book3s/64/tlbflush.h | 56 ++
arch/powerpc/include/asm/tlbflush.h| 2 +-
arch/powerpc/mm/tlb_hash64.c |
On Thu, Feb 18, 2016 at 04:00:37PM +0100, Gerald Schaefer wrote:
> On Thu, 18 Feb 2016 01:58:08 +0200
> "Kirill A. Shutemov" wrote:
>
> > On Wed, Feb 17, 2016 at 08:13:40PM +0100, Gerald Schaefer wrote:
> > > On Sat, 13 Feb 2016 12:58:31 +0100 (CET)
> > > Sebastian Ott wrote:
> > >
> > > > [
On Wed, Feb 17, 2016 at 5:24 AM, Raghav Dogra wrote:
> The new IFC controller version 2.0 has a different memory map page.
> Upto IFC 1.4 PAGE size is 4 KB and from IFC2.0 PAGE size is 64KB.
> This patch segregates the IFC global and runtime registers to appropriate
> PAGE sizes.
>
> Signed-off-by
On Thu, Feb 18, 2016 at 10:20:24PM +0530, Aneesh Kumar K.V wrote:
> Hello,
>
> This is a large series, mostly consisting of code movement. No new features
> are done in this series. The changes are done to accomodate the upcoming new
> memory
> model in future powerpc chips. The details of the ne
On Thu, Feb 18, 2016 at 10:20:25PM +0530, Aneesh Kumar K.V wrote:
> With next generation power processor, we are having a new mmu model
> [1] that require us to maintain a different linux page table format.
>
> Inorder to support both current and future ppc64 systems with a single
> kernel we need
On Thu, 2016-02-18 at 15:18 -0600, Leo Li wrote:
> On Wed, Feb 17, 2016 at 5:24 AM, Raghav Dogra wrote:
> > The new IFC controller version 2.0 has a different memory map page.
> > Upto IFC 1.4 PAGE size is 4 KB and from IFC2.0 PAGE size is 64KB.
> > This patch segregates the IFC global and runtime
Add CPU table entry for POWER9
v2:
Updates based on comments from mpe:
- reuse user features from POWER8
- remove "Hacked up" from comment
- gave oprofile name POWER9
- removed untested power8 machine check hook
- used defines for tlb init code
- removed pmu init from setup code
- a
Subcores isn't really part of the 2.07 architecture but currently we
turn it on using the 2.07 feature bit. Subcores is really a POWER8
specific feature.
This adds a new CPU_FTR bit just for subcores and moves the subcore
init code over to use this.
Reviewed-by: Aneesh Kumar K.V
Signed-off-by:
Use defines for literals __init_tlb_power[78] rather than hand coding
them.
Signed-off-by: Michael Neuling
---
arch/powerpc/kernel/cpu_setup_power.S | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/cpu_setup_power.S
b/arch/powerpc/kernel/cpu_setup_pow
Add a cputable entry for POWER9. More code is required to actually
boot and run on a POWER9 but this gets the base piece in which we can
start building on.
Copies over from POWER8 except for:
- Adds a new CPU_FTR_ARCH_300 bit to start hanging new architecture
features from (in subsequent patch
On 02/18/2016 08:50 AM, Aneesh Kumar K.V wrote:
> With next generation power processor, we are having a new mmu model
> [1] that require us to maintain a different linux page table format.
>
> Inorder to support both current and future ppc64 systems with a single
> kernel we need to make sure kern
Currently on PPC64 changing kernel pagesize from 4K to 64K leaves
FORCE_MAX_ZONEORDER set to 13 - which produces a compile error.
The error occurs because of the following constraint (from
include/linux/mmzone.h) being violated:
MAX_ORDER -1 + PAGESHIFT <= SECTION_SIZE_BITS.
Expanding th
Paul Mackerras writes:
> On Thu, Feb 18, 2016 at 10:20:24PM +0530, Aneesh Kumar K.V wrote:
>> Hello,
>>
>> This is a large series, mostly consisting of code movement. No new features
>> are done in this series. The changes are done to accomodate the upcoming new
>> memory
>> model in future pow
Paul Mackerras writes:
> On Thu, Feb 18, 2016 at 10:20:25PM +0530, Aneesh Kumar K.V wrote:
>> With next generation power processor, we are having a new mmu model
>> [1] that require us to maintain a different linux page table format.
>>
>> Inorder to support both current and future ppc64 systems
Dave Hansen writes:
> On 02/18/2016 08:50 AM, Aneesh Kumar K.V wrote:
>> With next generation power processor, we are having a new mmu model
>> [1] that require us to maintain a different linux page table format.
>>
>> Inorder to support both current and future ppc64 systems with a single
>> ker
On Wed, Feb 17, 2016 at 08:59:53AM -0600, Rob Herring wrote:
>On Tue, Feb 16, 2016 at 9:44 PM, Gavin Shan wrote:
>> This renames unflatten_dt_node() to unflatten_dt_nodes() as it
>> populates multiple device nodes from FDT blob. No logical changes
>> introduced.
>>
>> Signed-off-by: Gavin Shan
>>
On 19/02/16 12:55, Rashmica Gupta wrote:
> Currently on PPC64 changing kernel pagesize from 4K to 64K leaves
> FORCE_MAX_ZONEORDER set to 13 - which produces a compile error.
>
> The error occurs because of the following constraint (from
> include/linux/mmzone.h) being violated:
>
> MAX_ORD
On 19/02/16 15:08, Balbir Singh wrote:
On 19/02/16 12:55, Rashmica Gupta wrote:
Currently on PPC64 changing kernel pagesize from 4K to 64K leaves
FORCE_MAX_ZONEORDER set to 13 - which produces a compile error.
The error occurs because of the following constraint (from
include/linux/mmzone.h)
On 02/18/2016 08:04 PM, Michael Ellerman wrote:
> On Wed, 2016-02-17 at 17:42 +0530, Anshuman Khandual wrote:
>
>> The commit (16a05bff1: powerpc: start loop at section start of
>> start in vmemmap_populated()) reused 'start' variable to compute
>> the starting address of the memory section where
On 02/18/2016 08:07 PM, Michael Ellerman wrote:
> On Wed, 2016-02-17 at 17:42 +0530, Anshuman Khandual wrote:
>
>> This renames the global list which tracks all the virtual to physical
>> mapping and also the global list which tracks all the available unused
>> vmemmap_hw_map node structures.
>
>
On 02/18/2016 07:52 PM, Michael Ellerman wrote:
> On Wed, 2016-02-17 at 17:42 +0530, Anshuman Khandual wrote:
>
>> Add some explaination to the layout of vmemmap virtual address
>> space and how physical page mapping is only used for valid PFNs
>> present at any point on the system.
>>
>> Signed-o
Currently on PPC64 changing kernel pagesize from 4K to 64K leaves
FORCE_MAX_ZONEORDER set to 13 - which produces a compile error.
The error occurs because of the following constraint (from
include/linux/mmzone.h) being violated:
MAX_ORDER -1 + PAGESHIFT <= SECTION_SIZE_BITS.
Expanding th
On 02/18/2016 10:14 PM, Aneesh Kumar K.V wrote:
> We can get a hash pte fault with 4k base page size and find the pte
> already inserted with 64K base page size. In that case we need to clear
Can you please elaborate on this ? What are those situations when we
have 64K base page size on the PTE bu
On 19/02/16 16:38, Rashmica Gupta wrote:
> Currently on PPC64 changing kernel pagesize from 4K to 64K leaves
> FORCE_MAX_ZONEORDER set to 13 - which produces a compile error.
>
> The error occurs because of the following constraint (from
> include/linux/mmzone.h) being violated:
>
> MAX_ORD
62 matches
Mail list logo