* [RFC PATCH 1/6] KVM: PPC: Book3E: Fix AltiVec interrupt numbers and build breakage
2013-06-03 20:54 [RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support Mihai Caraman
@ 2013-06-03 20:54 ` Mihai Caraman
2013-06-03 20:54 ` [RFC PATCH 2/6] KVM: PPC: Book3E: Refactor SPE_FP exit handling Mihai Caraman
` (5 subsequent siblings)
6 siblings, 0 replies; 25+ messages in thread
From: Mihai Caraman @ 2013-06-03 20:54 UTC (permalink / raw)
To: kvm-ppc; +Cc: Mihai Caraman, linuxppc-dev, kvm
Interrupt numbers defined for Book3E follows IVORs definition. Align
BOOKE_INTERRUPT_ALTIVEC_UNAVAIL and BOOKE_INTERRUPT_ALTIVEC_ASSIST to this
rule which also fixes the build breakage.
IVORs 32 and 33 are shared so reflect this in the interrupts naming.
Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
---
arch/powerpc/include/asm/kvm_asm.h | 16 ++++++++++------
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_asm.h b/arch/powerpc/include/asm/kvm_asm.h
index b9dd382..851bac7 100644
--- a/arch/powerpc/include/asm/kvm_asm.h
+++ b/arch/powerpc/include/asm/kvm_asm.h
@@ -54,8 +54,16 @@
#define BOOKE_INTERRUPT_DEBUG 15
/* E500 */
-#define BOOKE_INTERRUPT_SPE_UNAVAIL 32
-#define BOOKE_INTERRUPT_SPE_FP_DATA 33
+#define BOOKE_INTERRUPT_SPE_ALTIVEC_UNAVAIL 32
+#define BOOKE_INTERRUPT_SPE_FP_DATA_ALTIVEC_ASSIST 33
+/*
+ * TODO: Unify 32-bit and 64-bit kernel exception handlers to use same defines
+ */
+#define BOOKE_INTERRUPT_SPE_UNAVAIL BOOKE_INTERRUPT_SPE_ALTIVEC_UNAVAIL
+#define BOOKE_INTERRUPT_SPE_FP_DATA BOOKE_INTERRUPT_SPE_FP_DATA_ALTIVEC_ASSIST
+#define BOOKE_INTERRUPT_ALTIVEC_UNAVAIL BOOKE_INTERRUPT_SPE_ALTIVEC_UNAVAIL
+#define BOOKE_INTERRUPT_ALTIVEC_ASSIST \
+ BOOKE_INTERRUPT_SPE_FP_DATA_ALTIVEC_ASSIST
#define BOOKE_INTERRUPT_SPE_FP_ROUND 34
#define BOOKE_INTERRUPT_PERFORMANCE_MONITOR 35
#define BOOKE_INTERRUPT_DOORBELL 36
@@ -67,10 +75,6 @@
#define BOOKE_INTERRUPT_HV_SYSCALL 40
#define BOOKE_INTERRUPT_HV_PRIV 41
-/* altivec */
-#define BOOKE_INTERRUPT_ALTIVEC_UNAVAIL 42
-#define BOOKE_INTERRUPT_ALTIVEC_ASSIST 43
-
/* book3s */
#define BOOK3S_INTERRUPT_SYSTEM_RESET 0x100
--
1.7.4.1
^ permalink raw reply related [flat|nested] 25+ messages in thread* [RFC PATCH 2/6] KVM: PPC: Book3E: Refactor SPE_FP exit handling
2013-06-03 20:54 [RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support Mihai Caraman
2013-06-03 20:54 ` [RFC PATCH 1/6] KVM: PPC: Book3E: Fix AltiVec interrupt numbers and build breakage Mihai Caraman
@ 2013-06-03 20:54 ` Mihai Caraman
2013-06-04 22:14 ` Scott Wood
2013-06-03 20:54 ` [RFC PATCH 3/6] KVM: PPC: Book3E: Rename IRQPRIO names to accommodate ALTIVEC Mihai Caraman
` (4 subsequent siblings)
6 siblings, 1 reply; 25+ messages in thread
From: Mihai Caraman @ 2013-06-03 20:54 UTC (permalink / raw)
To: kvm-ppc; +Cc: Mihai Caraman, linuxppc-dev, kvm
SPE_FP interrupts are shared with ALTIVEC. Refactor SPE_FP exit handling
to detect KVM support for the featured unit at run-time, in order to
accommodate ALTIVEC later.
Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
---
arch/powerpc/kvm/booke.c | 80 ++++++++++++++++++++++++++++++++++------------
1 files changed, 59 insertions(+), 21 deletions(-)
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 1020119..d082bbc 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -822,6 +822,15 @@ static void kvmppc_restart_interrupt(struct kvm_vcpu *vcpu,
}
}
+static inline bool kvmppc_supports_spe(void)
+{
+#ifdef CONFIG_SPE
+ if (cpu_has_feature(CPU_FTR_SPE))
+ return true;
+#endif
+ return false;
+}
+
/**
* kvmppc_handle_exit
*
@@ -931,42 +940,71 @@ int kvmppc_handle_exit(struct kvm_run *run, struct kvm_vcpu *vcpu,
r = RESUME_GUEST;
break;
-#ifdef CONFIG_SPE
case BOOKE_INTERRUPT_SPE_UNAVAIL: {
- if (vcpu->arch.shared->msr & MSR_SPE)
- kvmppc_vcpu_enable_spe(vcpu);
- else
- kvmppc_booke_queue_irqprio(vcpu,
- BOOKE_IRQPRIO_SPE_UNAVAIL);
+ /*
+ * The interrupt is shared, KVM support for the featured unit
+ * is detected at run-time.
+ */
+ bool handled = false;
+
+ if (kvmppc_supports_spe()) {
+#ifdef CONFIG_SPE
+ if (cpu_has_feature(CPU_FTR_SPE))
+ if (vcpu->arch.shared->msr & MSR_SPE) {
+ kvmppc_vcpu_enable_spe(vcpu);
+ handled = true;
+ }
+#endif
+ if (!handled)
+ kvmppc_booke_queue_irqprio(vcpu,
+ BOOKE_IRQPRIO_SPE_UNAVAIL);
+ } else {
+ /*
+ * Guest wants SPE, but host kernel doesn't support it.
+ * Send an "unimplemented operation" program check to
+ * the guest.
+ */
+ kvmppc_core_queue_program(vcpu, ESR_PUO | ESR_SPV);
+ }
+
r = RESUME_GUEST;
break;
}
case BOOKE_INTERRUPT_SPE_FP_DATA:
- kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_SPE_FP_DATA);
- r = RESUME_GUEST;
+ /*
+ * The interrupt is shared, KVM support for the featured unit
+ * is detected at run-time.
+ */
+ if (kvmppc_supports_spe()) {
+ kvmppc_booke_queue_irqprio(vcpu,
+ BOOKE_IRQPRIO_SPE_FP_DATA);
+ r = RESUME_GUEST;
+ } else {
+ /*
+ * These really should never happen without CONFIG_SPE,
+ * as we should never enable the real MSR[SPE] in the
+ * guest.
+ */
+ printk(KERN_CRIT "%s: unexpected SPE interrupt %u at \
+ %08lx\n", __func__, exit_nr, vcpu->arch.pc);
+ run->hw.hardware_exit_reason = exit_nr;
+ r = RESUME_HOST;
+ }
+
break;
case BOOKE_INTERRUPT_SPE_FP_ROUND:
+#ifdef CONFIG_SPE
kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_SPE_FP_ROUND);
r = RESUME_GUEST;
break;
#else
- case BOOKE_INTERRUPT_SPE_UNAVAIL:
/*
- * Guest wants SPE, but host kernel doesn't support it. Send
- * an "unimplemented operation" program check to the guest.
+ * These really should never happen without CONFIG_SPE,
+ * as we should never enable the real MSR[SPE] in the
+ * guest.
*/
- kvmppc_core_queue_program(vcpu, ESR_PUO | ESR_SPV);
- r = RESUME_GUEST;
- break;
-
- /*
- * These really should never happen without CONFIG_SPE,
- * as we should never enable the real MSR[SPE] in the guest.
- */
- case BOOKE_INTERRUPT_SPE_FP_DATA:
- case BOOKE_INTERRUPT_SPE_FP_ROUND:
printk(KERN_CRIT "%s: unexpected SPE interrupt %u at %08lx\n",
__func__, exit_nr, vcpu->arch.pc);
run->hw.hardware_exit_reason = exit_nr;
--
1.7.4.1
^ permalink raw reply related [flat|nested] 25+ messages in thread* Re: [RFC PATCH 2/6] KVM: PPC: Book3E: Refactor SPE_FP exit handling
2013-06-03 20:54 ` [RFC PATCH 2/6] KVM: PPC: Book3E: Refactor SPE_FP exit handling Mihai Caraman
@ 2013-06-04 22:14 ` Scott Wood
2013-06-05 7:29 ` Caraman Mihai Claudiu-B02008
0 siblings, 1 reply; 25+ messages in thread
From: Scott Wood @ 2013-06-04 22:14 UTC (permalink / raw)
To: Mihai Caraman; +Cc: Mihai Caraman, linuxppc-dev, kvm, kvm-ppc
On 06/03/2013 03:54:24 PM, Mihai Caraman wrote:
> SPE_FP interrupts are shared with ALTIVEC. Refactor SPE_FP exit =20
> handling
> to detect KVM support for the featured unit at run-time, in order to
> accommodate ALTIVEC later.
>=20
> Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
> ---
> arch/powerpc/kvm/booke.c | 80 =20
> ++++++++++++++++++++++++++++++++++------------
> 1 files changed, 59 insertions(+), 21 deletions(-)
>=20
> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> index 1020119..d082bbc 100644
> --- a/arch/powerpc/kvm/booke.c
> +++ b/arch/powerpc/kvm/booke.c
> @@ -822,6 +822,15 @@ static void kvmppc_restart_interrupt(struct =20
> kvm_vcpu *vcpu,
> }
> }
>=20
> +static inline bool kvmppc_supports_spe(void)
> +{
> +#ifdef CONFIG_SPE
> + if (cpu_has_feature(CPU_FTR_SPE))
> + return true;
> +#endif
> + return false;
> +}
Whitespace
> /**
> * kvmppc_handle_exit
> *
> @@ -931,42 +940,71 @@ int kvmppc_handle_exit(struct kvm_run *run, =20
> struct kvm_vcpu *vcpu,
> r =3D RESUME_GUEST;
> break;
>=20
> -#ifdef CONFIG_SPE
> case BOOKE_INTERRUPT_SPE_UNAVAIL: {
> - if (vcpu->arch.shared->msr & MSR_SPE)
> - kvmppc_vcpu_enable_spe(vcpu);
> - else
> - kvmppc_booke_queue_irqprio(vcpu,
> - =20
> BOOKE_IRQPRIO_SPE_UNAVAIL);
> + /*
> + * The interrupt is shared, KVM support for the =20
> featured unit
> + * is detected at run-time.
> + */
This is a decent comment for the changelog, but for the code itself it =20
seems fairly obvious if you look at the definition of =20
kvmppc_supports_spe().
> + bool handled =3D false;
> +
> + if (kvmppc_supports_spe()) {
> +#ifdef CONFIG_SPE
> + if (cpu_has_feature(CPU_FTR_SPE))
Didn't you already check this using kvmppc_supports_spe()?
> case BOOKE_INTERRUPT_SPE_FP_ROUND:
> +#ifdef CONFIG_SPE
> kvmppc_booke_queue_irqprio(vcpu, =20
> BOOKE_IRQPRIO_SPE_FP_ROUND);
> r =3D RESUME_GUEST;
> break;
Why not use kvmppc_supports_spe() here, for consistency?
-Scott=
^ permalink raw reply [flat|nested] 25+ messages in thread* RE: [RFC PATCH 2/6] KVM: PPC: Book3E: Refactor SPE_FP exit handling
2013-06-04 22:14 ` Scott Wood
@ 2013-06-05 7:29 ` Caraman Mihai Claudiu-B02008
2013-06-05 19:07 ` Scott Wood
0 siblings, 1 reply; 25+ messages in thread
From: Caraman Mihai Claudiu-B02008 @ 2013-06-05 7:29 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org,
kvm-ppc@vger.kernel.org
> > + /*
> > + * The interrupt is shared, KVM support for the
> > featured unit
> > + * is detected at run-time.
> > + */
>=20
> This is a decent comment for the changelog, but for the code itself it
> seems fairly obvious if you look at the definition of
> kvmppc_supports_spe().
I will move it to change log.
>=20
> > + bool handled =3D false;
> > +
> > + if (kvmppc_supports_spe()) {
> > +#ifdef CONFIG_SPE
> > + if (cpu_has_feature(CPU_FTR_SPE))
>=20
> Didn't you already check this using kvmppc_supports_spe()?
It makes sense with the next patch. It handles the improbable case of havin=
g
CONFIG_ALTIVEC and CONFIG_SPE defined:
if (kvmppc_supports_altivec() || kvmppc_supports_spe()).
>=20
> > case BOOKE_INTERRUPT_SPE_FP_ROUND:
> > +#ifdef CONFIG_SPE
> > kvmppc_booke_queue_irqprio(vcpu,
> > BOOKE_IRQPRIO_SPE_FP_ROUND);
> > r =3D RESUME_GUEST;
> > break;
>=20
> Why not use kvmppc_supports_spe() here, for consistency?
I added cpu_has_feature(CPU_FTR_SPE) for the case specified above, but here
SPE_FP_ROUND is not shared with ALTIVEC. CONFIG_SPE is used in other places
in KVM without this check, shouldn't be all or nothing?
-Mike
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [RFC PATCH 2/6] KVM: PPC: Book3E: Refactor SPE_FP exit handling
2013-06-05 7:29 ` Caraman Mihai Claudiu-B02008
@ 2013-06-05 19:07 ` Scott Wood
0 siblings, 0 replies; 25+ messages in thread
From: Scott Wood @ 2013-06-05 19:07 UTC (permalink / raw)
To: Caraman Mihai Claudiu-B02008
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
kvm@vger.kernel.org, kvm-ppc@vger.kernel.org
On 06/05/2013 02:29:47 AM, Caraman Mihai Claudiu-B02008 wrote:
> > > case BOOKE_INTERRUPT_SPE_FP_ROUND:
> > > +#ifdef CONFIG_SPE
> > > kvmppc_booke_queue_irqprio(vcpu,
> > > BOOKE_IRQPRIO_SPE_FP_ROUND);
> > > r =3D RESUME_GUEST;
> > > break;
> >
> > Why not use kvmppc_supports_spe() here, for consistency?
>=20
> I added cpu_has_feature(CPU_FTR_SPE) for the case specified above, =20
> but here
> SPE_FP_ROUND is not shared with ALTIVEC. CONFIG_SPE is used in other =20
> places
> in KVM without this check, shouldn't be all or nothing?
I'd rather it be consistent, at least between handling one exception =20
and another.
-Scott=
^ permalink raw reply [flat|nested] 25+ messages in thread
* [RFC PATCH 3/6] KVM: PPC: Book3E: Rename IRQPRIO names to accommodate ALTIVEC
2013-06-03 20:54 [RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support Mihai Caraman
2013-06-03 20:54 ` [RFC PATCH 1/6] KVM: PPC: Book3E: Fix AltiVec interrupt numbers and build breakage Mihai Caraman
2013-06-03 20:54 ` [RFC PATCH 2/6] KVM: PPC: Book3E: Refactor SPE_FP exit handling Mihai Caraman
@ 2013-06-03 20:54 ` Mihai Caraman
2013-06-04 22:28 ` Scott Wood
2013-06-03 20:54 ` [RFC PATCH 4/6] KVM: PPC: Book3E: Add AltiVec support Mihai Caraman
` (3 subsequent siblings)
6 siblings, 1 reply; 25+ messages in thread
From: Mihai Caraman @ 2013-06-03 20:54 UTC (permalink / raw)
To: kvm-ppc; +Cc: Mihai Caraman, linuxppc-dev, kvm
Rename BOOKE_IRQPRIO_SPE_UNAVAIL and BOOKE_IRQPRIO_SPE_FP_DATA names
to accommodate ALTIVEC. Replace BOOKE_INTERRUPT_SPE_UNAVAIL and
BOOKE_INTERRUPT_SPE_FP_DATA with the common version.
Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
---
arch/powerpc/kvm/booke.c | 12 ++++++------
arch/powerpc/kvm/booke.h | 4 ++--
arch/powerpc/kvm/bookehv_interrupts.S | 8 ++++----
arch/powerpc/kvm/e500.c | 10 ++++++----
arch/powerpc/kvm/e500_emulate.c | 8 ++++----
5 files changed, 22 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index d082bbc..c08b04b 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -362,8 +362,8 @@ static int kvmppc_booke_irqprio_deliver(struct kvm_vcpu *vcpu,
case BOOKE_IRQPRIO_ITLB_MISS:
case BOOKE_IRQPRIO_SYSCALL:
case BOOKE_IRQPRIO_FP_UNAVAIL:
- case BOOKE_IRQPRIO_SPE_UNAVAIL:
- case BOOKE_IRQPRIO_SPE_FP_DATA:
+ case BOOKE_IRQPRIO_SPE_ALTIVEC_UNAVAIL:
+ case BOOKE_IRQPRIO_SPE_FP_DATA_ALTIVEC_ASSIST:
case BOOKE_IRQPRIO_SPE_FP_ROUND:
case BOOKE_IRQPRIO_AP_UNAVAIL:
allowed = 1;
@@ -940,7 +940,7 @@ int kvmppc_handle_exit(struct kvm_run *run, struct kvm_vcpu *vcpu,
r = RESUME_GUEST;
break;
- case BOOKE_INTERRUPT_SPE_UNAVAIL: {
+ case BOOKE_INTERRUPT_SPE_ALTIVEC_UNAVAIL: {
/*
* The interrupt is shared, KVM support for the featured unit
* is detected at run-time.
@@ -957,7 +957,7 @@ int kvmppc_handle_exit(struct kvm_run *run, struct kvm_vcpu *vcpu,
#endif
if (!handled)
kvmppc_booke_queue_irqprio(vcpu,
- BOOKE_IRQPRIO_SPE_UNAVAIL);
+ BOOKE_IRQPRIO_SPE_ALTIVEC_UNAVAIL);
} else {
/*
* Guest wants SPE, but host kernel doesn't support it.
@@ -971,14 +971,14 @@ int kvmppc_handle_exit(struct kvm_run *run, struct kvm_vcpu *vcpu,
break;
}
- case BOOKE_INTERRUPT_SPE_FP_DATA:
+ case BOOKE_INTERRUPT_SPE_FP_DATA_ALTIVEC_ASSIST:
/*
* The interrupt is shared, KVM support for the featured unit
* is detected at run-time.
*/
if (kvmppc_supports_spe()) {
kvmppc_booke_queue_irqprio(vcpu,
- BOOKE_IRQPRIO_SPE_FP_DATA);
+ BOOKE_IRQPRIO_SPE_FP_DATA_ALTIVEC_ASSIST);
r = RESUME_GUEST;
} else {
/*
diff --git a/arch/powerpc/kvm/booke.h b/arch/powerpc/kvm/booke.h
index 5fd1ba6..9e92006 100644
--- a/arch/powerpc/kvm/booke.h
+++ b/arch/powerpc/kvm/booke.h
@@ -32,8 +32,8 @@
#define BOOKE_IRQPRIO_ALIGNMENT 2
#define BOOKE_IRQPRIO_PROGRAM 3
#define BOOKE_IRQPRIO_FP_UNAVAIL 4
-#define BOOKE_IRQPRIO_SPE_UNAVAIL 5
-#define BOOKE_IRQPRIO_SPE_FP_DATA 6
+#define BOOKE_IRQPRIO_SPE_ALTIVEC_UNAVAIL 5
+#define BOOKE_IRQPRIO_SPE_FP_DATA_ALTIVEC_ASSIST 6
#define BOOKE_IRQPRIO_SPE_FP_ROUND 7
#define BOOKE_IRQPRIO_SYSCALL 8
#define BOOKE_IRQPRIO_AP_UNAVAIL 9
diff --git a/arch/powerpc/kvm/bookehv_interrupts.S b/arch/powerpc/kvm/bookehv_interrupts.S
index e8ed7d6..8d35dc0 100644
--- a/arch/powerpc/kvm/bookehv_interrupts.S
+++ b/arch/powerpc/kvm/bookehv_interrupts.S
@@ -295,9 +295,9 @@ kvm_handler BOOKE_INTERRUPT_DTLB_MISS, EX_PARAMS_TLB, \
SPRN_SRR0, SPRN_SRR1, (NEED_EMU | NEED_DEAR | NEED_ESR)
kvm_handler BOOKE_INTERRUPT_ITLB_MISS, EX_PARAMS_TLB, \
SPRN_SRR0, SPRN_SRR1, 0
-kvm_handler BOOKE_INTERRUPT_SPE_UNAVAIL, EX_PARAMS(GEN), \
+kvm_handler BOOKE_INTERRUPT_SPE_ALTIVEC_UNAVAIL, EX_PARAMS(GEN), \
SPRN_SRR0, SPRN_SRR1, 0
-kvm_handler BOOKE_INTERRUPT_SPE_FP_DATA, EX_PARAMS(GEN), \
+kvm_handler BOOKE_INTERRUPT_SPE_FP_DATA_ALTIVEC_ASSIST, EX_PARAMS(GEN), \
SPRN_SRR0, SPRN_SRR1, 0
kvm_handler BOOKE_INTERRUPT_SPE_FP_ROUND, EX_PARAMS(GEN), \
SPRN_SRR0, SPRN_SRR1, 0
@@ -398,8 +398,8 @@ kvm_lvl_handler BOOKE_INTERRUPT_WATCHDOG, \
kvm_handler BOOKE_INTERRUPT_DTLB_MISS, \
SPRN_SRR0, SPRN_SRR1, (NEED_EMU | NEED_DEAR | NEED_ESR)
kvm_handler BOOKE_INTERRUPT_ITLB_MISS, SPRN_SRR0, SPRN_SRR1, 0
-kvm_handler BOOKE_INTERRUPT_SPE_UNAVAIL, SPRN_SRR0, SPRN_SRR1, 0
-kvm_handler BOOKE_INTERRUPT_SPE_FP_DATA, SPRN_SRR0, SPRN_SRR1, 0
+kvm_handler BOOKE_INTERRUPT_SPE_ALTIVEC_UNAVAIL, SPRN_SRR0, SPRN_SRR1, 0
+kvm_handler BOOKE_INTERRUPT_SPE_FP_DATA_ALTIVEC_ASSIST, SPRN_SRR0, SPRN_SRR1, 0
kvm_handler BOOKE_INTERRUPT_SPE_FP_ROUND, SPRN_SRR0, SPRN_SRR1, 0
kvm_handler BOOKE_INTERRUPT_PERFORMANCE_MONITOR, SPRN_SRR0, SPRN_SRR1, 0
kvm_handler BOOKE_INTERRUPT_DOORBELL, SPRN_SRR0, SPRN_SRR1, 0
diff --git a/arch/powerpc/kvm/e500.c b/arch/powerpc/kvm/e500.c
index ce6b73c..0fb2f4d 100644
--- a/arch/powerpc/kvm/e500.c
+++ b/arch/powerpc/kvm/e500.c
@@ -380,8 +380,10 @@ void kvmppc_core_get_sregs(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs)
sregs->u.e.impl.fsl.hid0 = vcpu_e500->hid0;
sregs->u.e.impl.fsl.mcar = vcpu_e500->mcar;
- sregs->u.e.ivor_high[0] = vcpu->arch.ivor[BOOKE_IRQPRIO_SPE_UNAVAIL];
- sregs->u.e.ivor_high[1] = vcpu->arch.ivor[BOOKE_IRQPRIO_SPE_FP_DATA];
+ sregs->u.e.ivor_high[0] =
+ vcpu->arch.ivor[BOOKE_IRQPRIO_SPE_ALTIVEC_UNAVAIL];
+ sregs->u.e.ivor_high[1] =
+ vcpu->arch.ivor[BOOKE_IRQPRIO_SPE_FP_DATA_ALTIVEC_ASSIST];
sregs->u.e.ivor_high[2] = vcpu->arch.ivor[BOOKE_IRQPRIO_SPE_FP_ROUND];
sregs->u.e.ivor_high[3] =
vcpu->arch.ivor[BOOKE_IRQPRIO_PERFORMANCE_MONITOR];
@@ -409,9 +411,9 @@ int kvmppc_core_set_sregs(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs)
return 0;
if (sregs->u.e.features & KVM_SREGS_E_SPE) {
- vcpu->arch.ivor[BOOKE_IRQPRIO_SPE_UNAVAIL] =
+ vcpu->arch.ivor[BOOKE_IRQPRIO_SPE_ALTIVEC_UNAVAIL] =
sregs->u.e.ivor_high[0];
- vcpu->arch.ivor[BOOKE_IRQPRIO_SPE_FP_DATA] =
+ vcpu->arch.ivor[BOOKE_IRQPRIO_SPE_FP_DATA_ALTIVEC_ASSIST] =
sregs->u.e.ivor_high[1];
vcpu->arch.ivor[BOOKE_IRQPRIO_SPE_FP_ROUND] =
sregs->u.e.ivor_high[2];
diff --git a/arch/powerpc/kvm/e500_emulate.c b/arch/powerpc/kvm/e500_emulate.c
index b10a012..b2e159b 100644
--- a/arch/powerpc/kvm/e500_emulate.c
+++ b/arch/powerpc/kvm/e500_emulate.c
@@ -211,10 +211,10 @@ int kvmppc_core_emulate_mtspr(struct kvm_vcpu *vcpu, int sprn, ulong spr_val)
/* extra exceptions */
case SPRN_IVOR32:
- vcpu->arch.ivor[BOOKE_IRQPRIO_SPE_UNAVAIL] = spr_val;
+ vcpu->arch.ivor[BOOKE_IRQPRIO_SPE_ALTIVEC_UNAVAIL] = spr_val;
break;
case SPRN_IVOR33:
- vcpu->arch.ivor[BOOKE_IRQPRIO_SPE_FP_DATA] = spr_val;
+ vcpu->arch.ivor[BOOKE_IRQPRIO_SPE_FP_DATA_ALTIVEC_ASSIST] = spr_val;
break;
case SPRN_IVOR34:
vcpu->arch.ivor[BOOKE_IRQPRIO_SPE_FP_ROUND] = spr_val;
@@ -329,10 +329,10 @@ int kvmppc_core_emulate_mfspr(struct kvm_vcpu *vcpu, int sprn, ulong *spr_val)
/* extra exceptions */
case SPRN_IVOR32:
- *spr_val = vcpu->arch.ivor[BOOKE_IRQPRIO_SPE_UNAVAIL];
+ *spr_val = vcpu->arch.ivor[BOOKE_IRQPRIO_SPE_ALTIVEC_UNAVAIL];
break;
case SPRN_IVOR33:
- *spr_val = vcpu->arch.ivor[BOOKE_IRQPRIO_SPE_FP_DATA];
+ *spr_val = vcpu->arch.ivor[BOOKE_IRQPRIO_SPE_FP_DATA_ALTIVEC_ASSIST];
break;
case SPRN_IVOR34:
*spr_val = vcpu->arch.ivor[BOOKE_IRQPRIO_SPE_FP_ROUND];
--
1.7.4.1
^ permalink raw reply related [flat|nested] 25+ messages in thread* Re: [RFC PATCH 3/6] KVM: PPC: Book3E: Rename IRQPRIO names to accommodate ALTIVEC
2013-06-03 20:54 ` [RFC PATCH 3/6] KVM: PPC: Book3E: Rename IRQPRIO names to accommodate ALTIVEC Mihai Caraman
@ 2013-06-04 22:28 ` Scott Wood
2013-06-05 7:52 ` Caraman Mihai Claudiu-B02008
0 siblings, 1 reply; 25+ messages in thread
From: Scott Wood @ 2013-06-04 22:28 UTC (permalink / raw)
To: Mihai Caraman; +Cc: Mihai Caraman, linuxppc-dev, kvm, kvm-ppc
On 06/03/2013 03:54:25 PM, Mihai Caraman wrote:
> Rename BOOKE_IRQPRIO_SPE_UNAVAIL and BOOKE_IRQPRIO_SPE_FP_DATA names
> to accommodate ALTIVEC. Replace BOOKE_INTERRUPT_SPE_UNAVAIL and
> BOOKE_INTERRUPT_SPE_FP_DATA with the common version.
>=20
> Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
> ---
> arch/powerpc/kvm/booke.c | 12 ++++++------
> arch/powerpc/kvm/booke.h | 4 ++--
> arch/powerpc/kvm/bookehv_interrupts.S | 8 ++++----
> arch/powerpc/kvm/e500.c | 10 ++++++----
> arch/powerpc/kvm/e500_emulate.c | 8 ++++----
> 5 files changed, 22 insertions(+), 20 deletions(-)
Can you remove the TODO separate definitions from 1/6 now? And/or =20
combine 1/6 with this patch?
-Scott=
^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: [RFC PATCH 3/6] KVM: PPC: Book3E: Rename IRQPRIO names to accommodate ALTIVEC
2013-06-04 22:28 ` Scott Wood
@ 2013-06-05 7:52 ` Caraman Mihai Claudiu-B02008
0 siblings, 0 replies; 25+ messages in thread
From: Caraman Mihai Claudiu-B02008 @ 2013-06-05 7:52 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org,
kvm-ppc@vger.kernel.org
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Wednesday, June 05, 2013 1:28 AM
> To: Caraman Mihai Claudiu-B02008
> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
> dev@lists.ozlabs.org; Caraman Mihai Claudiu-B02008
> Subject: Re: [RFC PATCH 3/6] KVM: PPC: Book3E: Rename IRQPRIO names to
> accommodate ALTIVEC
>=20
> On 06/03/2013 03:54:25 PM, Mihai Caraman wrote:
> > Rename BOOKE_IRQPRIO_SPE_UNAVAIL and BOOKE_IRQPRIO_SPE_FP_DATA names
> > to accommodate ALTIVEC. Replace BOOKE_INTERRUPT_SPE_UNAVAIL and
> > BOOKE_INTERRUPT_SPE_FP_DATA with the common version.
> >
> > Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
> > ---
> > arch/powerpc/kvm/booke.c | 12 ++++++------
> > arch/powerpc/kvm/booke.h | 4 ++--
> > arch/powerpc/kvm/bookehv_interrupts.S | 8 ++++----
> > arch/powerpc/kvm/e500.c | 10 ++++++----
> > arch/powerpc/kvm/e500_emulate.c | 8 ++++----
> > 5 files changed, 22 insertions(+), 20 deletions(-)
>=20
> Can you remove the TODO separate definitions from 1/6 now? And/or
> combine 1/6 with this patch?
TODO separate definitions are for kernel code, they require a new patch
depending on comments. I sent 1/6 to fix the build brake generated
by this
/* altivec */
#define BOOKE_INTERRUPT_ALTIVEC_UNAVAIL 42
#define BOOKE_INTERRUPT_ALTIVEC_ASSIST 43
So if we agree that 42/43 numbers are wrong then I would prefer 1/6 (or som=
ething
similar) instead of adding new kvm_handlers (which legitimates the above co=
mmit)
just to remove them later.
-Mike
^ permalink raw reply [flat|nested] 25+ messages in thread
* [RFC PATCH 4/6] KVM: PPC: Book3E: Add AltiVec support
2013-06-03 20:54 [RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support Mihai Caraman
` (2 preceding siblings ...)
2013-06-03 20:54 ` [RFC PATCH 3/6] KVM: PPC: Book3E: Rename IRQPRIO names to accommodate ALTIVEC Mihai Caraman
@ 2013-06-03 20:54 ` Mihai Caraman
2013-06-04 22:36 ` Scott Wood
2013-06-03 20:54 ` [RFC PATCH 5/6] KVM: PPC: Book3E: Add ONE_REG " Mihai Caraman
` (2 subsequent siblings)
6 siblings, 1 reply; 25+ messages in thread
From: Mihai Caraman @ 2013-06-03 20:54 UTC (permalink / raw)
To: kvm-ppc; +Cc: Mihai Caraman, linuxppc-dev, kvm
KVM Book3E FPU support gracefully reuse host infrastructure so we do the
same for AltiVec. To keep AltiVec lazy call kvmppc_load_guest_altivec()
just when returning to guest instead of each sched in.
Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
---
arch/powerpc/kvm/booke.c | 74 +++++++++++++++++++++++++++++++++++++++++++-
arch/powerpc/kvm/e500mc.c | 8 +++++
2 files changed, 80 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index c08b04b..01eb635 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -134,6 +134,23 @@ static void kvmppc_vcpu_sync_fpu(struct kvm_vcpu *vcpu)
}
/*
+ * Simulate AltiVec unavailable fault to load guest state
+ * from thread to AltiVec unit.
+ * It requires to be called with preemption disabled.
+ */
+static inline void kvmppc_load_guest_altivec(struct kvm_vcpu *vcpu)
+{
+#ifdef CONFIG_ALTIVEC
+ if (cpu_has_feature(CPU_FTR_ALTIVEC)) {
+ if (!(current->thread.regs->msr & MSR_VEC)) {
+ load_up_altivec(NULL);
+ current->thread.regs->msr |= MSR_VEC;
+ }
+ }
+#endif
+}
+
+/*
* Helper function for "full" MSR writes. No need to call this if only
* EE/CE/ME/DE/RI are changing.
*/
@@ -661,6 +678,12 @@ int kvmppc_vcpu_run(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu)
u64 fpr[32];
#endif
+#ifdef CONFIG_ALTIVEC
+ vector128 vr[32];
+ vector128 vscr;
+ int used_vr = 0;
+#endif
+
if (!vcpu->arch.sane) {
kvm_run->exit_reason = KVM_EXIT_INTERNAL_ERROR;
return -EINVAL;
@@ -699,6 +722,22 @@ int kvmppc_vcpu_run(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu)
kvmppc_load_guest_fp(vcpu);
#endif
+#ifdef CONFIG_ALTIVEC
+ if (cpu_has_feature(CPU_FTR_ALTIVEC)) {
+ /* Save userspace VEC state in stack */
+ enable_kernel_altivec();
+ memcpy(vr, current->thread.vr, sizeof(current->thread.vr));
+ vscr = current->thread.vscr;
+ used_vr = current->thread.used_vr;
+
+ /* Restore guest VEC state to thread */
+ memcpy(current->thread.vr, vcpu->arch.vr, sizeof(vcpu->arch.vr));
+ current->thread.vscr = vcpu->arch.vscr;
+
+ kvmppc_load_guest_altivec(vcpu);
+ }
+#endif
+
ret = __kvmppc_vcpu_run(kvm_run, vcpu);
/* No need for kvm_guest_exit. It's done in handle_exit.
@@ -719,6 +758,23 @@ int kvmppc_vcpu_run(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu)
current->thread.fpexc_mode = fpexc_mode;
#endif
+#ifdef CONFIG_ALTIVEC
+ if (cpu_has_feature(CPU_FTR_ALTIVEC)) {
+ /* Save AltiVec state to thread */
+ if (current->thread.regs->msr & MSR_VEC)
+ giveup_altivec(current);
+
+ /* Save guest state */
+ memcpy(vcpu->arch.vr, current->thread.vr, sizeof(vcpu->arch.vr));
+ vcpu->arch.vscr = current->thread.vscr;
+
+ /* Restore userspace state */
+ memcpy(current->thread.vr, vr, sizeof(current->thread.vr));
+ current->thread.vscr = vscr;
+ current->thread.used_vr = used_vr;
+ }
+#endif
+
out:
vcpu->mode = OUTSIDE_GUEST_MODE;
return ret;
@@ -822,6 +878,19 @@ static void kvmppc_restart_interrupt(struct kvm_vcpu *vcpu,
}
}
+/*
+ * Always returns true is AltiVec unit is present, see
+ * kvmppc_core_check_processor_compat().
+ */
+static inline bool kvmppc_supports_altivec(void)
+{
+#ifdef CONFIG_ALTIVEC
+ if (cpu_has_feature(CPU_FTR_ALTIVEC))
+ return true;
+#endif
+ return false;
+}
+
static inline bool kvmppc_supports_spe(void)
{
#ifdef CONFIG_SPE
@@ -947,7 +1016,7 @@ int kvmppc_handle_exit(struct kvm_run *run, struct kvm_vcpu *vcpu,
*/
bool handled = false;
- if (kvmppc_supports_spe()) {
+ if (kvmppc_supports_altivec() || kvmppc_supports_spe()) {
#ifdef CONFIG_SPE
if (cpu_has_feature(CPU_FTR_SPE))
if (vcpu->arch.shared->msr & MSR_SPE) {
@@ -976,7 +1045,7 @@ int kvmppc_handle_exit(struct kvm_run *run, struct kvm_vcpu *vcpu,
* The interrupt is shared, KVM support for the featured unit
* is detected at run-time.
*/
- if (kvmppc_supports_spe()) {
+ if (kvmppc_supports_altivec() || kvmppc_supports_spe()) {
kvmppc_booke_queue_irqprio(vcpu,
BOOKE_IRQPRIO_SPE_FP_DATA_ALTIVEC_ASSIST);
r = RESUME_GUEST;
@@ -1188,6 +1257,7 @@ int kvmppc_handle_exit(struct kvm_run *run, struct kvm_vcpu *vcpu,
r = (s << 2) | RESUME_HOST | (r & RESUME_FLAG_NV);
} else {
kvmppc_lazy_ee_enable();
+ kvmppc_load_guest_altivec(vcpu);
}
}
diff --git a/arch/powerpc/kvm/e500mc.c b/arch/powerpc/kvm/e500mc.c
index c3bdc0a..9d7f38e 100644
--- a/arch/powerpc/kvm/e500mc.c
+++ b/arch/powerpc/kvm/e500mc.c
@@ -172,8 +172,16 @@ int kvmppc_core_check_processor_compat(void)
r = 0;
else if (strcmp(cur_cpu_spec->cpu_name, "e5500") == 0)
r = 0;
+#ifdef CONFIG_ALTIVEC
+ /*
+ * Since guests have the priviledge to enable AltiVec, we need AltiVec
+ * support in the host to save/restore their context.
+ * Don't use CPU_FTR_ALTIVEC to identify cores with AltiVec unit
+ * because it's cleared in the absence of CONFIG_ALTIVEC!
+ */
else if (strcmp(cur_cpu_spec->cpu_name, "e6500") == 0)
r = 0;
+#endif
else
r = -ENOTSUPP;
--
1.7.4.1
^ permalink raw reply related [flat|nested] 25+ messages in thread* Re: [RFC PATCH 4/6] KVM: PPC: Book3E: Add AltiVec support
2013-06-03 20:54 ` [RFC PATCH 4/6] KVM: PPC: Book3E: Add AltiVec support Mihai Caraman
@ 2013-06-04 22:36 ` Scott Wood
2013-06-05 9:23 ` Caraman Mihai Claudiu-B02008
0 siblings, 1 reply; 25+ messages in thread
From: Scott Wood @ 2013-06-04 22:36 UTC (permalink / raw)
To: Mihai Caraman; +Cc: Mihai Caraman, linuxppc-dev, kvm, kvm-ppc
On 06/03/2013 03:54:26 PM, Mihai Caraman wrote:
> KVM Book3E FPU support gracefully reuse host infrastructure so we do =20
> the
> same for AltiVec. To keep AltiVec lazy call =20
> kvmppc_load_guest_altivec()
> just when returning to guest instead of each sched in.
>=20
> Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
> ---
> arch/powerpc/kvm/booke.c | 74 =20
> +++++++++++++++++++++++++++++++++++++++++++-
> arch/powerpc/kvm/e500mc.c | 8 +++++
> 2 files changed, 80 insertions(+), 2 deletions(-)
>=20
> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> index c08b04b..01eb635 100644
> --- a/arch/powerpc/kvm/booke.c
> +++ b/arch/powerpc/kvm/booke.c
> @@ -134,6 +134,23 @@ static void kvmppc_vcpu_sync_fpu(struct kvm_vcpu =20
> *vcpu)
> }
>=20
> /*
> + * Simulate AltiVec unavailable fault to load guest state
> + * from thread to AltiVec unit.
> + * It requires to be called with preemption disabled.
> + */
> +static inline void kvmppc_load_guest_altivec(struct kvm_vcpu *vcpu)
> +{
> +#ifdef CONFIG_ALTIVEC
> + if (cpu_has_feature(CPU_FTR_ALTIVEC)) {
> + if (!(current->thread.regs->msr & MSR_VEC)) {
> + load_up_altivec(NULL);
> + current->thread.regs->msr |=3D MSR_VEC;
> + }
> + }
> +#endif
Why not use kvmppc_supports_altivec()? In fact, there's nothing =20
KVM-specific about these functions...
> +/*
> + * Always returns true is AltiVec unit is present, see
> + * kvmppc_core_check_processor_compat().
> + */
> +static inline bool kvmppc_supports_altivec(void)
> +{
> +#ifdef CONFIG_ALTIVEC
> + if (cpu_has_feature(CPU_FTR_ALTIVEC))
> + return true;
> +#endif
> + return false;
> +}
Whitespace
> static inline bool kvmppc_supports_spe(void)
> {
> #ifdef CONFIG_SPE
> @@ -947,7 +1016,7 @@ int kvmppc_handle_exit(struct kvm_run *run, =20
> struct kvm_vcpu *vcpu,
> */
> bool handled =3D false;
>=20
> - if (kvmppc_supports_spe()) {
> + if (kvmppc_supports_altivec() || kvmppc_supports_spe()) =20
> {
> #ifdef CONFIG_SPE
> if (cpu_has_feature(CPU_FTR_SPE))
> if (vcpu->arch.shared->msr & MSR_SPE) {
> @@ -976,7 +1045,7 @@ int kvmppc_handle_exit(struct kvm_run *run, =20
> struct kvm_vcpu *vcpu,
> * The interrupt is shared, KVM support for the =20
> featured unit
> * is detected at run-time.
> */
> - if (kvmppc_supports_spe()) {
> + if (kvmppc_supports_altivec() || kvmppc_supports_spe()) =20
> {
> kvmppc_booke_queue_irqprio(vcpu,
> =20
> BOOKE_IRQPRIO_SPE_FP_DATA_ALTIVEC_ASSIST);
> r =3D RESUME_GUEST;
The distinction between how you're handling SPE and Altivec here =20
doesn't really have anything to do with SPE versus Altivec -- it's =20
PR-mode versus HV-mode.
> @@ -1188,6 +1257,7 @@ int kvmppc_handle_exit(struct kvm_run *run, =20
> struct kvm_vcpu *vcpu,
> r =3D (s << 2) | RESUME_HOST | (r & =20
> RESUME_FLAG_NV);
> } else {
> kvmppc_lazy_ee_enable();
> + kvmppc_load_guest_altivec(vcpu);
> }
> }
>=20
Why do you need to call an Altivec function here if we don't need to =20
call an ordinary FPU function here?
-Scott=
^ permalink raw reply [flat|nested] 25+ messages in thread* RE: [RFC PATCH 4/6] KVM: PPC: Book3E: Add AltiVec support
2013-06-04 22:36 ` Scott Wood
@ 2013-06-05 9:23 ` Caraman Mihai Claudiu-B02008
0 siblings, 0 replies; 25+ messages in thread
From: Caraman Mihai Claudiu-B02008 @ 2013-06-05 9:23 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org,
kvm-ppc@vger.kernel.org
> > + * Simulate AltiVec unavailable fault to load guest state
> > + * from thread to AltiVec unit.
> > + * It requires to be called with preemption disabled.
> > + */
> > +static inline void kvmppc_load_guest_altivec(struct kvm_vcpu *vcpu)
> > +{
> > +#ifdef CONFIG_ALTIVEC
> > + if (cpu_has_feature(CPU_FTR_ALTIVEC)) {
> > + if (!(current->thread.regs->msr & MSR_VEC)) {
> > + load_up_altivec(NULL);
> > + current->thread.regs->msr |=3D MSR_VEC;
> > + }
> > + }
> > +#endif
>=20
> Why not use kvmppc_supports_altivec()? In fact, there's nothing
> KVM-specific about these functions...
I will do so, I had this code before kvmppc_supports_altivec() :)
> > static inline bool kvmppc_supports_spe(void)
> > {
> > #ifdef CONFIG_SPE
> > @@ -947,7 +1016,7 @@ int kvmppc_handle_exit(struct kvm_run *run,
> > struct kvm_vcpu *vcpu,
> > */
> > bool handled =3D false;
> >
> > - if (kvmppc_supports_spe()) {
> > + if (kvmppc_supports_altivec() || kvmppc_supports_spe())
> > {
> > #ifdef CONFIG_SPE
> > if (cpu_has_feature(CPU_FTR_SPE))
> > if (vcpu->arch.shared->msr & MSR_SPE) {
>=20
> The distinction between how you're handling SPE and Altivec here
> doesn't really have anything to do with SPE versus Altivec -- it's
> PR-mode versus HV-mode.
I was mislead by MSR_SPE bit, we should rename it as MSR_SPV.
-Mike
^ permalink raw reply [flat|nested] 25+ messages in thread
* [RFC PATCH 5/6] KVM: PPC: Book3E: Add ONE_REG AltiVec support
2013-06-03 20:54 [RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support Mihai Caraman
` (3 preceding siblings ...)
2013-06-03 20:54 ` [RFC PATCH 4/6] KVM: PPC: Book3E: Add AltiVec support Mihai Caraman
@ 2013-06-03 20:54 ` Mihai Caraman
2013-06-04 22:40 ` Scott Wood
2013-06-03 20:54 ` [RFC PATCH 6/6] KVM: PPC: Book3E: Enhance FPU laziness Mihai Caraman
2013-06-04 21:39 ` [RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support Scott Wood
6 siblings, 1 reply; 25+ messages in thread
From: Mihai Caraman @ 2013-06-03 20:54 UTC (permalink / raw)
To: kvm-ppc; +Cc: Mihai Caraman, linuxppc-dev, kvm
Add ONE_REG support for AltiVec on Book3E.
Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
---
arch/powerpc/kvm/booke.c | 32 ++++++++++++++++++++++++++++++++
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 01eb635..019496d 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -1570,6 +1570,22 @@ int kvm_vcpu_ioctl_get_one_reg(struct kvm_vcpu *vcpu, struct kvm_one_reg *reg)
case KVM_REG_PPC_DEBUG_INST:
val = get_reg_val(reg->id, KVMPPC_INST_EHPRIV);
break;
+#ifdef CONFIG_ALTIVEC
+ case KVM_REG_PPC_VR0 ... KVM_REG_PPC_VR31:
+ if (!cpu_has_feature(CPU_FTR_ALTIVEC)) {
+ r = -ENXIO;
+ break;
+ }
+ val.vval = vcpu->arch.vr[reg->id - KVM_REG_PPC_VR0];
+ break;
+ case KVM_REG_PPC_VSCR:
+ if (!cpu_has_feature(CPU_FTR_ALTIVEC)) {
+ r = -ENXIO;
+ break;
+ }
+ val = get_reg_val(reg->id, vcpu->arch.vscr.u[3]);
+ break;
+#endif /* CONFIG_ALTIVEC */
default:
r = kvmppc_get_one_reg(vcpu, reg->id, &val);
break;
@@ -1643,6 +1659,22 @@ int kvm_vcpu_ioctl_set_one_reg(struct kvm_vcpu *vcpu, struct kvm_one_reg *reg)
kvmppc_set_tcr(vcpu, tcr);
break;
}
+#ifdef CONFIG_ALTIVEC
+ case KVM_REG_PPC_VR0 ... KVM_REG_PPC_VR31:
+ if (!cpu_has_feature(CPU_FTR_ALTIVEC)) {
+ r = -ENXIO;
+ break;
+ }
+ vcpu->arch.vr[reg->id - KVM_REG_PPC_VR0] = val.vval;
+ break;
+ case KVM_REG_PPC_VSCR:
+ if (!cpu_has_feature(CPU_FTR_ALTIVEC)) {
+ r = -ENXIO;
+ break;
+ }
+ vcpu->arch.vscr.u[3] = set_reg_val(reg->id, val);
+ break;
+#endif /* CONFIG_ALTIVEC */
default:
r = kvmppc_set_one_reg(vcpu, reg->id, &val);
break;
--
1.7.4.1
^ permalink raw reply related [flat|nested] 25+ messages in thread* Re: [RFC PATCH 5/6] KVM: PPC: Book3E: Add ONE_REG AltiVec support
2013-06-03 20:54 ` [RFC PATCH 5/6] KVM: PPC: Book3E: Add ONE_REG " Mihai Caraman
@ 2013-06-04 22:40 ` Scott Wood
2013-07-03 12:11 ` Caraman Mihai Claudiu-B02008
0 siblings, 1 reply; 25+ messages in thread
From: Scott Wood @ 2013-06-04 22:40 UTC (permalink / raw)
To: Mihai Caraman; +Cc: Mihai Caraman, linuxppc-dev, kvm, kvm-ppc
On 06/03/2013 03:54:27 PM, Mihai Caraman wrote:
> Add ONE_REG support for AltiVec on Book3E.
>=20
> Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
> ---
> arch/powerpc/kvm/booke.c | 32 ++++++++++++++++++++++++++++++++
> 1 files changed, 32 insertions(+), 0 deletions(-)
>=20
> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> index 01eb635..019496d 100644
> --- a/arch/powerpc/kvm/booke.c
> +++ b/arch/powerpc/kvm/booke.c
> @@ -1570,6 +1570,22 @@ int kvm_vcpu_ioctl_get_one_reg(struct kvm_vcpu =20
> *vcpu, struct kvm_one_reg *reg)
> case KVM_REG_PPC_DEBUG_INST:
> val =3D get_reg_val(reg->id, KVMPPC_INST_EHPRIV);
> break;
> +#ifdef CONFIG_ALTIVEC
> + case KVM_REG_PPC_VR0 ... KVM_REG_PPC_VR31:
> + if (!cpu_has_feature(CPU_FTR_ALTIVEC)) {
> + r =3D -ENXIO;
> + break;
> + }
> + val.vval =3D vcpu->arch.vr[reg->id - KVM_REG_PPC_VR0];
> + break;
> + case KVM_REG_PPC_VSCR:
> + if (!cpu_has_feature(CPU_FTR_ALTIVEC)) {
> + r =3D -ENXIO;
> + break;
> + }
> + val =3D get_reg_val(reg->id, vcpu->arch.vscr.u[3]);
> + break;
Why u[3]?
-Scott=
^ permalink raw reply [flat|nested] 25+ messages in thread* RE: [RFC PATCH 5/6] KVM: PPC: Book3E: Add ONE_REG AltiVec support
2013-06-04 22:40 ` Scott Wood
@ 2013-07-03 12:11 ` Caraman Mihai Claudiu-B02008
2013-07-03 18:31 ` Scott Wood
0 siblings, 1 reply; 25+ messages in thread
From: Caraman Mihai Claudiu-B02008 @ 2013-07-03 12:11 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org,
kvm-ppc@vger.kernel.org
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Wednesday, June 05, 2013 1:40 AM
> To: Caraman Mihai Claudiu-B02008
> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
> dev@lists.ozlabs.org; Caraman Mihai Claudiu-B02008
> Subject: Re: [RFC PATCH 5/6] KVM: PPC: Book3E: Add ONE_REG AltiVec
> support
>=20
> On 06/03/2013 03:54:27 PM, Mihai Caraman wrote:
> > Add ONE_REG support for AltiVec on Book3E.
> >
> > Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
> > ---
> > arch/powerpc/kvm/booke.c | 32 ++++++++++++++++++++++++++++++++
> > 1 files changed, 32 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> > index 01eb635..019496d 100644
> > --- a/arch/powerpc/kvm/booke.c
> > +++ b/arch/powerpc/kvm/booke.c
> > @@ -1570,6 +1570,22 @@ int kvm_vcpu_ioctl_get_one_reg(struct kvm_vcpu
> > *vcpu, struct kvm_one_reg *reg)
> > case KVM_REG_PPC_DEBUG_INST:
> > val =3D get_reg_val(reg->id, KVMPPC_INST_EHPRIV);
> > break;
> > +#ifdef CONFIG_ALTIVEC
> > + case KVM_REG_PPC_VR0 ... KVM_REG_PPC_VR31:
> > + if (!cpu_has_feature(CPU_FTR_ALTIVEC)) {
> > + r =3D -ENXIO;
> > + break;
> > + }
> > + val.vval =3D vcpu->arch.vr[reg->id - KVM_REG_PPC_VR0];
> > + break;
> > + case KVM_REG_PPC_VSCR:
> > + if (!cpu_has_feature(CPU_FTR_ALTIVEC)) {
> > + r =3D -ENXIO;
> > + break;
> > + }
> > + val =3D get_reg_val(reg->id, vcpu->arch.vscr.u[3]);
> > + break;
>=20
> Why u[3]?
AltiVec PEM manual says: "The VSCR has two defined bits, the AltiVec non-Ja=
va
mode (NJ) bit (VSCR[15]) and the AltiVec saturation (SAT) bit (VSCR[31]);
the remaining bits are reserved."
I think this is the reason Paul M. exposed KVM_REG_PPC_VSCR width as 32-bit=
.
-Mike
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [RFC PATCH 5/6] KVM: PPC: Book3E: Add ONE_REG AltiVec support
2013-07-03 12:11 ` Caraman Mihai Claudiu-B02008
@ 2013-07-03 18:31 ` Scott Wood
0 siblings, 0 replies; 25+ messages in thread
From: Scott Wood @ 2013-07-03 18:31 UTC (permalink / raw)
To: Caraman Mihai Claudiu-B02008
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
kvm@vger.kernel.org, kvm-ppc@vger.kernel.org
On 07/03/2013 07:11:52 AM, Caraman Mihai Claudiu-B02008 wrote:
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Wednesday, June 05, 2013 1:40 AM
> > To: Caraman Mihai Claudiu-B02008
> > Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
> > dev@lists.ozlabs.org; Caraman Mihai Claudiu-B02008
> > Subject: Re: [RFC PATCH 5/6] KVM: PPC: Book3E: Add ONE_REG AltiVec
> > support
> >
> > On 06/03/2013 03:54:27 PM, Mihai Caraman wrote:
> > > Add ONE_REG support for AltiVec on Book3E.
> > >
> > > Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
> > > ---
> > > arch/powerpc/kvm/booke.c | 32 ++++++++++++++++++++++++++++++++
> > > 1 files changed, 32 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> > > index 01eb635..019496d 100644
> > > --- a/arch/powerpc/kvm/booke.c
> > > +++ b/arch/powerpc/kvm/booke.c
> > > @@ -1570,6 +1570,22 @@ int kvm_vcpu_ioctl_get_one_reg(struct =20
> kvm_vcpu
> > > *vcpu, struct kvm_one_reg *reg)
> > > case KVM_REG_PPC_DEBUG_INST:
> > > val =3D get_reg_val(reg->id, KVMPPC_INST_EHPRIV);
> > > break;
> > > +#ifdef CONFIG_ALTIVEC
> > > + case KVM_REG_PPC_VR0 ... KVM_REG_PPC_VR31:
> > > + if (!cpu_has_feature(CPU_FTR_ALTIVEC)) {
> > > + r =3D -ENXIO;
> > > + break;
> > > + }
> > > + val.vval =3D vcpu->arch.vr[reg->id - KVM_REG_PPC_VR0];
> > > + break;
> > > + case KVM_REG_PPC_VSCR:
> > > + if (!cpu_has_feature(CPU_FTR_ALTIVEC)) {
> > > + r =3D -ENXIO;
> > > + break;
> > > + }
> > > + val =3D get_reg_val(reg->id, vcpu->arch.vscr.u[3]);
> > > + break;
> >
> > Why u[3]?
>=20
> AltiVec PEM manual says: "The VSCR has two defined bits, the AltiVec =20
> non-Java
> mode (NJ) bit (VSCR[15]) and the AltiVec saturation (SAT) bit =20
> (VSCR[31]);
> the remaining bits are reserved."
>=20
> I think this is the reason Paul M. exposed KVM_REG_PPC_VSCR width as =20
> 32-bit.
Ugh. It's documented as a 32-bit register in the ISA, but it can only =20
be accessed via a vector register (seems like an odd design choice, but =20
whatever). And the kernel chose to represent it as a 128-bit vector, =20
while KVM chose to represent it as the register (not the access =20
thereto) is architected. It would have been nice to be consistent... =20
At least put in a comment explaining this.
-Scott=
^ permalink raw reply [flat|nested] 25+ messages in thread
* [RFC PATCH 6/6] KVM: PPC: Book3E: Enhance FPU laziness
2013-06-03 20:54 [RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support Mihai Caraman
` (4 preceding siblings ...)
2013-06-03 20:54 ` [RFC PATCH 5/6] KVM: PPC: Book3E: Add ONE_REG " Mihai Caraman
@ 2013-06-03 20:54 ` Mihai Caraman
2013-06-04 22:53 ` Scott Wood
2013-06-04 21:39 ` [RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support Scott Wood
6 siblings, 1 reply; 25+ messages in thread
From: Mihai Caraman @ 2013-06-03 20:54 UTC (permalink / raw)
To: kvm-ppc; +Cc: Mihai Caraman, linuxppc-dev, kvm
Adopt AltiVec approach to increase laziness by calling kvmppc_load_guest_fp()
just before returning to guest instaed of each sched in.
Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
---
arch/powerpc/kvm/booke.c | 1 +
arch/powerpc/kvm/e500mc.c | 2 --
2 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 019496d..5382238 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -1258,6 +1258,7 @@ int kvmppc_handle_exit(struct kvm_run *run, struct kvm_vcpu *vcpu,
} else {
kvmppc_lazy_ee_enable();
kvmppc_load_guest_altivec(vcpu);
+ kvmppc_load_guest_fp(vcpu);
}
}
diff --git a/arch/powerpc/kvm/e500mc.c b/arch/powerpc/kvm/e500mc.c
index 9d7f38e..29cf97a 100644
--- a/arch/powerpc/kvm/e500mc.c
+++ b/arch/powerpc/kvm/e500mc.c
@@ -138,8 +138,6 @@ void kvmppc_core_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
if (vcpu->arch.oldpir != mfspr(SPRN_PIR))
kvmppc_e500_tlbil_all(vcpu_e500);
-
- kvmppc_load_guest_fp(vcpu);
}
void kvmppc_core_vcpu_put(struct kvm_vcpu *vcpu)
--
1.7.4.1
^ permalink raw reply related [flat|nested] 25+ messages in thread* Re: [RFC PATCH 6/6] KVM: PPC: Book3E: Enhance FPU laziness
2013-06-03 20:54 ` [RFC PATCH 6/6] KVM: PPC: Book3E: Enhance FPU laziness Mihai Caraman
@ 2013-06-04 22:53 ` Scott Wood
2013-06-05 9:14 ` Caraman Mihai Claudiu-B02008
0 siblings, 1 reply; 25+ messages in thread
From: Scott Wood @ 2013-06-04 22:53 UTC (permalink / raw)
To: Mihai Caraman; +Cc: Mihai Caraman, linuxppc-dev, kvm, kvm-ppc
On 06/03/2013 03:54:28 PM, Mihai Caraman wrote:
> Adopt AltiVec approach to increase laziness by calling =20
> kvmppc_load_guest_fp()
> just before returning to guest instaed of each sched in.
>=20
> Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
If you did this *before* adding Altivec it would have saved a question =20
in an earlier patch. :-)
> ---
> arch/powerpc/kvm/booke.c | 1 +
> arch/powerpc/kvm/e500mc.c | 2 --
> 2 files changed, 1 insertions(+), 2 deletions(-)
>=20
> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> index 019496d..5382238 100644
> --- a/arch/powerpc/kvm/booke.c
> +++ b/arch/powerpc/kvm/booke.c
> @@ -1258,6 +1258,7 @@ int kvmppc_handle_exit(struct kvm_run *run, =20
> struct kvm_vcpu *vcpu,
> } else {
> kvmppc_lazy_ee_enable();
> kvmppc_load_guest_altivec(vcpu);
> + kvmppc_load_guest_fp(vcpu);
> }
> }
>=20
You should probably do these before kvmppc_lazy_ee_enable().
Actually, I don't think this is a good idea at all. As I understand =20
it, you're not supposed to take kernel ownersship of floating point in =20
non-atomic context, because an interrupt could itself call =20
enable_kernel_fp().
Do you have benchmarks showing it's even worthwhile?
-Scott=
^ permalink raw reply [flat|nested] 25+ messages in thread* RE: [RFC PATCH 6/6] KVM: PPC: Book3E: Enhance FPU laziness
2013-06-04 22:53 ` Scott Wood
@ 2013-06-05 9:14 ` Caraman Mihai Claudiu-B02008
2013-06-05 20:59 ` Scott Wood
0 siblings, 1 reply; 25+ messages in thread
From: Caraman Mihai Claudiu-B02008 @ 2013-06-05 9:14 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org,
kvm-ppc@vger.kernel.org
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Wednesday, June 05, 2013 1:54 AM
> To: Caraman Mihai Claudiu-B02008
> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
> dev@lists.ozlabs.org; Caraman Mihai Claudiu-B02008
> Subject: Re: [RFC PATCH 6/6] KVM: PPC: Book3E: Enhance FPU laziness
>=20
> On 06/03/2013 03:54:28 PM, Mihai Caraman wrote:
> > Adopt AltiVec approach to increase laziness by calling
> > kvmppc_load_guest_fp()
> > just before returning to guest instaed of each sched in.
> >
> > Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
>=20
> If you did this *before* adding Altivec it would have saved a question
> in an earlier patch. :-)
I kept asking myself about the order and in the end I decided that this is
an improvement originated from AltiVec work. FPU may be further cleaned up
(get rid of active state, etc).=20
>=20
> > ---
> > arch/powerpc/kvm/booke.c | 1 +
> > arch/powerpc/kvm/e500mc.c | 2 --
> > 2 files changed, 1 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> > index 019496d..5382238 100644
> > --- a/arch/powerpc/kvm/booke.c
> > +++ b/arch/powerpc/kvm/booke.c
> > @@ -1258,6 +1258,7 @@ int kvmppc_handle_exit(struct kvm_run *run,
> > struct kvm_vcpu *vcpu,
> > } else {
> > kvmppc_lazy_ee_enable();
> > kvmppc_load_guest_altivec(vcpu);
> > + kvmppc_load_guest_fp(vcpu);
> > }
> > }
> >
>=20
> You should probably do these before kvmppc_lazy_ee_enable().
Why? I wanted to look like part of lightweight_exit.
>=20
> Actually, I don't think this is a good idea at all. As I understand
> it, you're not supposed to take kernel ownersship of floating point in
> non-atomic context, because an interrupt could itself call
> enable_kernel_fp().
So lightweight_exit isn't executed in atomic context?
Will be lazyee fixes including kvmppc_fix_ee_before_entry() in 3.10?
64-bit Book3E KVM is unreliable without them. Should we disable e5500 too
for 3.10?
=20
> Do you have benchmarks showing it's even worthwhile?
No yet but isn't this the whole idea of FPU/AltiVec laziness that the kerne=
l
is struggling to achieve? Without it when returning to host (if another pro=
cess
got unit ownership in handle_exit) we restore and save the unit state for n=
othing.
This multiplies when the ownership goes back and forth between handle_exit =
and other
processes.
Do you have in mid a specific AltiVec benchmark? I have a stress applicatio=
n that do
consecutive vector assignments which proved to be very good at finding stat=
e
corruptions. If I combine this application on the host with a guest that st=
ays longer
on handle_exit (running a tlb or emulation intensive application) I might h=
ave good
data to support my case.
-Mike
>=20
> -Scott
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [RFC PATCH 6/6] KVM: PPC: Book3E: Enhance FPU laziness
2013-06-05 9:14 ` Caraman Mihai Claudiu-B02008
@ 2013-06-05 20:59 ` Scott Wood
0 siblings, 0 replies; 25+ messages in thread
From: Scott Wood @ 2013-06-05 20:59 UTC (permalink / raw)
To: Caraman Mihai Claudiu-B02008
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
kvm@vger.kernel.org, kvm-ppc@vger.kernel.org, Alexander Graf
On 06/05/2013 04:14:21 AM, Caraman Mihai Claudiu-B02008 wrote:
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Wednesday, June 05, 2013 1:54 AM
> > To: Caraman Mihai Claudiu-B02008
> > Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
> > dev@lists.ozlabs.org; Caraman Mihai Claudiu-B02008
> > Subject: Re: [RFC PATCH 6/6] KVM: PPC: Book3E: Enhance FPU laziness
> >
> > On 06/03/2013 03:54:28 PM, Mihai Caraman wrote:
> > > Adopt AltiVec approach to increase laziness by calling
> > > kvmppc_load_guest_fp()
> > > just before returning to guest instaed of each sched in.
> > >
> > > Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
> >
> > If you did this *before* adding Altivec it would have saved a =20
> question
> > in an earlier patch. :-)
>=20
> I kept asking myself about the order and in the end I decided that =20
> this is
> an improvement originated from AltiVec work. FPU may be further =20
> cleaned up
> (get rid of active state, etc).
>=20
> >
> > > ---
> > > arch/powerpc/kvm/booke.c | 1 +
> > > arch/powerpc/kvm/e500mc.c | 2 --
> > > 2 files changed, 1 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> > > index 019496d..5382238 100644
> > > --- a/arch/powerpc/kvm/booke.c
> > > +++ b/arch/powerpc/kvm/booke.c
> > > @@ -1258,6 +1258,7 @@ int kvmppc_handle_exit(struct kvm_run *run,
> > > struct kvm_vcpu *vcpu,
> > > } else {
> > > kvmppc_lazy_ee_enable();
> > > kvmppc_load_guest_altivec(vcpu);
> > > + kvmppc_load_guest_fp(vcpu);
> > > }
> > > }
> > >
> >
> > You should probably do these before kvmppc_lazy_ee_enable().
>=20
> Why? I wanted to look like part of lightweight_exit.
We want to minimize the portion of the code that runs with interrupts =20
disabled while telling tracers that interrupts are enabled. We want to =20
minimize the C code run with lazy EE in an inconsistent state.
The same applies to kvm_vcpu_run()...
> > Actually, I don't think this is a good idea at all. As I understand
> > it, you're not supposed to take kernel ownersship of floating point =20
> in
> > non-atomic context, because an interrupt could itself call
> > enable_kernel_fp().
>=20
> So lightweight_exit isn't executed in atomic context?
Ignore this, I misread what the patch was doing. I thought you were =20
doing the opposite you did. :-P
As such, this patch appears to fix the thing I was complaining about -- =20
before, we could have taken an interrupt after kvmppc_core_vcpu_load(), =20
and that interrupt could have claimed the floating point (unlikely with =20
the kernel as is, but you never know what could happen in the future or =20
out-of-tree...).
> Will be lazyee fixes including kvmppc_fix_ee_before_entry() in 3.10?
> 64-bit Book3E KVM is unreliable without them. Should we disable e5500 =20
> too
> for 3.10?
I hope so... I meant to ask Gleb to take them while Alex was away, but =20
I forgot about them. :-P
Alex, are you back from vacation yet?
-Scott=
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support
2013-06-03 20:54 [RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support Mihai Caraman
` (5 preceding siblings ...)
2013-06-03 20:54 ` [RFC PATCH 6/6] KVM: PPC: Book3E: Enhance FPU laziness Mihai Caraman
@ 2013-06-04 21:39 ` Scott Wood
2013-06-05 7:10 ` Caraman Mihai Claudiu-B02008
6 siblings, 1 reply; 25+ messages in thread
From: Scott Wood @ 2013-06-04 21:39 UTC (permalink / raw)
To: Mihai Caraman; +Cc: linuxppc-dev, kvm, kvm-ppc, Alexander Graf
On 06/03/2013 03:54:22 PM, Mihai Caraman wrote:
> Mihai Caraman (6):
> KVM: PPC: Book3E: Fix AltiVec interrupt numbers and build breakage
> KVM: PPC: Book3E: Refactor SPE_FP exit handling
> KVM: PPC: Book3E: Rename IRQPRIO names to accommodate ALTIVEC
> KVM: PPC: Book3E: Add AltiVec support
> KVM: PPC: Book3E: Add ONE_REG AltiVec support
> KVM: PPC: Book3E: Enhance FPU laziness
>=20
> arch/powerpc/include/asm/kvm_asm.h | 16 ++-
> arch/powerpc/kvm/booke.c | 189 =20
> ++++++++++++++++++++++++++++----
> arch/powerpc/kvm/booke.h | 4 +-
> arch/powerpc/kvm/bookehv_interrupts.S | 8 +-
> arch/powerpc/kvm/e500.c | 10 +-
> arch/powerpc/kvm/e500_emulate.c | 8 +-
> arch/powerpc/kvm/e500mc.c | 10 ++-
> 7 files changed, 199 insertions(+), 46 deletions(-)
This looks like a bit much for 3.10 (certainly, subject lines like =20
"refactor" and "enhance" and "add support" aren't going to make Linus =20
happy given that we're past rc4) so I think we should apply =20
http://patchwork.ozlabs.org/patch/242896/ for 3.10. Then for 3.11, =20
revert it after applying this patchset.
-Scott=
^ permalink raw reply [flat|nested] 25+ messages in thread* RE: [RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support
2013-06-04 21:39 ` [RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support Scott Wood
@ 2013-06-05 7:10 ` Caraman Mihai Claudiu-B02008
2013-06-05 16:35 ` Scott Wood
0 siblings, 1 reply; 25+ messages in thread
From: Caraman Mihai Claudiu-B02008 @ 2013-06-05 7:10 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org,
kvm-ppc@vger.kernel.org, Alexander Graf
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Wednesday, June 05, 2013 12:39 AM
> To: Caraman Mihai Claudiu-B02008
> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
> dev@lists.ozlabs.org; Alexander Graf
> Subject: Re: [RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support
>=20
> On 06/03/2013 03:54:22 PM, Mihai Caraman wrote:
> > Mihai Caraman (6):
> > KVM: PPC: Book3E: Fix AltiVec interrupt numbers and build breakage
> > KVM: PPC: Book3E: Refactor SPE_FP exit handling
> > KVM: PPC: Book3E: Rename IRQPRIO names to accommodate ALTIVEC
> > KVM: PPC: Book3E: Add AltiVec support
> > KVM: PPC: Book3E: Add ONE_REG AltiVec support
> > KVM: PPC: Book3E: Enhance FPU laziness
> >
> > arch/powerpc/include/asm/kvm_asm.h | 16 ++-
> > arch/powerpc/kvm/booke.c | 189
> > ++++++++++++++++++++++++++++----
> > arch/powerpc/kvm/booke.h | 4 +-
> > arch/powerpc/kvm/bookehv_interrupts.S | 8 +-
> > arch/powerpc/kvm/e500.c | 10 +-
> > arch/powerpc/kvm/e500_emulate.c | 8 +-
> > arch/powerpc/kvm/e500mc.c | 10 ++-
> > 7 files changed, 199 insertions(+), 46 deletions(-)
>=20
> This looks like a bit much for 3.10 (certainly, subject lines like
> "refactor" and "enhance" and "add support" aren't going to make Linus
> happy given that we're past rc4) so I think we should apply
> http://patchwork.ozlabs.org/patch/242896/ for 3.10. Then for 3.11,
> revert it after applying this patchset.
>=20
Why not 1/6 plus e6500 removal?
-Mike
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support
2013-06-05 7:10 ` Caraman Mihai Claudiu-B02008
@ 2013-06-05 16:35 ` Scott Wood
2013-06-06 9:42 ` Caraman Mihai Claudiu-B02008
0 siblings, 1 reply; 25+ messages in thread
From: Scott Wood @ 2013-06-05 16:35 UTC (permalink / raw)
To: Caraman Mihai Claudiu-B02008
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
kvm@vger.kernel.org, kvm-ppc@vger.kernel.org, Alexander Graf
On 06/05/2013 02:10:07 AM, Caraman Mihai Claudiu-B02008 wrote:
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Wednesday, June 05, 2013 12:39 AM
> > To: Caraman Mihai Claudiu-B02008
> > Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
> > dev@lists.ozlabs.org; Alexander Graf
> > Subject: Re: [RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support
> >
> > On 06/03/2013 03:54:22 PM, Mihai Caraman wrote:
> > > Mihai Caraman (6):
> > > KVM: PPC: Book3E: Fix AltiVec interrupt numbers and build =20
> breakage
> > > KVM: PPC: Book3E: Refactor SPE_FP exit handling
> > > KVM: PPC: Book3E: Rename IRQPRIO names to accommodate ALTIVEC
> > > KVM: PPC: Book3E: Add AltiVec support
> > > KVM: PPC: Book3E: Add ONE_REG AltiVec support
> > > KVM: PPC: Book3E: Enhance FPU laziness
> > >
> > > arch/powerpc/include/asm/kvm_asm.h | 16 ++-
> > > arch/powerpc/kvm/booke.c | 189
> > > ++++++++++++++++++++++++++++----
> > > arch/powerpc/kvm/booke.h | 4 +-
> > > arch/powerpc/kvm/bookehv_interrupts.S | 8 +-
> > > arch/powerpc/kvm/e500.c | 10 +-
> > > arch/powerpc/kvm/e500_emulate.c | 8 +-
> > > arch/powerpc/kvm/e500mc.c | 10 ++-
> > > 7 files changed, 199 insertions(+), 46 deletions(-)
> >
> > This looks like a bit much for 3.10 (certainly, subject lines like
> > "refactor" and "enhance" and "add support" aren't going to make =20
> Linus
> > happy given that we're past rc4) so I think we should apply
> > http://patchwork.ozlabs.org/patch/242896/ for 3.10. Then for 3.11,
> > revert it after applying this patchset.
> >
>=20
> Why not 1/6 plus e6500 removal?
1/6 is not a bugfix.
-Scott=
^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: [RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support
2013-06-05 16:35 ` Scott Wood
@ 2013-06-06 9:42 ` Caraman Mihai Claudiu-B02008
2013-06-06 19:57 ` Scott Wood
0 siblings, 1 reply; 25+ messages in thread
From: Caraman Mihai Claudiu-B02008 @ 2013-06-06 9:42 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org,
kvm-ppc@vger.kernel.org, Alexander Graf
> > > This looks like a bit much for 3.10 (certainly, subject lines like
> > > "refactor" and "enhance" and "add support" aren't going to make
> > Linus
> > > happy given that we're past rc4) so I think we should apply
> > > http://patchwork.ozlabs.org/patch/242896/ for 3.10. Then for 3.11,
> > > revert it after applying this patchset.
> > >
> >
> > Why not 1/6 plus e6500 removal?
>=20
> 1/6 is not a bugfix.
Not sure I get it. Isn't this a better fix for AltiVec build breakage:
-#define BOOKE_INTERRUPT_ALTIVEC_UNAVAIL 42
-#define BOOKE_INTERRUPT_ALTIVEC_ASSIST 43
+#define BOOKE_INTERRUPT_ALTIVEC_UNAVAIL 32
+#define BOOKE_INTERRUPT_ALTIVEC_ASSIST 33
This removes the need for additional kvm_handlers. Obvious this doesn't mak=
e
AltiVec to work so we still need to disable e6500.
-Mike
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support
2013-06-06 9:42 ` Caraman Mihai Claudiu-B02008
@ 2013-06-06 19:57 ` Scott Wood
0 siblings, 0 replies; 25+ messages in thread
From: Scott Wood @ 2013-06-06 19:57 UTC (permalink / raw)
To: Caraman Mihai Claudiu-B02008
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
kvm@vger.kernel.org, kvm-ppc@vger.kernel.org, Alexander Graf
On 06/06/2013 04:42:44 AM, Caraman Mihai Claudiu-B02008 wrote:
> > > > This looks like a bit much for 3.10 (certainly, subject lines =20
> like
> > > > "refactor" and "enhance" and "add support" aren't going to make
> > > Linus
> > > > happy given that we're past rc4) so I think we should apply
> > > > http://patchwork.ozlabs.org/patch/242896/ for 3.10. Then for =20
> 3.11,
> > > > revert it after applying this patchset.
> > > >
> > >
> > > Why not 1/6 plus e6500 removal?
> >
> > 1/6 is not a bugfix.
>=20
> Not sure I get it. Isn't this a better fix for AltiVec build breakage:
>=20
> -#define BOOKE_INTERRUPT_ALTIVEC_UNAVAIL 42
> -#define BOOKE_INTERRUPT_ALTIVEC_ASSIST 43
> +#define BOOKE_INTERRUPT_ALTIVEC_UNAVAIL 32
> +#define BOOKE_INTERRUPT_ALTIVEC_ASSIST 33
>=20
> This removes the need for additional kvm_handlers. Obvious this =20
> doesn't make
> AltiVec to work so we still need to disable e6500.
OK, didn't realize you meant it as an alternative fix to what was in my =20
patch.
-Scott=
^ permalink raw reply [flat|nested] 25+ messages in thread