KVM: PPC: e6500: support powers of 2K TLB1 sizes
Subsystems (2)
PATCH 1/1 KVM: PPC: e6500: support powers of 2K TLB1 sizes
Book-E MMUv2 present in e6500 cores supports powers of 2K page sizes while older MMUv1 cores support only powers of 4K page sizes, or in other words the LSB of TSIZE on MMUv1 is always 0. Thus, on MMUv2 we must not strip the LSB.
[[email protected]: addressed review
feedback, split in distinct patch]
--- arch/powerpc/kvm/e500_mmu_host.c | 28 +++++++++++++++++++++------- 1 file changed, 21 insertions(+), 7 deletions(-)
arch/powerpc/kvm/e500_mmu_host.c +21 -7
@@ -371,6 +371,7 @@ static inline int kvmppc_e500_shadow_map(struct kvmppc_vcpu_e500 *vcpu_e500,unsigned long start, end;unsigned long slot_start, slot_end; +int tsize_inc; pfnmap =1 ;
@@ -392,10 +393,20 @@ static inline int kvmppc_e500_shadow_map(struct kvmppc_vcpu_e500 *vcpu_e500,MAS1_TSIZE_SHIFT ;/* -* e500 doesn't implement the lowest tsize bit, -* or 1K pages. +* MMUv1 doesn't implement the lowest tsize bit, +* or translations smaller than 4K. */ - tsize =max (BOOK3E_PAGESZ_4K , tsize & ~1 ); +if (!has_feature (&vcpu_e500->vcpu,VCPU_FTR_MMU_V2 )) + tsize &= ~1 ; + tsize =max (BOOK3E_PAGESZ_4K , tsize); + +/* +* Calculate TSIZE increment. MMUv2 supports +* power of 2K translations while MMUv1 is limited +* to power of 4K sizes. +*/ + tsize_inc =has_feature (&vcpu_e500->vcpu, +VCPU_FTR_MMU_V2 ) ?1 :2 ;/* * Now find the largest tsize (up to what the guest
@@ -404,7 +415,8 @@ static inline int kvmppc_e500_shadow_map(struct kvmppc_vcpu_e500 *vcpu_e500,* aligned. */ -for (; tsize >BOOK3E_PAGESZ_4K ; tsize -=2 ) { +for (; tsize >BOOK3E_PAGESZ_4K ; + tsize -= tsize_inc) {unsigned long gfn_start, gfn_end; tsize_pages =1 << (tsize -2 );
@@ -437,10 +449,12 @@ static inline int kvmppc_e500_shadow_map(struct kvmppc_vcpu_e500 *vcpu_e500, tsize =min (__ilog2 (psize) -10 , tsize);/* -* e500 doesn't implement the lowest tsize bit, -* or 1K pages. +* MMUv1 doesn't implement the lowest tsize bit, +* or translations smaller than 4K. */ - tsize =max (BOOK3E_PAGESZ_4K , tsize & ~1 ); +if (!has_feature (&vcpu_e500->vcpu,VCPU_FTR_MMU_V2 )) + tsize &= ~1 ; + tsize =max (BOOK3E_PAGESZ_4K , tsize); }up_read (¤t->mm->mmap_sem);
Signature · 1 line
1.8.3.1
Quoted 5 lines · Laurentiu Tudor
Book-E MMUv2 present in e6500 cores supports powers of 2K page sizes while older MMUv1 cores support only powers of 4K page sizes, or in other words the LSB of TSIZE on MMUv1 is always 0. Thus, on MMUv2 we must not strip the LSB.
We can get better TLB utilization by not stripping it, but why "must not" which makes it sound like a bugfix rather than an optimization?
Quoted 34 lines
Signed-off-by Mihai Caraman <[email protected]>[[email protected]: addressed review
feedback, split in distinct patch]Signed-off-by Laurentiu Tudor <[email protected]>--- arch/powerpc/kvm/e500_mmu_host.c | 28 +++++++++++++++++++++------- 1 file changed, 21 insertions(+), 7 deletions(-)arch/powerpc/kvm/e500_mmu_host.c +4
-3@@ -371,6 +371,7 @@ static inline int kvmppc_e500_shadow_map(structkvmppc_vcpu_e500 *vcpu_e500, unsigned long start, end;unsigned long slot_start, slot_end; +int tsize_inc; pfnmap =1 ;@@ -392,10 +393,20 @@ static inline int kvmppc_e500_shadow_map(structkvmppc_vcpu_e500 *vcpu_e500,MAS1_TSIZE_SHIFT ;/* -* e500 doesn't implement the lowest tsize bit, -* or 1K pages. +* MMUv1 doesn't implement the lowest tsize bit, +* or translations smaller than 4K. */ - tsize =max (BOOK3E_PAGESZ_4K , tsize & ~1 ); +if (!has_feature (&vcpu_e500->vcpu,VCPU_FTR_MMU_V2 ))
arch/powerpc/kvm/e500_mmu_host.c static inline int kvmppc_e500_shadow_map(struct · line 410
Quoted 10 lines
arch/powerpc/kvm/e500_mmu_host.c +10
-0+ tsize &= ~1 ; + tsize =max (BOOK3E_PAGESZ_4K , tsize); + +/* +* Calculate TSIZE increment. MMUv2 supports +* power of 2K translations while MMUv1 is limited +* to power of 4K sizes. +*/ + tsize_inc =has_feature (&vcpu_e500->vcpu, +VCPU_FTR_MMU_V2 ) ?1 :2 ;
If you calculate tsize_inc first, then the previous if-statement can become "tsize &= ~(tsize_inc - 1);".
Quoted 15 lines
arch/powerpc/kvm/e500_mmu_host.c +2
-1/* * Now find the largest tsize (up to what the guest @@ -404,7 +415,8 @@ static inline int kvmppc_e500_shadow_map(structkvmppc_vcpu_e500 *vcpu_e500, * aligned. */ -for (; tsize >BOOK3E_PAGESZ_4K ; tsize -=2 ) { +for (; tsize >BOOK3E_PAGESZ_4K ; + tsize -= tsize_inc) {unsigned long gfn_start, gfn_end; tsize_pages =1 << (tsize -2 );
arch/powerpc/kvm/e500_mmu_host.c static inline int kvmppc_e500_shadow_map(struct · line 455
Quoted 9 lines
arch/powerpc/kvm/e500_mmu_host.c +2
-2@@ -437,10 +449,12 @@ static inline int kvmppc_e500_shadow_map(structkvmppc_vcpu_e500 *vcpu_e500, tsize =min (__ilog2 (psize) -10 , tsize);/* -* e500 doesn't implement the lowest tsize bit, -* or 1K pages. +* MMUv1 doesn't implement the lowest tsize bit, +* or translations smaller than 4K. */
This comment makes it sound like MMUv2 might support translations smaller than 4K.
-Scott
Quoted 9 lines · Scott Wood
Quoted 5 lines · Laurentiu Tudor
Book-E MMUv2 present in e6500 cores supports powers of 2K page sizes while older MMUv1 cores support only powers of 4K page sizes, or in other words the LSB of TSIZE on MMUv1 is always 0. Thus, on MMUv2 we must not strip the LSB.
We can get better TLB utilization by not stripping it, but why "must not" which makes it sound like a bugfix rather than an optimization?
Not sure i get it. If a guests wants a 2K^^(2n+1) translation size it will instead get a 2K^^2n size, no? Isn't this an issue?
Quoted 39 lines
Quoted 39 lines
Signed-off-by Mihai Caraman <[email protected]>[[email protected]: addressed review
feedback, split in distinct patch]Signed-off-by Laurentiu Tudor <[email protected]>--- arch/powerpc/kvm/e500_mmu_host.c | 28 +++++++++++++++++++++------- 1 file changed, 21 insertions(+), 7 deletions(-)arch/powerpc/kvm/e500_mmu_host.c +9
-3@@ -371,6 +371,7 @@ static inline int kvmppc_e500_shadow_map(structkvmppc_vcpu_e500 *vcpu_e500, unsigned long start, end;unsigned long slot_start, slot_end; +int tsize_inc; pfnmap =1 ;@@ -392,10 +393,20 @@ static inline int kvmppc_e500_shadow_map(structkvmppc_vcpu_e500 *vcpu_e500,MAS1_TSIZE_SHIFT ;/* -* e500 doesn't implement the lowest tsize bit, -* or 1K pages. +* MMUv1 doesn't implement the lowest tsize bit, +* or translations smaller than 4K. */ - tsize =max (BOOK3E_PAGESZ_4K , tsize & ~1 ); +if (!has_feature (&vcpu_e500->vcpu,VCPU_FTR_MMU_V2 )) + tsize &= ~1 ; + tsize =max (BOOK3E_PAGESZ_4K , tsize); + +/* +* Calculate TSIZE increment. MMUv2 supports
Quoted 8 lines
arch/powerpc/kvm/e500_mmu_host.c static inline int kvmppc_e500_shadow_map(struct kvmppc_vcpu_e500 *vcpu_e500, · line 409
Quoted 5 lines
arch/powerpc/kvm/e500_mmu_host.c +5
-0+* power of 2K translations while MMUv1 is limited +* to power of 4K sizes. +*/ + tsize_inc =has_feature (&vcpu_e500->vcpu, +VCPU_FTR_MMU_V2 ) ?1 :2 ;If you calculate
tsize_incfirst, then the previous if-statement can become "tsize &= ~(tsize_inc - 1);".
Thanks for the tip. Will do this in the next version.
Quoted 18 lines
Quoted 18 lines
arch/powerpc/kvm/e500_mmu_host.c +2
-1/* * Now find the largest tsize (up to what the guest @@ -404,7 +415,8 @@ static inline int kvmppc_e500_shadow_map(structkvmppc_vcpu_e500 *vcpu_e500, * aligned. */ -for (; tsize >BOOK3E_PAGESZ_4K ; tsize -=2 ) { +for (; tsize >BOOK3E_PAGESZ_4K ; + tsize -= tsize_inc) {unsigned long gfn_start, gfn_end; tsize_pages =1 << (tsize -2 );@@ -437,10 +449,12 @@ static inline int kvmppc_e500_shadow_map(structkvmppc_vcpu_e500 *vcpu_e500, tsize =min (__ilog2 (psize) -10 , tsize);
Quoted 9 lines
arch/powerpc/kvm/e500_mmu_host.c static inline int kvmppc_e500_shadow_map(struct kvmppc_vcpu_e500 *vcpu_e500, · line 398
Quoted 6 lines
arch/powerpc/kvm/e500_mmu_host.c +2
-2/* -* e500 doesn't implement the lowest tsize bit, -* or 1K pages. +* MMUv1 doesn't implement the lowest tsize bit, +* or translations smaller than 4K. */ This comment makes it sound like MMUv2 might support translations smaller than 4K.
Right. I'll rephrase in the next spin.
Thanks for the review!
---
Best Regards, Laurentiu
Quoted 8 lines · Laurentiu Tudor
Quoted 7 lines · Scott Wood
Quoted 5 lines · Laurentiu Tudor
Book-E MMUv2 present in e6500 cores supports powers of 2K page sizes while older MMUv1 cores support only powers of 4K page sizes, or in other words the LSB of TSIZE on MMUv1 is always 0. Thus, on MMUv2 we must not strip the LSB.
Quoted 5 lines
Quoted 2 lines
We can get better TLB utilization by not stripping it, but why "must not" which makes it sound like a bugfix rather than an optimization?
Not sure i get it. If a guests wants a 2K^^(2n+1) translation size it will instead get a 2K^^2n size, no? Isn't this an issue?
It will get two pages of 2k^^2n size (assuming both halves are accessed). It will work, it will just consume twice as many TLB1 entries. It's the same as if the host pages backing the region are smaller than the mapping that the guest tries to create.
-Scott