[PATCH 0/5] KVM: PPC: e500: Enable FSL e6500 core

[PATCH 0/5] KVM: PPC: e500: Enable FSL e6500 core

[Mihai Caraman]

Enable Freescale e6500 core adding missing MAV 2.0 support. LRAT and Page
Table are not addresses by this commit.

Mihai Caraman (5):
  KVM: PPC: e500: Move VCPU's MMUCFG register initialization earlier
  KVM: PPC: e500: Emulate TLBnPS registers
  KVM: PPC: e500: Remove E.PT category from VCPUs
  KVM: PPC: e500: Emulate EPTCFG register
  KVM: PPC: e500mc: Enable e6500 cores

 arch/powerpc/include/asm/kvm_host.h |    2 ++
 arch/powerpc/kvm/e500.h             |   11 +++++++++++
 arch/powerpc/kvm/e500_emulate.c     |   19 +++++++++++++++++++
 arch/powerpc/kvm/e500_mmu.c         |   24 ++++++++++++++++++------
 arch/powerpc/kvm/e500mc.c           |    2 ++
 5 files changed, 52 insertions(+), 6 deletions(-)

-- 
1.7.4.1

[PATCH 1/5] KVM: PPC: e500: Move VCPU's MMUCFG register initialization earlier

[Mihai Caraman]

VCPU's MMUCFG register initialization should not depend on KVM_CAP_SW_TLB
ioctl call. Move it earlier into tlb initalization phase.

Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
---
 arch/powerpc/kvm/e500_mmu.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kvm/e500_mmu.c b/arch/powerpc/kvm/e500_mmu.c
index 5c44759..bb1b2b0 100644
--- a/arch/powerpc/kvm/e500_mmu.c
+++ b/arch/powerpc/kvm/e500_mmu.c
@@ -692,8 +692,6 @@ int kvm_vcpu_ioctl_config_tlb(struct kvm_vcpu *vcpu,
 	vcpu_e500->gtlb_offset[0] = 0;
 	vcpu_e500->gtlb_offset[1] = params.tlb_sizes[0];
 
-	vcpu->arch.mmucfg = mfspr(SPRN_MMUCFG) & ~MMUCFG_LPIDSIZE;
-
 	vcpu->arch.tlbcfg[0] &= ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
 	if (params.tlb_sizes[0] <= 2048)
 		vcpu->arch.tlbcfg[0] |= params.tlb_sizes[0];
@@ -781,6 +779,8 @@ int kvmppc_e500_tlb_init(struct kvmppc_vcpu_e500 *vcpu_e500)
 	if (!vcpu_e500->g2h_tlb1_map)
 		goto err;
 
+	vcpu->arch.mmucfg = mfspr(SPRN_MMUCFG) & ~MMUCFG_LPIDSIZE;
+
 	/* Init TLB configuration register */
 	vcpu->arch.tlbcfg[0] = mfspr(SPRN_TLB0CFG) &
 			     ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
-- 
1.7.4.1

Re: [PATCH 1/5] KVM: PPC: e500: Move VCPU's MMUCFG register initialization earlier

[Alexander Graf]

On 30.01.2013, at 14:29, Mihai Caraman wrote:

> VCPU's MMUCFG register initialization should not depend on =
KVM_CAP_SW_TLB
> ioctl call. Move it earlier into tlb initalization phase.

Quite the contrary. The fact that there is an mfspr() in e500_mmu.c =
already tells us that the code is broken. The TLB guest code should only =
depend on input from the SW_TLB configuration. It's completely =
orthogonal to the host capabilities.


Alex

>=20
> Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
> ---
> arch/powerpc/kvm/e500_mmu.c |    4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>=20
> diff --git a/arch/powerpc/kvm/e500_mmu.c b/arch/powerpc/kvm/e500_mmu.c
> index 5c44759..bb1b2b0 100644
> --- a/arch/powerpc/kvm/e500_mmu.c
> +++ b/arch/powerpc/kvm/e500_mmu.c
> @@ -692,8 +692,6 @@ int kvm_vcpu_ioctl_config_tlb(struct kvm_vcpu =
*vcpu,
> 	vcpu_e500->gtlb_offset[0] =3D 0;
> 	vcpu_e500->gtlb_offset[1] =3D params.tlb_sizes[0];
>=20
> -	vcpu->arch.mmucfg =3D mfspr(SPRN_MMUCFG) & ~MMUCFG_LPIDSIZE;
> -
> 	vcpu->arch.tlbcfg[0] &=3D ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
> 	if (params.tlb_sizes[0] <=3D 2048)
> 		vcpu->arch.tlbcfg[0] |=3D params.tlb_sizes[0];
> @@ -781,6 +779,8 @@ int kvmppc_e500_tlb_init(struct kvmppc_vcpu_e500 =
*vcpu_e500)
> 	if (!vcpu_e500->g2h_tlb1_map)
> 		goto err;
>=20
> +	vcpu->arch.mmucfg =3D mfspr(SPRN_MMUCFG) & ~MMUCFG_LPIDSIZE;
> +
> 	/* Init TLB configuration register */
> 	vcpu->arch.tlbcfg[0] =3D mfspr(SPRN_TLB0CFG) &
> 			     ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
> --=20
> 1.7.4.1
>=20
>=20
> --
> To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 1/5] KVM: PPC: e500: Move VCPU's MMUCFG register initialization earlier

[Caraman Mihai Claudiu-B02008]

> -----Original Message-----
> From: Alexander Graf [mailto:agraf@suse.de]
> Sent: Thursday, January 31, 2013 3:21 PM
> To: Caraman Mihai Claudiu-B02008
> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
> dev@lists.ozlabs.org
> Subject: Re: [PATCH 1/5] KVM: PPC: e500: Move VCPU's MMUCFG register
> initialization earlier
>=20
>=20
> On 30.01.2013, at 14:29, Mihai Caraman wrote:
>=20
> > VCPU's MMUCFG register initialization should not depend on
> KVM_CAP_SW_TLB
> > ioctl call. Move it earlier into tlb initalization phase.
>=20
> Quite the contrary. The fact that there is an mfspr() in e500_mmu.c
> already tells us that the code is broken. The TLB guest code should only
> depend on input from the SW_TLB configuration. It's completely orthogonal
> to the host capabilities.

Then we have the same issue for TLBnCFG registers which need to be configur=
ed
via SW_TLB ioctl. What is the purpose of guest tlb initalization in e500_mm=
u.c
if we rely on SW_TLB?

-Mike

Re: [PATCH 1/5] KVM: PPC: e500: Move VCPU's MMUCFG register initialization earlier

[Alexander Graf]

On 31.01.2013, at 15:56, Caraman Mihai Claudiu-B02008 wrote:

>> -----Original Message-----
>> From: Alexander Graf [mailto:agraf@suse.de]
>> Sent: Thursday, January 31, 2013 3:21 PM
>> To: Caraman Mihai Claudiu-B02008
>> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
>> dev@lists.ozlabs.org
>> Subject: Re: [PATCH 1/5] KVM: PPC: e500: Move VCPU's MMUCFG register
>> initialization earlier
>>=20
>>=20
>> On 30.01.2013, at 14:29, Mihai Caraman wrote:
>>=20
>>> VCPU's MMUCFG register initialization should not depend on
>> KVM_CAP_SW_TLB
>>> ioctl call. Move it earlier into tlb initalization phase.
>>=20
>> Quite the contrary. The fact that there is an mfspr() in e500_mmu.c
>> already tells us that the code is broken. The TLB guest code should =
only
>> depend on input from the SW_TLB configuration. It's completely =
orthogonal
>> to the host capabilities.
>=20
> Then we have the same issue for TLBnCFG registers which need to be =
configured
> via SW_TLB ioctl. What is the purpose of guest tlb initalization in =
e500_mmu.c
> if we rely on SW_TLB?

It's to provide a fallback to user space that doesn't implement SW_TLB =
configuration yet.


Alex

RE: [PATCH 1/5] KVM: PPC: e500: Move VCPU's MMUCFG register initialization earlier

[Caraman Mihai Claudiu-B02008]

> -----Original Message-----
> From: Alexander Graf [mailto:agraf@suse.de]
> Sent: Thursday, January 31, 2013 4:58 PM
> To: Caraman Mihai Claudiu-B02008
> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
> dev@lists.ozlabs.org
> Subject: Re: [PATCH 1/5] KVM: PPC: e500: Move VCPU's MMUCFG register
> initialization earlier
>=20
>=20
> On 31.01.2013, at 15:56, Caraman Mihai Claudiu-B02008 wrote:
>=20
> >> -----Original Message-----
> >> From: Alexander Graf [mailto:agraf@suse.de]
> >> Sent: Thursday, January 31, 2013 3:21 PM
> >> To: Caraman Mihai Claudiu-B02008
> >> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
> >> dev@lists.ozlabs.org
> >> Subject: Re: [PATCH 1/5] KVM: PPC: e500: Move VCPU's MMUCFG register
> >> initialization earlier
> >>
> >>
> >> On 30.01.2013, at 14:29, Mihai Caraman wrote:
> >>
> >>> VCPU's MMUCFG register initialization should not depend on
> >> KVM_CAP_SW_TLB
> >>> ioctl call. Move it earlier into tlb initalization phase.
> >>
> >> Quite the contrary. The fact that there is an mfspr() in e500_mmu.c
> >> already tells us that the code is broken. The TLB guest code should
> only
> >> depend on input from the SW_TLB configuration. It's completely
> orthogonal
> >> to the host capabilities.
> >
> > Then we have the same issue for TLBnCFG registers which need to be
> configured
> > via SW_TLB ioctl. What is the purpose of guest tlb initalization in
> e500_mmu.c
> > if we rely on SW_TLB?
>=20
> It's to provide a fallback to user space that doesn't implement SW_TLB
> configuration yet.

Do we have such a case now or is it just hypothetical? For the fallback we
need to initialize the MMUCFG register which I intended to say in the commi=
t
message.

>=20
>=20
> Alex
>=20

Re: [PATCH 1/5] KVM: PPC: e500: Move VCPU's MMUCFG register initialization earlier

[Scott Wood]

On 01/31/2013 09:26:20 AM, Caraman Mihai Claudiu-B02008 wrote:
> > -----Original Message-----
> > From: Alexander Graf [mailto:agraf@suse.de]
> > Sent: Thursday, January 31, 2013 4:58 PM
> > To: Caraman Mihai Claudiu-B02008
> > Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
> > dev@lists.ozlabs.org
> > Subject: Re: [PATCH 1/5] KVM: PPC: e500: Move VCPU's MMUCFG register
> > initialization earlier
> >
> >
> > On 31.01.2013, at 15:56, Caraman Mihai Claudiu-B02008 wrote:
> >
> > >> -----Original Message-----
> > >> From: Alexander Graf [mailto:agraf@suse.de]
> > >> Sent: Thursday, January 31, 2013 3:21 PM
> > >> To: Caraman Mihai Claudiu-B02008
> > >> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
> > >> dev@lists.ozlabs.org
> > >> Subject: Re: [PATCH 1/5] KVM: PPC: e500: Move VCPU's MMUCFG =20
> register
> > >> initialization earlier
> > >>
> > >>
> > >> On 30.01.2013, at 14:29, Mihai Caraman wrote:
> > >>
> > >>> VCPU's MMUCFG register initialization should not depend on
> > >> KVM_CAP_SW_TLB
> > >>> ioctl call. Move it earlier into tlb initalization phase.
> > >>
> > >> Quite the contrary. The fact that there is an mfspr() in =20
> e500_mmu.c
> > >> already tells us that the code is broken. The TLB guest code =20
> should
> > only
> > >> depend on input from the SW_TLB configuration. It's completely
> > orthogonal
> > >> to the host capabilities.
> > >
> > > Then we have the same issue for TLBnCFG registers which need to be
> > configured
> > > via SW_TLB ioctl. What is the purpose of guest tlb initalization =20
> in
> > e500_mmu.c
> > > if we rely on SW_TLB?
> >
> > It's to provide a fallback to user space that doesn't implement =20
> SW_TLB
> > configuration yet.
>=20
> Do we have such a case now or is it just hypothetical? For the =20
> fallback we
> need to initialize the MMUCFG register which I intended to say in the =20
> commit
> message.

I don't think we need to support a fallback for e6500, since there's =20
nothing to be backwards compatible with.

As for use case, I don't see us ever supporting the guest being a =20
different CPU than the host.  Page sizes probably aren't a problem, but =20
there are other barriers.

The main reasons that TLBnCFG are settable through SW_TLB are:
1. The guest TLB can be enlarged as a performance hack (like in Topaz, =20
though QEMU doesn't currently do this),
2. The legacy default in KVM is based on the e500v1 TLB0 size, which is =20
half of what e500v2/e500mc have, and
3. QEMU needs to know the exact geometry of the TLB so that it can =20
interpret the shared data properly.

#3 seems like a compelling reason here, to avoid silent weirdness if =20
there's a slight mismatch between what QEMU thinks it's modelling and =20
what we're actually running on.

-Scott=

[PATCH 2/5] KVM: PPC: e500: Emulate TLBnPS registers

[Mihai Caraman]

Emulate TLBnPS registers which are available in MMU Architecture Version
(MAV) 2.0.

Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
---
 arch/powerpc/include/asm/kvm_host.h |    1 +
 arch/powerpc/kvm/e500.h             |    5 +++++
 arch/powerpc/kvm/e500_emulate.c     |   10 ++++++++++
 arch/powerpc/kvm/e500_mmu.c         |    5 +++++
 4 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
index 8a72d59..88fcfe6 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -501,6 +501,7 @@ struct kvm_vcpu_arch {
 	spinlock_t wdt_lock;
 	struct timer_list wdt_timer;
 	u32 tlbcfg[4];
+	u32 tlbps[4];
 	u32 mmucfg;
 	u32 epr;
 	struct kvmppc_booke_debug_reg dbg_reg;
diff --git a/arch/powerpc/kvm/e500.h b/arch/powerpc/kvm/e500.h
index 41cefd4..b9f76d8 100644
--- a/arch/powerpc/kvm/e500.h
+++ b/arch/powerpc/kvm/e500.h
@@ -303,4 +303,9 @@ static inline unsigned int get_tlbmiss_tid(struct kvm_vcpu *vcpu)
 #define get_tlb_sts(gtlbe)              (MAS1_TS)
 #endif /* !BOOKE_HV */
 
+static inline unsigned int has_mmu_v2(const struct kvm_vcpu *vcpu)
+{
+	return ((vcpu->arch.mmucfg & MMUCFG_MAVN) == MMUCFG_MAVN_V2);
+}
+
 #endif /* KVM_E500_H */
diff --git a/arch/powerpc/kvm/e500_emulate.c b/arch/powerpc/kvm/e500_emulate.c
index e78f353..5515dc5 100644
--- a/arch/powerpc/kvm/e500_emulate.c
+++ b/arch/powerpc/kvm/e500_emulate.c
@@ -329,6 +329,16 @@ int kvmppc_core_emulate_mfspr(struct kvm_vcpu *vcpu, int sprn, ulong *spr_val)
 		*spr_val = vcpu->arch.ivor[BOOKE_IRQPRIO_DBELL_CRIT];
 		break;
 #endif
+	case SPRN_TLB0PS:
+		if (!has_mmu_v2(vcpu))
+			return EMULATE_FAIL;
+		*spr_val = vcpu->arch.tlbps[0];
+		break;
+	case SPRN_TLB1PS:
+		if (!has_mmu_v2(vcpu))
+			return EMULATE_FAIL;
+		*spr_val = vcpu->arch.tlbps[1];
+		break;
 	default:
 		emulated = kvmppc_booke_emulate_mfspr(vcpu, sprn, spr_val);
 	}
diff --git a/arch/powerpc/kvm/e500_mmu.c b/arch/powerpc/kvm/e500_mmu.c
index bb1b2b0..129299a 100644
--- a/arch/powerpc/kvm/e500_mmu.c
+++ b/arch/powerpc/kvm/e500_mmu.c
@@ -794,6 +794,11 @@ int kvmppc_e500_tlb_init(struct kvmppc_vcpu_e500 *vcpu_e500)
 	vcpu->arch.tlbcfg[1] |=
 		vcpu_e500->gtlb_params[1].ways << TLBnCFG_ASSOC_SHIFT;
 
+	if (has_mmu_v2(vcpu)) {
+		vcpu->arch.tlbps[0] = mfspr(SPRN_TLB0PS);
+		vcpu->arch.tlbps[1] = mfspr(SPRN_TLB1PS);
+	}
+
 	kvmppc_recalc_tlb1map_range(vcpu_e500);
 	return 0;
 
-- 
1.7.4.1

Re: [PATCH 2/5] KVM: PPC: e500: Emulate TLBnPS registers

[Alexander Graf]

On 30.01.2013, at 14:29, Mihai Caraman wrote:

> Emulate TLBnPS registers which are available in MMU Architecture =
Version
> (MAV) 2.0.
>=20
> Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
> ---
> arch/powerpc/include/asm/kvm_host.h |    1 +
> arch/powerpc/kvm/e500.h             |    5 +++++
> arch/powerpc/kvm/e500_emulate.c     |   10 ++++++++++
> arch/powerpc/kvm/e500_mmu.c         |    5 +++++
> 4 files changed, 21 insertions(+), 0 deletions(-)
>=20
> diff --git a/arch/powerpc/include/asm/kvm_host.h =
b/arch/powerpc/include/asm/kvm_host.h
> index 8a72d59..88fcfe6 100644
> --- a/arch/powerpc/include/asm/kvm_host.h
> +++ b/arch/powerpc/include/asm/kvm_host.h
> @@ -501,6 +501,7 @@ struct kvm_vcpu_arch {
> 	spinlock_t wdt_lock;
> 	struct timer_list wdt_timer;
> 	u32 tlbcfg[4];
> +	u32 tlbps[4];
> 	u32 mmucfg;
> 	u32 epr;
> 	struct kvmppc_booke_debug_reg dbg_reg;
> diff --git a/arch/powerpc/kvm/e500.h b/arch/powerpc/kvm/e500.h
> index 41cefd4..b9f76d8 100644
> --- a/arch/powerpc/kvm/e500.h
> +++ b/arch/powerpc/kvm/e500.h
> @@ -303,4 +303,9 @@ static inline unsigned int get_tlbmiss_tid(struct =
kvm_vcpu *vcpu)
> #define get_tlb_sts(gtlbe)              (MAS1_TS)
> #endif /* !BOOKE_HV */
>=20
> +static inline unsigned int has_mmu_v2(const struct kvm_vcpu *vcpu)

bool. Also rename it to "is_..." then.

> +{
> +	return ((vcpu->arch.mmucfg & MMUCFG_MAVN) =3D=3D =
MMUCFG_MAVN_V2);
> +}
> +
> #endif /* KVM_E500_H */
> diff --git a/arch/powerpc/kvm/e500_emulate.c =
b/arch/powerpc/kvm/e500_emulate.c
> index e78f353..5515dc5 100644
> --- a/arch/powerpc/kvm/e500_emulate.c
> +++ b/arch/powerpc/kvm/e500_emulate.c
> @@ -329,6 +329,16 @@ int kvmppc_core_emulate_mfspr(struct kvm_vcpu =
*vcpu, int sprn, ulong *spr_val)
> 		*spr_val =3D vcpu->arch.ivor[BOOKE_IRQPRIO_DBELL_CRIT];
> 		break;
> #endif
> +	case SPRN_TLB0PS:
> +		if (!has_mmu_v2(vcpu))
> +			return EMULATE_FAIL;
> +		*spr_val =3D vcpu->arch.tlbps[0];
> +		break;
> +	case SPRN_TLB1PS:
> +		if (!has_mmu_v2(vcpu))
> +			return EMULATE_FAIL;
> +		*spr_val =3D vcpu->arch.tlbps[1];
> +		break;
> 	default:
> 		emulated =3D kvmppc_booke_emulate_mfspr(vcpu, sprn, =
spr_val);
> 	}
> diff --git a/arch/powerpc/kvm/e500_mmu.c b/arch/powerpc/kvm/e500_mmu.c
> index bb1b2b0..129299a 100644
> --- a/arch/powerpc/kvm/e500_mmu.c
> +++ b/arch/powerpc/kvm/e500_mmu.c
> @@ -794,6 +794,11 @@ int kvmppc_e500_tlb_init(struct kvmppc_vcpu_e500 =
*vcpu_e500)
> 	vcpu->arch.tlbcfg[1] |=3D
> 		vcpu_e500->gtlb_params[1].ways << TLBnCFG_ASSOC_SHIFT;
>=20
> +	if (has_mmu_v2(vcpu)) {
> +		vcpu->arch.tlbps[0] =3D mfspr(SPRN_TLB0PS);
> +		vcpu->arch.tlbps[1] =3D mfspr(SPRN_TLB1PS);

So I suppose that means that user space doesn't tell us the possible TLB =
entry sizes through the SW_TLB config? Then we should add them there.

To not break untested code paths, we can still compare if the values =
user space asks for are identical to what physical hardware does. But =
eventually we shouldn't care.


Alex

Re: [PATCH 2/5] KVM: PPC: e500: Emulate TLBnPS registers

[Alexander Graf]

On 31.01.2013, at 14:24, Alexander Graf wrote:

>=20
> On 30.01.2013, at 14:29, Mihai Caraman wrote:
>=20
>> Emulate TLBnPS registers which are available in MMU Architecture =
Version
>> (MAV) 2.0.
>>=20
>> Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
>> ---
>> arch/powerpc/include/asm/kvm_host.h |    1 +
>> arch/powerpc/kvm/e500.h             |    5 +++++
>> arch/powerpc/kvm/e500_emulate.c     |   10 ++++++++++
>> arch/powerpc/kvm/e500_mmu.c         |    5 +++++
>> 4 files changed, 21 insertions(+), 0 deletions(-)
>>=20
>> diff --git a/arch/powerpc/include/asm/kvm_host.h =
b/arch/powerpc/include/asm/kvm_host.h
>> index 8a72d59..88fcfe6 100644
>> --- a/arch/powerpc/include/asm/kvm_host.h
>> +++ b/arch/powerpc/include/asm/kvm_host.h
>> @@ -501,6 +501,7 @@ struct kvm_vcpu_arch {
>> 	spinlock_t wdt_lock;
>> 	struct timer_list wdt_timer;
>> 	u32 tlbcfg[4];
>> +	u32 tlbps[4];
>> 	u32 mmucfg;
>> 	u32 epr;
>> 	struct kvmppc_booke_debug_reg dbg_reg;
>> diff --git a/arch/powerpc/kvm/e500.h b/arch/powerpc/kvm/e500.h
>> index 41cefd4..b9f76d8 100644
>> --- a/arch/powerpc/kvm/e500.h
>> +++ b/arch/powerpc/kvm/e500.h
>> @@ -303,4 +303,9 @@ static inline unsigned int get_tlbmiss_tid(struct =
kvm_vcpu *vcpu)
>> #define get_tlb_sts(gtlbe)              (MAS1_TS)
>> #endif /* !BOOKE_HV */
>>=20
>> +static inline unsigned int has_mmu_v2(const struct kvm_vcpu *vcpu)
>=20
> bool. Also rename it to "is_..." then.

In light of the comment I did in a later patch, this too could be =
convert to feature flags.


Alex

[PATCH 3/5] KVM: PPC: e500: Remove E.PT category from VCPUs

[Mihai Caraman]

Embedded.Page Table (E.PT) category in VMs requires indirect tlb entries
emulation which is not supported yet. Configure TLBnCFG to remove E.PT
category from VCPUs.

Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
---
 arch/powerpc/kvm/e500_mmu.c |   10 ++++++----
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/kvm/e500_mmu.c b/arch/powerpc/kvm/e500_mmu.c
index 129299a..9a1f7b7 100644
--- a/arch/powerpc/kvm/e500_mmu.c
+++ b/arch/powerpc/kvm/e500_mmu.c
@@ -692,12 +692,14 @@ int kvm_vcpu_ioctl_config_tlb(struct kvm_vcpu *vcpu,
 	vcpu_e500->gtlb_offset[0] = 0;
 	vcpu_e500->gtlb_offset[1] = params.tlb_sizes[0];
 
-	vcpu->arch.tlbcfg[0] &= ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
+	vcpu->arch.tlbcfg[0] &=
+			      ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC | TLBnCFG_IND);
 	if (params.tlb_sizes[0] <= 2048)
 		vcpu->arch.tlbcfg[0] |= params.tlb_sizes[0];
 	vcpu->arch.tlbcfg[0] |= params.tlb_ways[0] << TLBnCFG_ASSOC_SHIFT;
 
-	vcpu->arch.tlbcfg[1] &= ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
+	vcpu->arch.tlbcfg[1] &=
+			      ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC | TLBnCFG_IND);
 	vcpu->arch.tlbcfg[1] |= params.tlb_sizes[1];
 	vcpu->arch.tlbcfg[1] |= params.tlb_ways[1] << TLBnCFG_ASSOC_SHIFT;
 
@@ -783,13 +785,13 @@ int kvmppc_e500_tlb_init(struct kvmppc_vcpu_e500 *vcpu_e500)
 
 	/* Init TLB configuration register */
 	vcpu->arch.tlbcfg[0] = mfspr(SPRN_TLB0CFG) &
-			     ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
+			     ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC | TLBnCFG_IND);
 	vcpu->arch.tlbcfg[0] |= vcpu_e500->gtlb_params[0].entries;
 	vcpu->arch.tlbcfg[0] |=
 		vcpu_e500->gtlb_params[0].ways << TLBnCFG_ASSOC_SHIFT;
 
 	vcpu->arch.tlbcfg[1] = mfspr(SPRN_TLB1CFG) &
-			     ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
+			     ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC | TLBnCFG_IND);
 	vcpu->arch.tlbcfg[1] |= vcpu_e500->gtlb_params[1].entries;
 	vcpu->arch.tlbcfg[1] |=
 		vcpu_e500->gtlb_params[1].ways << TLBnCFG_ASSOC_SHIFT;
-- 
1.7.4.1

Re: [PATCH 3/5] KVM: PPC: e500: Remove E.PT category from VCPUs

[Alexander Graf]

On 30.01.2013, at 14:29, Mihai Caraman wrote:

> Embedded.Page Table (E.PT) category in VMs requires indirect tlb =
entries
> emulation which is not supported yet. Configure TLBnCFG to remove E.PT
> category from VCPUs.
>=20
> Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>

Please do this in a separate function that you call from these =
locations. That way the code is self-documenting on what it actually =
does.

Also add a comment to this one function that removes E.PT related bits =
from TLBCFG that our _guest_ mmu emulation currently doesn't handle =
E.PT.


Alex

> ---
> arch/powerpc/kvm/e500_mmu.c |   10 ++++++----
> 1 files changed, 6 insertions(+), 4 deletions(-)
>=20
> diff --git a/arch/powerpc/kvm/e500_mmu.c b/arch/powerpc/kvm/e500_mmu.c
> index 129299a..9a1f7b7 100644
> --- a/arch/powerpc/kvm/e500_mmu.c
> +++ b/arch/powerpc/kvm/e500_mmu.c
> @@ -692,12 +692,14 @@ int kvm_vcpu_ioctl_config_tlb(struct kvm_vcpu =
*vcpu,
> 	vcpu_e500->gtlb_offset[0] =3D 0;
> 	vcpu_e500->gtlb_offset[1] =3D params.tlb_sizes[0];
>=20
> -	vcpu->arch.tlbcfg[0] &=3D ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
> +	vcpu->arch.tlbcfg[0] &=3D
> +			      ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC | =
TLBnCFG_IND);
> 	if (params.tlb_sizes[0] <=3D 2048)
> 		vcpu->arch.tlbcfg[0] |=3D params.tlb_sizes[0];
> 	vcpu->arch.tlbcfg[0] |=3D params.tlb_ways[0] << =
TLBnCFG_ASSOC_SHIFT;
>=20
> -	vcpu->arch.tlbcfg[1] &=3D ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
> +	vcpu->arch.tlbcfg[1] &=3D
> +			      ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC | =
TLBnCFG_IND);
> 	vcpu->arch.tlbcfg[1] |=3D params.tlb_sizes[1];
> 	vcpu->arch.tlbcfg[1] |=3D params.tlb_ways[1] << =
TLBnCFG_ASSOC_SHIFT;
>=20
> @@ -783,13 +785,13 @@ int kvmppc_e500_tlb_init(struct kvmppc_vcpu_e500 =
*vcpu_e500)
>=20
> 	/* Init TLB configuration register */
> 	vcpu->arch.tlbcfg[0] =3D mfspr(SPRN_TLB0CFG) &
> -			     ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
> +			     ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC | =
TLBnCFG_IND);
> 	vcpu->arch.tlbcfg[0] |=3D vcpu_e500->gtlb_params[0].entries;
> 	vcpu->arch.tlbcfg[0] |=3D
> 		vcpu_e500->gtlb_params[0].ways << TLBnCFG_ASSOC_SHIFT;
>=20
> 	vcpu->arch.tlbcfg[1] =3D mfspr(SPRN_TLB1CFG) &
> -			     ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
> +			     ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC | =
TLBnCFG_IND);
> 	vcpu->arch.tlbcfg[1] |=3D vcpu_e500->gtlb_params[1].entries;
> 	vcpu->arch.tlbcfg[1] |=3D
> 		vcpu_e500->gtlb_params[1].ways << TLBnCFG_ASSOC_SHIFT;
> --=20
> 1.7.4.1
>=20
>=20
> --
> To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/5] KVM: PPC: e500: Emulate EPTCFG register

[Mihai Caraman]

EPTCFG register defined by E.PT is accessed unconditionally by Linux guests
in the presence of MAV 2.0. Emulate EPTCFG register now.

Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
---
 arch/powerpc/include/asm/kvm_host.h |    1 +
 arch/powerpc/kvm/e500.h             |    6 ++++++
 arch/powerpc/kvm/e500_emulate.c     |    9 +++++++++
 arch/powerpc/kvm/e500_mmu.c         |    5 +++++
 4 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
index 88fcfe6..f480b20 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -503,6 +503,7 @@ struct kvm_vcpu_arch {
 	u32 tlbcfg[4];
 	u32 tlbps[4];
 	u32 mmucfg;
+	u32 eptcfg;
 	u32 epr;
 	struct kvmppc_booke_debug_reg dbg_reg;
 #endif
diff --git a/arch/powerpc/kvm/e500.h b/arch/powerpc/kvm/e500.h
index b9f76d8..983eb95 100644
--- a/arch/powerpc/kvm/e500.h
+++ b/arch/powerpc/kvm/e500.h
@@ -308,4 +308,10 @@ static inline unsigned int has_mmu_v2(const struct kvm_vcpu *vcpu)
 	return ((vcpu->arch.mmucfg & MMUCFG_MAVN) == MMUCFG_MAVN_V2);
 }
 
+static inline unsigned int supports_page_tables(const struct kvm_vcpu *vcpu)
+{
+	return ((vcpu->arch.tlbcfg[0] & TLBnCFG_IND)
+		|| (vcpu->arch.tlbcfg[1] & TLBnCFG_IND));
+}
+
 #endif /* KVM_E500_H */
diff --git a/arch/powerpc/kvm/e500_emulate.c b/arch/powerpc/kvm/e500_emulate.c
index 5515dc5..493e231 100644
--- a/arch/powerpc/kvm/e500_emulate.c
+++ b/arch/powerpc/kvm/e500_emulate.c
@@ -339,6 +339,15 @@ int kvmppc_core_emulate_mfspr(struct kvm_vcpu *vcpu, int sprn, ulong *spr_val)
 			return EMULATE_FAIL;
 		*spr_val = vcpu->arch.tlbps[1];
 		break;
+	case SPRN_EPTCFG:
+		if (!has_mmu_v2(vcpu))
+			return EMULATE_FAIL;
+		/*
+		 * Legacy Linux guests access EPTCFG register even if the E.PT
+		 * category is disabled in the VM. Give them a chance to live.
+		 */
+		*spr_val = vcpu->arch.eptcfg;
+		break;
 	default:
 		emulated = kvmppc_booke_emulate_mfspr(vcpu, sprn, spr_val);
 	}
diff --git a/arch/powerpc/kvm/e500_mmu.c b/arch/powerpc/kvm/e500_mmu.c
index 9a1f7b7..199c11e 100644
--- a/arch/powerpc/kvm/e500_mmu.c
+++ b/arch/powerpc/kvm/e500_mmu.c
@@ -799,6 +799,11 @@ int kvmppc_e500_tlb_init(struct kvmppc_vcpu_e500 *vcpu_e500)
 	if (has_mmu_v2(vcpu)) {
 		vcpu->arch.tlbps[0] = mfspr(SPRN_TLB0PS);
 		vcpu->arch.tlbps[1] = mfspr(SPRN_TLB1PS);
+
+		if (supports_page_tables(vcpu))
+			vcpu->arch.eptcfg = mfspr(SPRN_EPTCFG);
+		else
+			vcpu->arch.eptcfg = 0;
 	}
 
 	kvmppc_recalc_tlb1map_range(vcpu_e500);
-- 
1.7.4.1

Re: [PATCH 4/5] KVM: PPC: e500: Emulate EPTCFG register

[Alexander Graf]

On 30.01.2013, at 14:29, Mihai Caraman wrote:

> EPTCFG register defined by E.PT is accessed unconditionally by Linux =
guests
> in the presence of MAV 2.0. Emulate EPTCFG register now.
>=20
> Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
> ---
> arch/powerpc/include/asm/kvm_host.h |    1 +
> arch/powerpc/kvm/e500.h             |    6 ++++++
> arch/powerpc/kvm/e500_emulate.c     |    9 +++++++++
> arch/powerpc/kvm/e500_mmu.c         |    5 +++++
> 4 files changed, 21 insertions(+), 0 deletions(-)
>=20
> diff --git a/arch/powerpc/include/asm/kvm_host.h =
b/arch/powerpc/include/asm/kvm_host.h
> index 88fcfe6..f480b20 100644
> --- a/arch/powerpc/include/asm/kvm_host.h
> +++ b/arch/powerpc/include/asm/kvm_host.h
> @@ -503,6 +503,7 @@ struct kvm_vcpu_arch {
> 	u32 tlbcfg[4];
> 	u32 tlbps[4];
> 	u32 mmucfg;
> +	u32 eptcfg;

This too needs to be settable through SW_TLB.

> 	u32 epr;
> 	struct kvmppc_booke_debug_reg dbg_reg;
> #endif
> diff --git a/arch/powerpc/kvm/e500.h b/arch/powerpc/kvm/e500.h
> index b9f76d8..983eb95 100644
> --- a/arch/powerpc/kvm/e500.h
> +++ b/arch/powerpc/kvm/e500.h
> @@ -308,4 +308,10 @@ static inline unsigned int has_mmu_v2(const =
struct kvm_vcpu *vcpu)
> 	return ((vcpu->arch.mmucfg & MMUCFG_MAVN) =3D=3D =
MMUCFG_MAVN_V2);
> }
>=20
> +static inline unsigned int supports_page_tables(const struct kvm_vcpu =
*vcpu)

bool again. Can we generalize this a bit more? How about a small =
framework that allows us to differentiate across e.XX features?

if (has_feature(vcpu, FEATURE_E_PT))
   ...


> +{
> +	return ((vcpu->arch.tlbcfg[0] & TLBnCFG_IND)
> +		|| (vcpu->arch.tlbcfg[1] & TLBnCFG_IND));
> +}
> +
> #endif /* KVM_E500_H */
> diff --git a/arch/powerpc/kvm/e500_emulate.c =
b/arch/powerpc/kvm/e500_emulate.c
> index 5515dc5..493e231 100644
> --- a/arch/powerpc/kvm/e500_emulate.c
> +++ b/arch/powerpc/kvm/e500_emulate.c
> @@ -339,6 +339,15 @@ int kvmppc_core_emulate_mfspr(struct kvm_vcpu =
*vcpu, int sprn, ulong *spr_val)
> 			return EMULATE_FAIL;
> 		*spr_val =3D vcpu->arch.tlbps[1];
> 		break;
> +	case SPRN_EPTCFG:
> +		if (!has_mmu_v2(vcpu))
> +			return EMULATE_FAIL;
> +		/*
> +		 * Legacy Linux guests access EPTCFG register even if =
the E.PT
> +		 * category is disabled in the VM. Give them a chance to =
live.
> +		 */
> +		*spr_val =3D vcpu->arch.eptcfg;
> +		break;
> 	default:
> 		emulated =3D kvmppc_booke_emulate_mfspr(vcpu, sprn, =
spr_val);
> 	}
> diff --git a/arch/powerpc/kvm/e500_mmu.c b/arch/powerpc/kvm/e500_mmu.c
> index 9a1f7b7..199c11e 100644
> --- a/arch/powerpc/kvm/e500_mmu.c
> +++ b/arch/powerpc/kvm/e500_mmu.c
> @@ -799,6 +799,11 @@ int kvmppc_e500_tlb_init(struct kvmppc_vcpu_e500 =
*vcpu_e500)
> 	if (has_mmu_v2(vcpu)) {
> 		vcpu->arch.tlbps[0] =3D mfspr(SPRN_TLB0PS);
> 		vcpu->arch.tlbps[1] =3D mfspr(SPRN_TLB1PS);
> +
> +		if (supports_page_tables(vcpu))
> +			vcpu->arch.eptcfg =3D mfspr(SPRN_EPTCFG);

Please don't introduce new mfspr()s here :). Just have user space set =
it.


Alex

> +		else
> +			vcpu->arch.eptcfg =3D 0;
> 	}
>=20
> 	kvmppc_recalc_tlb1map_range(vcpu_e500);
> --=20
> 1.7.4.1
>=20
>=20
> --
> To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 4/5] KVM: PPC: e500: Emulate EPTCFG register

[Caraman Mihai Claudiu-B02008]

> -----Original Message-----
> From: Alexander Graf [mailto:agraf@suse.de]
> Sent: Thursday, January 31, 2013 3:31 PM
> To: Caraman Mihai Claudiu-B02008
> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
> dev@lists.ozlabs.org
> Subject: Re: [PATCH 4/5] KVM: PPC: e500: Emulate EPTCFG register
>=20
>=20
> On 30.01.2013, at 14:29, Mihai Caraman wrote:
>=20
> > EPTCFG register defined by E.PT is accessed unconditionally by Linux
> guests
> > in the presence of MAV 2.0. Emulate EPTCFG register now.
> >
> > Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
> > ---
> > arch/powerpc/include/asm/kvm_host.h |    1 +
> > arch/powerpc/kvm/e500.h             |    6 ++++++
> > arch/powerpc/kvm/e500_emulate.c     |    9 +++++++++
> > arch/powerpc/kvm/e500_mmu.c         |    5 +++++
> > 4 files changed, 21 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/powerpc/include/asm/kvm_host.h
> b/arch/powerpc/include/asm/kvm_host.h
> > index 88fcfe6..f480b20 100644
> > --- a/arch/powerpc/include/asm/kvm_host.h
> > +++ b/arch/powerpc/include/asm/kvm_host.h
> > @@ -503,6 +503,7 @@ struct kvm_vcpu_arch {
> > 	u32 tlbcfg[4];
> > 	u32 tlbps[4];
> > 	u32 mmucfg;
> > +	u32 eptcfg;
>=20
> This too needs to be settable through SW_TLB.
>=20
> > 	u32 epr;
> > 	struct kvmppc_booke_debug_reg dbg_reg;
> > #endif
> > diff --git a/arch/powerpc/kvm/e500.h b/arch/powerpc/kvm/e500.h
> > index b9f76d8..983eb95 100644
> > --- a/arch/powerpc/kvm/e500.h
> > +++ b/arch/powerpc/kvm/e500.h
> > @@ -308,4 +308,10 @@ static inline unsigned int has_mmu_v2(const struct
> kvm_vcpu *vcpu)
> > 	return ((vcpu->arch.mmucfg & MMUCFG_MAVN) =3D=3D MMUCFG_MAVN_V2);
> > }
> >
> > +static inline unsigned int supports_page_tables(const struct kvm_vcpu
> *vcpu)
>=20
> bool again. Can we generalize this a bit more? How about a small
> framework that allows us to differentiate across e.XX features?=20

I thought you will ask for it :)

-Mike

[PATCH 5/5] KVM: PPC: e500mc: Enable e6500 cores

[Mihai Caraman]

Extend processor compatibility names to e6500 cores.

Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
---
 arch/powerpc/kvm/e500mc.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/kvm/e500mc.c b/arch/powerpc/kvm/e500mc.c
index 1f89d26..6c87299 100644
--- a/arch/powerpc/kvm/e500mc.c
+++ b/arch/powerpc/kvm/e500mc.c
@@ -172,6 +172,8 @@ int kvmppc_core_check_processor_compat(void)
 		r = 0;
 	else if (strcmp(cur_cpu_spec->cpu_name, "e5500") == 0)
 		r = 0;
+	else if (strcmp(cur_cpu_spec->cpu_name, "e6500") == 0)
+		r = 0;
 	else
 		r = -ENOTSUPP;
 
-- 
1.7.4.1

Re: [PATCH 5/5] KVM: PPC: e500mc: Enable e6500 cores

[Alexander Graf]

On 30.01.2013, at 14:29, Mihai Caraman wrote:

> Extend processor compatibility names to e6500 cores.
> 
> Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>

Looks good to me.

Reviewed-by: Alexander Graf <agraf@suse.de>


Alex

> ---
> arch/powerpc/kvm/e500mc.c |    2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/powerpc/kvm/e500mc.c b/arch/powerpc/kvm/e500mc.c
> index 1f89d26..6c87299 100644
> --- a/arch/powerpc/kvm/e500mc.c
> +++ b/arch/powerpc/kvm/e500mc.c
> @@ -172,6 +172,8 @@ int kvmppc_core_check_processor_compat(void)
> 		r = 0;
> 	else if (strcmp(cur_cpu_spec->cpu_name, "e5500") == 0)
> 		r = 0;
> +	else if (strcmp(cur_cpu_spec->cpu_name, "e6500") == 0)
> +		r = 0;
> 	else
> 		r = -ENOTSUPP;
> 
> -- 
> 1.7.4.1
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html