[RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support

[RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support

[Mihai Caraman]

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(-)

-- 
1.7.4.1

[RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support

[Mihai Caraman]

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(-)

-- 
1.7.4.1

[RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support

[Mihai Caraman]

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(-)

-- 
1.7.4.1

[RFC PATCH 1/6] KVM: PPC: Book3E: Fix AltiVec interrupt numbers and build breakage

[Mihai Caraman]

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

[RFC PATCH 1/6] KVM: PPC: Book3E: Fix AltiVec interrupt numbers and build breakage

[Mihai Caraman]

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

[RFC PATCH 1/6] KVM: PPC: Book3E: Fix AltiVec interrupt numbers and build breakage

[Mihai Caraman]

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

[RFC PATCH 2/6] KVM: PPC: Book3E: Refactor SPE_FP exit handling

[Mihai Caraman]

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

[RFC PATCH 2/6] KVM: PPC: Book3E: Refactor SPE_FP exit handling

[Mihai Caraman]

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

[RFC PATCH 2/6] KVM: PPC: Book3E: Refactor SPE_FP exit handling

[Mihai Caraman]

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

Re: [RFC PATCH 2/6] KVM: PPC: Book3E: Refactor SPE_FP exit handling

[Scott Wood]

On 06/03/2013 03:54:24 PM, Mihai Caraman wrote:
> 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;
> +}

Whitespace

>  /**
>   * 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.
> +		 */

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().

> +		bool handled = 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,  
> BOOKE_IRQPRIO_SPE_FP_ROUND);
>  		r = RESUME_GUEST;
>  		break;

Why not use kvmppc_supports_spe() here, for consistency?

-Scott

Re: [RFC PATCH 2/6] KVM: PPC: Book3E: Refactor SPE_FP exit handling

[Scott Wood]

On 06/03/2013 03:54:24 PM, Mihai Caraman wrote:
> 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;
> +}

Whitespace

>  /**
>   * 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.
> +		 */

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().

> +		bool handled = 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,  
> BOOKE_IRQPRIO_SPE_FP_ROUND);
>  		r = RESUME_GUEST;
>  		break;

Why not use kvmppc_supports_spe() here, for consistency?

-Scott

Re: [RFC PATCH 2/6] KVM: PPC: Book3E: Refactor SPE_FP exit handling

[Scott Wood]

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=

RE: [RFC PATCH 2/6] KVM: PPC: Book3E: Refactor SPE_FP exit handling

[Caraman Mihai Claudiu-B02008]

> > +		/*
> > +		 * The interrupt is shared, KVM support for the
> > featured unit
> > +		 * is detected at run-time.
> > +		 */
> 
> 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.

> 
> > +		bool handled = 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()?

It makes sense with the next patch. It handles the improbable case of having
CONFIG_ALTIVEC and CONFIG_SPE defined:

	if (kvmppc_supports_altivec() || kvmppc_supports_spe()).

> 
> >  	case BOOKE_INTERRUPT_SPE_FP_ROUND:
> > +#ifdef CONFIG_SPE
> >  		kvmppc_booke_queue_irqprio(vcpu,
> > BOOKE_IRQPRIO_SPE_FP_ROUND);
> >  		r = RESUME_GUEST;
> >  		break;
> 
> 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

RE: [RFC PATCH 2/6] KVM: PPC: Book3E: Refactor SPE_FP exit handling

[Caraman Mihai Claudiu-B02008]

> > +		/*
> > +		 * The interrupt is shared, KVM support for the
> > featured unit
> > +		 * is detected at run-time.
> > +		 */
> 
> 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.

> 
> > +		bool handled = 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()?

It makes sense with the next patch. It handles the improbable case of having
CONFIG_ALTIVEC and CONFIG_SPE defined:

	if (kvmppc_supports_altivec() || kvmppc_supports_spe()).

> 
> >  	case BOOKE_INTERRUPT_SPE_FP_ROUND:
> > +#ifdef CONFIG_SPE
> >  		kvmppc_booke_queue_irqprio(vcpu,
> > BOOKE_IRQPRIO_SPE_FP_ROUND);
> >  		r = RESUME_GUEST;
> >  		break;
> 
> 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

RE: [RFC PATCH 2/6] KVM: PPC: Book3E: Refactor SPE_FP exit handling

[Caraman Mihai Claudiu-B02008]

> > +		/*
> > +		 * 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

Re: [RFC PATCH 2/6] KVM: PPC: Book3E: Refactor SPE_FP exit handling

[Scott Wood]

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 = RESUME_GUEST;
> > >  		break;
> >
> > 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?

I'd rather it be consistent, at least between handling one exception  
and another.

-Scott

Re: [RFC PATCH 2/6] KVM: PPC: Book3E: Refactor SPE_FP exit handling

[Scott Wood]

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 = RESUME_GUEST;
> > >  		break;
> >
> > 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?

I'd rather it be consistent, at least between handling one exception  
and another.

-Scott

Re: [RFC PATCH 2/6] KVM: PPC: Book3E: Refactor SPE_FP exit handling

[Scott Wood]

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=

[RFC PATCH 3/6] KVM: PPC: Book3E: Rename IRQPRIO names to accommodate ALTIVEC

[Mihai Caraman]

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

[RFC PATCH 3/6] KVM: PPC: Book3E: Rename IRQPRIO names to accommodate ALTIVEC

[Mihai Caraman]

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

[RFC PATCH 3/6] KVM: PPC: Book3E: Rename IRQPRIO names to accommodate ALTIVEC

[Mihai Caraman]

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

Re: [RFC PATCH 3/6] KVM: PPC: Book3E: Rename IRQPRIO names to accommodate ALTIVEC

[Scott Wood]

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(-)

Can you remove the TODO separate definitions from 1/6 now?  And/or  
combine 1/6 with this patch?

-Scott

Re: [RFC PATCH 3/6] KVM: PPC: Book3E: Rename IRQPRIO names to accommodate ALTIVEC

[Scott Wood]

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(-)

Can you remove the TODO separate definitions from 1/6 now?  And/or  
combine 1/6 with this patch?

-Scott

Re: [RFC PATCH 3/6] KVM: PPC: Book3E: Rename IRQPRIO names to accommodate ALTIVEC

[Scott Wood]

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=

RE: [RFC PATCH 3/6] KVM: PPC: Book3E: Rename IRQPRIO names to accommodate ALTIVEC

[Caraman Mihai Claudiu-B02008]

> -----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
> 
> 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(-)
> 
> 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 something
similar) instead of adding new kvm_handlers (which legitimates the above commit)
just to remove them later.

-Mike

RE: [RFC PATCH 3/6] KVM: PPC: Book3E: Rename IRQPRIO names to accommodate ALTIVEC

[Caraman Mihai Claudiu-B02008]

> -----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
> 
> 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(-)
> 
> 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 something
similar) instead of adding new kvm_handlers (which legitimates the above commit)
just to remove them later.

-Mike

RE: [RFC PATCH 3/6] KVM: PPC: Book3E: Rename IRQPRIO names to accommodate ALTIVEC

[Caraman Mihai Claudiu-B02008]

> -----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

[RFC PATCH 4/6] KVM: PPC: Book3E: Add AltiVec support

[Mihai Caraman]

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

[RFC PATCH 4/6] KVM: PPC: Book3E: Add AltiVec support

[Mihai Caraman]

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

[RFC PATCH 4/6] KVM: PPC: Book3E: Add AltiVec support

[Mihai Caraman]

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

Re: [RFC PATCH 4/6] KVM: PPC: Book3E: Add AltiVec support

[Scott Wood]

On 06/03/2013 03:54:26 PM, Mihai Caraman wrote:
> 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

Why not use kvmppc_supports_altivec()?  In fact, there's nothing  
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,  
> 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;

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.

> @@ -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);
>  		}
>  	}
> 

Why do you need to call an Altivec function here if we don't need to  
call an ordinary FPU function here?

-Scott

Re: [RFC PATCH 4/6] KVM: PPC: Book3E: Add AltiVec support

[Scott Wood]

On 06/03/2013 03:54:26 PM, Mihai Caraman wrote:
> 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

Why not use kvmppc_supports_altivec()?  In fact, there's nothing  
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,  
> 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;

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.

> @@ -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);
>  		}
>  	}
> 

Why do you need to call an Altivec function here if we don't need to  
call an ordinary FPU function here?

-Scott

Re: [RFC PATCH 4/6] KVM: PPC: Book3E: Add AltiVec support

[Scott Wood]

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=

RE: [RFC PATCH 4/6] KVM: PPC: Book3E: Add AltiVec support

[Caraman Mihai Claudiu-B02008]

> > + * 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
> 
> 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 = 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) {
> 
> 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

RE: [RFC PATCH 4/6] KVM: PPC: Book3E: Add AltiVec support

[Caraman Mihai Claudiu-B02008]

> > + * 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
> 
> 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 = 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) {
> 
> 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

RE: [RFC PATCH 4/6] KVM: PPC: Book3E: Add AltiVec support

[Caraman Mihai Claudiu-B02008]

> > + * 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

[RFC PATCH 5/6] KVM: PPC: Book3E: Add ONE_REG AltiVec support

[Mihai Caraman]

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

[RFC PATCH 5/6] KVM: PPC: Book3E: Add ONE_REG AltiVec support

[Mihai Caraman]

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

[RFC PATCH 5/6] KVM: PPC: Book3E: Add ONE_REG AltiVec support

[Mihai Caraman]

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

Re: [RFC PATCH 5/6] KVM: PPC: Book3E: Add ONE_REG AltiVec support

[Scott Wood]

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 = 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;

Why u[3]?

-Scott

Re: [RFC PATCH 5/6] KVM: PPC: Book3E: Add ONE_REG AltiVec support

[Scott Wood]

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 = 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;

Why u[3]?

-Scott

Re: [RFC PATCH 5/6] KVM: PPC: Book3E: Add ONE_REG AltiVec support

[Scott Wood]

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=

RE: [RFC PATCH 5/6] KVM: PPC: Book3E: Add ONE_REG AltiVec support

[Caraman Mihai Claudiu-B02008]

> -----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 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;
> 
> Why u[3]?

AltiVec PEM manual says: "The VSCR has two defined bits, the AltiVec non-Java
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

RE: [RFC PATCH 5/6] KVM: PPC: Book3E: Add ONE_REG AltiVec support

[Caraman Mihai Claudiu-B02008]

> -----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 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;
> 
> Why u[3]?

AltiVec PEM manual says: "The VSCR has two defined bits, the AltiVec non-Java
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

RE: [RFC PATCH 5/6] KVM: PPC: Book3E: Add ONE_REG AltiVec support

[Caraman Mihai Claudiu-B02008]

> -----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

Re: [RFC PATCH 5/6] KVM: PPC: Book3E: Add ONE_REG AltiVec support

[Scott Wood]

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  
> 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;
> >
> > Why u[3]?
> 
> AltiVec PEM manual says: "The VSCR has two defined bits, the AltiVec  
> non-Java
> 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.

Ugh.  It's documented as a 32-bit register in the ISA, but it can only  
be accessed via a vector register (seems like an odd design choice, but  
whatever).  And the kernel chose to represent it as a 128-bit vector,  
while KVM chose to represent it as the register (not the access  
thereto) is architected.  It would have been nice to be consistent...   
At least put in a comment explaining this.

-Scott

Re: [RFC PATCH 5/6] KVM: PPC: Book3E: Add ONE_REG AltiVec support

[Scott Wood]

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  
> 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;
> >
> > Why u[3]?
> 
> AltiVec PEM manual says: "The VSCR has two defined bits, the AltiVec  
> non-Java
> 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.

Ugh.  It's documented as a 32-bit register in the ISA, but it can only  
be accessed via a vector register (seems like an odd design choice, but  
whatever).  And the kernel chose to represent it as a 128-bit vector,  
while KVM chose to represent it as the register (not the access  
thereto) is architected.  It would have been nice to be consistent...   
At least put in a comment explaining this.

-Scott

Re: [RFC PATCH 5/6] KVM: PPC: Book3E: Add ONE_REG AltiVec support

[Scott Wood]

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=

[RFC PATCH 6/6] KVM: PPC: Book3E: Enhance FPU laziness

[Mihai Caraman]

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

[RFC PATCH 6/6] KVM: PPC: Book3E: Enhance FPU laziness

[Mihai Caraman]

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

[RFC PATCH 6/6] KVM: PPC: Book3E: Enhance FPU laziness

[Mihai Caraman]

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

Re: [RFC PATCH 6/6] KVM: PPC: Book3E: Enhance FPU laziness

[Scott Wood]

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 question  
in an earlier patch. :-)

> ---
>  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().

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().

Do you have benchmarks showing it's even worthwhile?

-Scott

Re: [RFC PATCH 6/6] KVM: PPC: Book3E: Enhance FPU laziness

[Scott Wood]

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 question  
in an earlier patch. :-)

> ---
>  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().

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().

Do you have benchmarks showing it's even worthwhile?

-Scott

Re: [RFC PATCH 6/6] KVM: PPC: Book3E: Enhance FPU laziness

[Scott Wood]

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=

RE: [RFC PATCH 6/6] KVM: PPC: Book3E: Enhance FPU laziness

[Caraman Mihai Claudiu-B02008]

> -----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 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). 

> 
> > ---
> >  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().

Why? I wanted to look like part of lightweight_exit.

> 
> 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?
 
> Do you have benchmarks showing it's even worthwhile?

No yet but isn't this the whole idea of FPU/AltiVec laziness that the kernel
is struggling to achieve? Without it when returning to host (if another process
got unit ownership in handle_exit) we restore and save the unit state for nothing.
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 application that do
consecutive vector assignments which proved to be very good at finding state
corruptions. If I combine this application on the host with a guest that stays longer
on handle_exit (running a tlb or emulation intensive application) I might have good
data to support my case.

-Mike



> 
> -Scott

RE: [RFC PATCH 6/6] KVM: PPC: Book3E: Enhance FPU laziness

[Caraman Mihai Claudiu-B02008]

> -----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 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). 

> 
> > ---
> >  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().

Why? I wanted to look like part of lightweight_exit.

> 
> 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?
 
> Do you have benchmarks showing it's even worthwhile?

No yet but isn't this the whole idea of FPU/AltiVec laziness that the kernel
is struggling to achieve? Without it when returning to host (if another process
got unit ownership in handle_exit) we restore and save the unit state for nothing.
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 application that do
consecutive vector assignments which proved to be very good at finding state
corruptions. If I combine this application on the host with a guest that stays longer
on handle_exit (running a tlb or emulation intensive application) I might have good
data to support my case.

-Mike



> 
> -Scott

RE: [RFC PATCH 6/6] KVM: PPC: Book3E: Enhance FPU laziness

[Caraman Mihai Claudiu-B02008]

> -----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

Re: [RFC PATCH 6/6] KVM: PPC: Book3E: Enhance FPU laziness

[Scott Wood]

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  
> 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).
> 
> >
> > > ---
> > >  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().
> 
> Why? I wanted to look like part of lightweight_exit.

We want to minimize the portion of the code that runs with interrupts  
disabled while telling tracers that interrupts are enabled.  We want to  
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  
> in
> > non-atomic context, because an interrupt could itself call
> > enable_kernel_fp().
> 
> So lightweight_exit isn't executed in atomic context?

Ignore this, I misread what the patch was doing.  I thought you were  
doing the opposite you did. :-P

As such, this patch appears to fix the thing I was complaining about --  
before, we could have taken an interrupt after kvmppc_core_vcpu_load(),  
and that interrupt could have claimed the floating point (unlikely with  
the kernel as is, but you never know what could happen in the future or  
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  
> too
> for 3.10?

I hope so...  I meant to ask Gleb to take them while Alex was away, but  
I forgot about them. :-P

Alex, are you back from vacation yet?

-Scott

Re: [RFC PATCH 6/6] KVM: PPC: Book3E: Enhance FPU laziness

[Scott Wood]

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  
> 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).
> 
> >
> > > ---
> > >  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().
> 
> Why? I wanted to look like part of lightweight_exit.

We want to minimize the portion of the code that runs with interrupts  
disabled while telling tracers that interrupts are enabled.  We want to  
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  
> in
> > non-atomic context, because an interrupt could itself call
> > enable_kernel_fp().
> 
> So lightweight_exit isn't executed in atomic context?

Ignore this, I misread what the patch was doing.  I thought you were  
doing the opposite you did. :-P

As such, this patch appears to fix the thing I was complaining about --  
before, we could have taken an interrupt after kvmppc_core_vcpu_load(),  
and that interrupt could have claimed the floating point (unlikely with  
the kernel as is, but you never know what could happen in the future or  
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  
> too
> for 3.10?

I hope so...  I meant to ask Gleb to take them while Alex was away, but  
I forgot about them. :-P

Alex, are you back from vacation yet?

-Scott

Re: [RFC PATCH 6/6] KVM: PPC: Book3E: Enhance FPU laziness

[Scott Wood]

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=

Re: [RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support

[Scott Wood]

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(-)

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.

-Scott

Re: [RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support

[Scott Wood]

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(-)

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.

-Scott

Re: [RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support

[Scott Wood]

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=

RE: [RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support

[Caraman Mihai Claudiu-B02008]

> -----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 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 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?

-Mike

RE: [RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support

[Caraman Mihai Claudiu-B02008]

> -----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 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 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?

-Mike

RE: [RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support

[Caraman Mihai Claudiu-B02008]

> -----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

Re: [RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support

[Scott Wood]

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  
> 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  
> 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?

1/6 is not a bugfix.

-Scott

Re: [RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support

[Scott Wood]

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  
> 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  
> 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?

1/6 is not a bugfix.

-Scott

Re: [RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support

[Scott Wood]

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=

RE: [RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support

[Caraman Mihai Claudiu-B02008]

> > > 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?
> 
> 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 make
AltiVec to work so we still need to disable e6500.

-Mike

RE: [RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support

[Caraman Mihai Claudiu-B02008]

> > > 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?
> 
> 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 make
AltiVec to work so we still need to disable e6500.

-Mike

RE: [RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support

[Caraman Mihai Claudiu-B02008]

> > > 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

Re: [RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support

[Scott Wood]

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  
> 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?
> >
> > 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 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  
patch.

-Scott

Re: [RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support

[Scott Wood]

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  
> 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?
> >
> > 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 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  
patch.

-Scott

Re: [RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support

[Scott Wood]

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=