[PATCH 00/10] PAPR virtualization on PR KVM

[PATCH 00/10] PAPR virtualization on PR KVM

[Alexander Graf]

In KVM for Book3S PPC we currently have 2 implementations. There
is the PR based implementation which works on any POWER system
you pass in and the super fast HV implementation which requires
libre firmware (so almost nobody can use it).

Currently, the two target two different machine types, with PR KVM
being used for bare metal system virtualization, while the HV KVM
is used to virtualize PAPR.

In an effort to make things more cozy and transparent to the user,
this patch set implements PAPR capabilities to the PR KVM side, so
a user doesn't have to worry what the respective kernel module
supports. Any machine he's virtualizing "just works".


Alex

Alexander Graf (10):
  KVM: PPC: move compute_tlbie_rb to book3s common header
  KVM: PPC: Add papr_enabled flag
  KVM: PPC: Check privilege level on SPRs
  KVM: PPC: Interpret SDR1 as HVA in PAPR mode
  KVM: PPC: Read out syscall instruction on trap
  KVM: PPC: Add support for explicit HIOR setting
  KVM: PPC: Add PAPR hypercall code for PR mode
  KVM: PPC: Stub emulate CFAR and PURR SPRs
  KVM: PPC: Support SC1 hypercalls for PAPR in PR mode
  KVM: PPC: Enable the PAPR CAP for Book3S

 arch/powerpc/include/asm/kvm.h        |    8 ++
 arch/powerpc/include/asm/kvm_book3s.h |   36 ++++++++
 arch/powerpc/include/asm/kvm_host.h   |    1 +
 arch/powerpc/kvm/Makefile             |    1 +
 arch/powerpc/kvm/book3s_64_mmu.c      |    8 ++-
 arch/powerpc/kvm/book3s_emulate.c     |   29 ++++++
 arch/powerpc/kvm/book3s_hv_rm_mmu.c   |   33 -------
 arch/powerpc/kvm/book3s_pr.c          |   36 +++++++-
 arch/powerpc/kvm/book3s_pr_papr.c     |  158 +++++++++++++++++++++++++++++++++
 arch/powerpc/kvm/book3s_segment.S     |    5 +
 arch/powerpc/kvm/powerpc.c            |    6 ++
 include/linux/kvm.h                   |    2 +
 12 files changed, 286 insertions(+), 37 deletions(-)
 create mode 100644 arch/powerpc/kvm/book3s_pr_papr.c

[PATCH 01/10] KVM: PPC: move compute_tlbie_rb to book3s common header

[Alexander Graf]

We need the compute_tlbie_rb in _pr and _hv implementations for papr
soon, so let's move it over to a common header file that both
implementations can leverage.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 arch/powerpc/include/asm/kvm_book3s.h |   33 +++++++++++++++++++++++++++++++++
 arch/powerpc/kvm/book3s_hv_rm_mmu.c   |   33 ---------------------------------
 2 files changed, 33 insertions(+), 33 deletions(-)

diff --git a/arch/powerpc/include/asm/kvm_book3s.h b/arch/powerpc/include/asm/kvm_book3s.h
index 98da010..37dd748 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -382,6 +382,39 @@ static inline bool kvmppc_critical_section(struct kvm_vcpu *vcpu)
 }
 #endif
 
+static inline unsigned long compute_tlbie_rb(unsigned long v, unsigned long r,
+					     unsigned long pte_index)
+{
+	unsigned long rb, va_low;
+
+	rb = (v & ~0x7fUL) << 16;		/* AVA field */
+	va_low = pte_index >> 3;
+	if (v & HPTE_V_SECONDARY)
+		va_low = ~va_low;
+	/* xor vsid from AVA */
+	if (!(v & HPTE_V_1TB_SEG))
+		va_low ^= v >> 12;
+	else
+		va_low ^= v >> 24;
+	va_low &= 0x7ff;
+	if (v & HPTE_V_LARGE) {
+		rb |= 1;			/* L field */
+		if (cpu_has_feature(CPU_FTR_ARCH_206) &&
+		    (r & 0xff000)) {
+			/* non-16MB large page, must be 64k */
+			/* (masks depend on page size) */
+			rb |= 0x1000;		/* page encoding in LP field */
+			rb |= (va_low & 0x7f) << 16; /* 7b of VA in AVA/LP field */
+			rb |= (va_low & 0xfe);	/* AVAL field (P7 doesn't seem to care) */
+		}
+	} else {
+		/* 4kB page */
+		rb |= (va_low & 0x7ff) << 12;	/* remaining 11b of VA */
+	}
+	rb |= (v >> 54) & 0x300;		/* B field */
+	return rb;
+}
+
 /* Magic register values loaded into r3 and r4 before the 'sc' assembly
  * instruction for the OSI hypercalls */
 #define OSI_SC_MAGIC_R3			0x113724FA
diff --git a/arch/powerpc/kvm/book3s_hv_rm_mmu.c b/arch/powerpc/kvm/book3s_hv_rm_mmu.c
index fcfe6b0..bacb0cf 100644
--- a/arch/powerpc/kvm/book3s_hv_rm_mmu.c
+++ b/arch/powerpc/kvm/book3s_hv_rm_mmu.c
@@ -110,39 +110,6 @@ long kvmppc_h_enter(struct kvm_vcpu *vcpu, unsigned long flags,
 	return H_SUCCESS;
 }
 
-static unsigned long compute_tlbie_rb(unsigned long v, unsigned long r,
-				      unsigned long pte_index)
-{
-	unsigned long rb, va_low;
-
-	rb = (v & ~0x7fUL) << 16;		/* AVA field */
-	va_low = pte_index >> 3;
-	if (v & HPTE_V_SECONDARY)
-		va_low = ~va_low;
-	/* xor vsid from AVA */
-	if (!(v & HPTE_V_1TB_SEG))
-		va_low ^= v >> 12;
-	else
-		va_low ^= v >> 24;
-	va_low &= 0x7ff;
-	if (v & HPTE_V_LARGE) {
-		rb |= 1;			/* L field */
-		if (cpu_has_feature(CPU_FTR_ARCH_206) &&
-		    (r & 0xff000)) {
-			/* non-16MB large page, must be 64k */
-			/* (masks depend on page size) */
-			rb |= 0x1000;		/* page encoding in LP field */
-			rb |= (va_low & 0x7f) << 16; /* 7b of VA in AVA/LP field */
-			rb |= (va_low & 0xfe);	/* AVAL field (P7 doesn't seem to care) */
-		}
-	} else {
-		/* 4kB page */
-		rb |= (va_low & 0x7ff) << 12;	/* remaining 11b of VA */
-	}
-	rb |= (v >> 54) & 0x300;		/* B field */
-	return rb;
-}
-
 #define LOCK_TOKEN	(*(u32 *)(&get_paca()->lock_token))
 
 static inline int try_lock_tlbie(unsigned int *lock)
-- 
1.6.0.2

[PATCH] KVM: PPC: move compute_tlbie_rb to book3s_64 common header

[Andreas Schwab]

compute_tlbie_rb is only used on ppc64 and cannot be compiled on ppc32.

Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
---
 arch/powerpc/include/asm/kvm_book3s.h    |   33 ------------------------------
 arch/powerpc/include/asm/kvm_book3s_64.h |   33 ++++++++++++++++++++++++++++++
 2 files changed, 33 insertions(+), 33 deletions(-)

diff --git a/arch/powerpc/include/asm/kvm_book3s.h b/arch/powerpc/include/asm/kvm_book3s.h
index a384ffd..db73fa3 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -383,39 +383,6 @@ static inline bool kvmppc_critical_section(struct kvm_vcpu *vcpu)
 }
 #endif
 
-static inline unsigned long compute_tlbie_rb(unsigned long v, unsigned long r,
-					     unsigned long pte_index)
-{
-	unsigned long rb, va_low;
-
-	rb = (v & ~0x7fUL) << 16;		/* AVA field */
-	va_low = pte_index >> 3;
-	if (v & HPTE_V_SECONDARY)
-		va_low = ~va_low;
-	/* xor vsid from AVA */
-	if (!(v & HPTE_V_1TB_SEG))
-		va_low ^= v >> 12;
-	else
-		va_low ^= v >> 24;
-	va_low &= 0x7ff;
-	if (v & HPTE_V_LARGE) {
-		rb |= 1;			/* L field */
-		if (cpu_has_feature(CPU_FTR_ARCH_206) &&
-		    (r & 0xff000)) {
-			/* non-16MB large page, must be 64k */
-			/* (masks depend on page size) */
-			rb |= 0x1000;		/* page encoding in LP field */
-			rb |= (va_low & 0x7f) << 16; /* 7b of VA in AVA/LP field */
-			rb |= (va_low & 0xfe);	/* AVAL field (P7 doesn't seem to care) */
-		}
-	} else {
-		/* 4kB page */
-		rb |= (va_low & 0x7ff) << 12;	/* remaining 11b of VA */
-	}
-	rb |= (v >> 54) & 0x300;		/* B field */
-	return rb;
-}
-
 /* Magic register values loaded into r3 and r4 before the 'sc' assembly
  * instruction for the OSI hypercalls */
 #define OSI_SC_MAGIC_R3			0x113724FA
diff --git a/arch/powerpc/include/asm/kvm_book3s_64.h b/arch/powerpc/include/asm/kvm_book3s_64.h
index e43fe42..d0ac94f 100644
--- a/arch/powerpc/include/asm/kvm_book3s_64.h
+++ b/arch/powerpc/include/asm/kvm_book3s_64.h
@@ -29,4 +29,37 @@ static inline struct kvmppc_book3s_shadow_vcpu *to_svcpu(struct kvm_vcpu *vcpu)
 
 #define SPAPR_TCE_SHIFT		12
 
+static inline unsigned long compute_tlbie_rb(unsigned long v, unsigned long r,
+					     unsigned long pte_index)
+{
+	unsigned long rb, va_low;
+
+	rb = (v & ~0x7fUL) << 16;		/* AVA field */
+	va_low = pte_index >> 3;
+	if (v & HPTE_V_SECONDARY)
+		va_low = ~va_low;
+	/* xor vsid from AVA */
+	if (!(v & HPTE_V_1TB_SEG))
+		va_low ^= v >> 12;
+	else
+		va_low ^= v >> 24;
+	va_low &= 0x7ff;
+	if (v & HPTE_V_LARGE) {
+		rb |= 1;			/* L field */
+		if (cpu_has_feature(CPU_FTR_ARCH_206) &&
+		    (r & 0xff000)) {
+			/* non-16MB large page, must be 64k */
+			/* (masks depend on page size) */
+			rb |= 0x1000;		/* page encoding in LP field */
+			rb |= (va_low & 0x7f) << 16; /* 7b of VA in AVA/LP field */
+			rb |= (va_low & 0xfe);	/* AVAL field (P7 doesn't seem to care) */
+		}
+	} else {
+		/* 4kB page */
+		rb |= (va_low & 0x7ff) << 12;	/* remaining 11b of VA */
+	}
+	rb |= (v >> 54) & 0x300;		/* B field */
+	return rb;
+}
+
 #endif /* __ASM_KVM_BOOK3S_64_H__ */
-- 
1.7.7.2


-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [PATCH] KVM: PPC: move compute_tlbie_rb to book3s_64 common header

[Alexander Graf]

On 11/08/2011 06:08 PM, Andreas Schwab wrote:
> compute_tlbie_rb is only used on ppc64 and cannot be compiled on ppc32.
>
> Signed-off-by: Andreas Schwab<schwab@linux-m68k.org>

Thanks, applied to kvm-ppc-next.

Alex

[PATCH 02/10] KVM: PPC: Add papr_enabled flag

[Alexander Graf]

When running a PAPR guest, some things change. The privilege level drops
from hypervisor to supervisor, SDR1 gets treated differently and we interpret
hypercalls. For bisectability sake, add the flag now, but only enable it when
all the support code is there.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 arch/powerpc/include/asm/kvm_host.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
index cc22b28..e681302 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -389,6 +389,7 @@ struct kvm_vcpu_arch {
 	u8 dcr_is_write;
 	u8 osi_needed;
 	u8 osi_enabled;
+	u8 papr_enabled;
 	u8 hcall_needed;
 
 	u32 cpr0_cfgaddr; /* holds the last set cpr0_cfgaddr */
-- 
1.6.0.2

[PATCH 03/10] KVM: PPC: Check privilege level on SPRs

[Alexander Graf]

We have 3 privilege levels: problem state, supervisor state and hypervisor
state. Each of them can access different SPRs, so we need to check on every
SPR if it's accessible in the respective mode.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 arch/powerpc/kvm/book3s_emulate.c |   25 +++++++++++++++++++++++++
 1 files changed, 25 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/kvm/book3s_emulate.c b/arch/powerpc/kvm/book3s_emulate.c
index 4668465..bf0ddcd 100644
--- a/arch/powerpc/kvm/book3s_emulate.c
+++ b/arch/powerpc/kvm/book3s_emulate.c
@@ -63,6 +63,25 @@
  * function pointers, so let's just disable the define. */
 #undef mfsrin
 
+enum priv_level {
+	PRIV_PROBLEM = 0,
+	PRIV_SUPER = 1,
+	PRIV_HYPER = 2,
+};
+
+static bool spr_allowed(struct kvm_vcpu *vcpu, enum priv_level level)
+{
+	/* PAPR VMs only access supervisor SPRs */
+	if (vcpu->arch.papr_enabled && (level > PRIV_SUPER))
+		return false;
+
+	/* Limit user space to its own small SPR set */
+	if ((vcpu->arch.shared->msr & MSR_PR) && level > PRIV_PROBLEM)
+		return false;
+
+	return true;
+}
+
 int kvmppc_core_emulate_op(struct kvm_run *run, struct kvm_vcpu *vcpu,
                            unsigned int inst, int *advance)
 {
@@ -296,6 +315,8 @@ int kvmppc_core_emulate_mtspr(struct kvm_vcpu *vcpu, int sprn, int rs)
 
 	switch (sprn) {
 	case SPRN_SDR1:
+		if (!spr_allowed(vcpu, PRIV_HYPER))
+			goto unprivileged;
 		to_book3s(vcpu)->sdr1 = spr_val;
 		break;
 	case SPRN_DSISR:
@@ -390,6 +411,7 @@ int kvmppc_core_emulate_mtspr(struct kvm_vcpu *vcpu, int sprn, int rs)
 	case SPRN_PMC4_GEKKO:
 	case SPRN_WPAR_GEKKO:
 		break;
+unprivileged:
 	default:
 		printk(KERN_INFO "KVM: invalid SPR write: %d\n", sprn);
 #ifndef DEBUG_SPR
@@ -421,6 +443,8 @@ int kvmppc_core_emulate_mfspr(struct kvm_vcpu *vcpu, int sprn, int rt)
 		break;
 	}
 	case SPRN_SDR1:
+		if (!spr_allowed(vcpu, PRIV_HYPER))
+			goto unprivileged;
 		kvmppc_set_gpr(vcpu, rt, to_book3s(vcpu)->sdr1);
 		break;
 	case SPRN_DSISR:
@@ -476,6 +500,7 @@ int kvmppc_core_emulate_mfspr(struct kvm_vcpu *vcpu, int sprn, int rt)
 		kvmppc_set_gpr(vcpu, rt, 0);
 		break;
 	default:
+unprivileged:
 		printk(KERN_INFO "KVM: invalid SPR read: %d\n", sprn);
 #ifndef DEBUG_SPR
 		emulated = EMULATE_FAIL;
-- 
1.6.0.2

[PATCH 04/10] KVM: PPC: Interpret SDR1 as HVA in PAPR mode

[Alexander Graf]

When running a PAPR guest, the guest is not allowed to set SDR1 - instead
the HTAB information is held in internal hypervisor structures. But all of
our current code relies on SDR1 and walking the HTAB like on real hardware.

So in order to not be too intrusive, we simply set SDR1 to the HTAB we hold
in host memory. That way we can keep the HTAB in user space, but use it from
kernel space to map the guest.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 arch/powerpc/kvm/book3s_64_mmu.c |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/kvm/book3s_64_mmu.c b/arch/powerpc/kvm/book3s_64_mmu.c
index c6d3e19..b871721 100644
--- a/arch/powerpc/kvm/book3s_64_mmu.c
+++ b/arch/powerpc/kvm/book3s_64_mmu.c
@@ -128,7 +128,13 @@ static hva_t kvmppc_mmu_book3s_64_get_pteg(
 	dprintk("MMU: page=0x%x sdr1=0x%llx pteg=0x%llx vsid=0x%llx\n",
 		page, vcpu_book3s->sdr1, pteg, slbe->vsid);
 
-	r = gfn_to_hva(vcpu_book3s->vcpu.kvm, pteg >> PAGE_SHIFT);
+	/* When running a PAPR guest, SDR1 contains a HVA address instead
+           of a GPA */
+	if (vcpu_book3s->vcpu.arch.papr_enabled)
+		r = pteg;
+	else
+		r = gfn_to_hva(vcpu_book3s->vcpu.kvm, pteg >> PAGE_SHIFT);
+
 	if (kvm_is_error_hva(r))
 		return r;
 	return r | (pteg & ~PAGE_MASK);
-- 
1.6.0.2

[PATCH 05/10] KVM: PPC: Read out syscall instruction on trap

[Alexander Graf]

We have a few traps where we cache the instruction that cause the trap
for analysis later on. Since we now need to be able to distinguish
between SC 0 and SC 1 system calls and the only way to find out which
is which is by looking at the instruction, we also read out the instruction
causing the system call.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 arch/powerpc/kvm/book3s_segment.S |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/kvm/book3s_segment.S b/arch/powerpc/kvm/book3s_segment.S
index aed32e5..678b6be 100644
--- a/arch/powerpc/kvm/book3s_segment.S
+++ b/arch/powerpc/kvm/book3s_segment.S
@@ -213,11 +213,16 @@ END_FTR_SECTION_IFSET(CPU_FTR_HVMODE)
 	beq	ld_last_inst
 	cmpwi	r12, BOOK3S_INTERRUPT_PROGRAM
 	beq	ld_last_inst
+	cmpwi	r12, BOOK3S_INTERRUPT_SYSCALL
+	beq	ld_last_prev_inst
 	cmpwi	r12, BOOK3S_INTERRUPT_ALIGNMENT
 	beq-	ld_last_inst
 
 	b	no_ld_last_inst
 
+ld_last_prev_inst:
+	addi	r3, r3, -4
+
 ld_last_inst:
 	/* Save off the guest instruction we're at */
 
-- 
1.6.0.2

[PATCH 06/10] KVM: PPC: Add support for explicit HIOR setting

[Alexander Graf]

Until now, we always set HIOR based on the PVR, but this is just wrong.
Instead, we should be setting HIOR explicitly, so user space can decide
what the initial HIOR value is - just like on real hardware.

We keep the old PVR based way around for backwards compatibility, but
once user space uses the SREGS based method, we drop the PVR logic.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 arch/powerpc/include/asm/kvm.h        |    8 ++++++++
 arch/powerpc/include/asm/kvm_book3s.h |    2 ++
 arch/powerpc/kvm/book3s_pr.c          |   14 ++++++++++++--
 arch/powerpc/kvm/powerpc.c            |    1 +
 include/linux/kvm.h                   |    1 +
 5 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/kvm.h b/arch/powerpc/include/asm/kvm.h
index a4f6c85..a6a253e 100644
--- a/arch/powerpc/include/asm/kvm.h
+++ b/arch/powerpc/include/asm/kvm.h
@@ -149,6 +149,12 @@ struct kvm_regs {
 #define KVM_SREGS_E_UPDATE_DBSR		(1 << 3)
 
 /*
+ * Book3S special bits to indicate contents in the struct by maintaining
+ * backwards compatibility with older structs. If adding a new field,
+ * please make sure to add a flag for that new field */
+#define KVM_SREGS_S_HIOR		(1 << 0)
+
+/*
  * In KVM_SET_SREGS, reserved/pad fields must be left untouched from a
  * previous KVM_GET_REGS.
  *
@@ -173,6 +179,8 @@ struct kvm_sregs {
 				__u64 ibat[8]; 
 				__u64 dbat[8]; 
 			} ppc32;
+			__u64 flags; /* KVM_SREGS_S_ */
+			__u64 hior;
 		} s;
 		struct {
 			union {
diff --git a/arch/powerpc/include/asm/kvm_book3s.h b/arch/powerpc/include/asm/kvm_book3s.h
index 37dd748..472437b 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -90,6 +90,8 @@ struct kvmppc_vcpu_book3s {
 #endif
 	int context_id[SID_CONTEXTS];
 
+	bool hior_sregs;		/* HIOR is set by SREGS, not PVR */
+
 	struct hlist_head hpte_hash_pte[HPTEG_HASH_NUM_PTE];
 	struct hlist_head hpte_hash_pte_long[HPTEG_HASH_NUM_PTE_LONG];
 	struct hlist_head hpte_hash_vpte[HPTEG_HASH_NUM_VPTE];
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index 0c0d3f2..78dcf65 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -150,13 +150,15 @@ void kvmppc_set_pvr(struct kvm_vcpu *vcpu, u32 pvr)
 #ifdef CONFIG_PPC_BOOK3S_64
 	if ((pvr >= 0x330000) && (pvr < 0x70330000)) {
 		kvmppc_mmu_book3s_64_init(vcpu);
-		to_book3s(vcpu)->hior = 0xfff00000;
+		if (!to_book3s(vcpu)->hior_sregs)
+			to_book3s(vcpu)->hior = 0xfff00000;
 		to_book3s(vcpu)->msr_mask = 0xffffffffffffffffULL;
 	} else
 #endif
 	{
 		kvmppc_mmu_book3s_32_init(vcpu);
-		to_book3s(vcpu)->hior = 0;
+		if (!to_book3s(vcpu)->hior_sregs)
+			to_book3s(vcpu)->hior = 0;
 		to_book3s(vcpu)->msr_mask = 0xffffffffULL;
 	}
 
@@ -770,6 +772,9 @@ int kvm_arch_vcpu_ioctl_get_sregs(struct kvm_vcpu *vcpu,
 		}
 	}
 
+	if (sregs->u.s.flags & KVM_SREGS_S_HIOR)
+		sregs->u.s.hior = to_book3s(vcpu)->hior;
+
 	return 0;
 }
 
@@ -806,6 +811,11 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
 	/* Flush the MMU after messing with the segments */
 	kvmppc_mmu_pte_flush(vcpu, 0, 0);
 
+	if (sregs->u.s.flags & KVM_SREGS_S_HIOR) {
+		to_book3s(vcpu)->hior_sregs = true;
+		to_book3s(vcpu)->hior = sregs->u.s.hior;
+	}
+
 	return 0;
 }
 
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index a107c9b..17a5c83 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -188,6 +188,7 @@ int kvm_dev_ioctl_check_extension(long ext)
 	case KVM_CAP_PPC_BOOKE_SREGS:
 #else
 	case KVM_CAP_PPC_SEGSTATE:
+	case KVM_CAP_PPC_HIOR:
 #endif
 	case KVM_CAP_PPC_UNSET_IRQ:
 	case KVM_CAP_PPC_IRQ_LEVEL:
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index 55f5afb..4d33f78 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -554,6 +554,7 @@ struct kvm_ppc_pvinfo {
 #define KVM_CAP_PPC_SMT 64
 #define KVM_CAP_PPC_RMA	65
 #define KVM_CAP_MAX_VCPUS 66       /* returns max vcpus per vm */
+#define KVM_CAP_PPC_HIOR 67
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
-- 
1.6.0.2

[PATCH 07/10] KVM: PPC: Add PAPR hypercall code for PR mode

[Alexander Graf]

When running a PAPR guest, we need to handle a few hypercalls in kernel space,
most prominently the page table invalidation (to sync the shadows).

So this patch adds handling for a few PAPR hypercalls to PR mode KVM. I tried
to share the code with HV mode, but it ended up being a lot easier this way
around, as the two differ too much in those details.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 arch/powerpc/include/asm/kvm_book3s.h |    1 +
 arch/powerpc/kvm/Makefile             |    1 +
 arch/powerpc/kvm/book3s_pr_papr.c     |  158 +++++++++++++++++++++++++++++++++
 3 files changed, 160 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/kvm/book3s_pr_papr.c

diff --git a/arch/powerpc/include/asm/kvm_book3s.h b/arch/powerpc/include/asm/kvm_book3s.h
index 472437b..91d41fa 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -150,6 +150,7 @@ extern void kvmppc_load_up_altivec(void);
 extern void kvmppc_load_up_vsx(void);
 extern u32 kvmppc_alignment_dsisr(struct kvm_vcpu *vcpu, unsigned int inst);
 extern ulong kvmppc_alignment_dar(struct kvm_vcpu *vcpu, unsigned int inst);
+extern int kvmppc_h_pr(struct kvm_vcpu *vcpu, unsigned long cmd);
 
 static inline struct kvmppc_vcpu_book3s *to_book3s(struct kvm_vcpu *vcpu)
 {
diff --git a/arch/powerpc/kvm/Makefile b/arch/powerpc/kvm/Makefile
index 08428e2..4c66d51 100644
--- a/arch/powerpc/kvm/Makefile
+++ b/arch/powerpc/kvm/Makefile
@@ -43,6 +43,7 @@ kvm-book3s_64-objs-$(CONFIG_KVM_BOOK3S_64_PR) := \
 	fpu.o \
 	book3s_paired_singles.o \
 	book3s_pr.o \
+	book3s_pr_papr.o \
 	book3s_emulate.o \
 	book3s_interrupts.o \
 	book3s_mmu_hpte.o \
diff --git a/arch/powerpc/kvm/book3s_pr_papr.c b/arch/powerpc/kvm/book3s_pr_papr.c
new file mode 100644
index 0000000..b8ec55f
--- /dev/null
+++ b/arch/powerpc/kvm/book3s_pr_papr.c
@@ -0,0 +1,158 @@
+/*
+ * Copyright (C) 2011. Freescale Inc. All rights reserved.
+ *
+ * Authors:
+ *    Alexander Graf <agraf@suse.de>
+ *    Paul Mackerras <paulus@samba.org>
+ *
+ * Description:
+ *
+ * Hypercall handling for running PAPR guests in PR KVM on Book 3S
+ * processors.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ */
+
+#include <asm/uaccess.h>
+#include <asm/kvm_ppc.h>
+#include <asm/kvm_book3s.h>
+
+static unsigned long get_pteg_addr(struct kvm_vcpu *vcpu, long pte_index)
+{
+	struct kvmppc_vcpu_book3s *vcpu_book3s = to_book3s(vcpu);
+	unsigned long pteg_addr;
+
+	pte_index <<= 4;
+	pte_index &= ((1 << ((vcpu_book3s->sdr1 & 0x1f) + 11)) - 1) << 7 | 0x70;
+        pteg_addr = vcpu_book3s->sdr1 & 0xfffffffffffc0000ULL;
+	pteg_addr |= pte_index;
+
+	return pteg_addr;
+}
+
+static int kvmppc_h_pr_enter(struct kvm_vcpu *vcpu)
+{
+	long flags = kvmppc_get_gpr(vcpu, 4);
+	long pte_index = kvmppc_get_gpr(vcpu, 5);
+	unsigned long pteg[2 * 8];
+	unsigned long pteg_addr, i, *hpte;
+
+	pte_index &= ~7UL;
+	pteg_addr = get_pteg_addr(vcpu, pte_index);
+
+	copy_from_user(pteg, (void __user *)pteg_addr, sizeof(pteg));
+	hpte = pteg;
+
+	if (likely((flags & H_EXACT) == 0)) {
+		pte_index &= ~7UL;
+		for (i = 0; ; ++i) {
+			if (i == 8)
+				return H_PTEG_FULL;
+			if ((*hpte & HPTE_V_VALID) == 0)
+				break;
+			hpte += 2;
+		}
+	} else {
+		i = kvmppc_get_gpr(vcpu, 5) & 7UL;
+		hpte += i * 2;
+	}
+
+	hpte[0] = kvmppc_get_gpr(vcpu, 6);
+	hpte[1] = kvmppc_get_gpr(vcpu, 7);
+	copy_to_user((void __user *)pteg_addr, pteg, sizeof(pteg));
+	kvmppc_set_gpr(vcpu, 3, H_SUCCESS);
+	kvmppc_set_gpr(vcpu, 4, pte_index | i);
+
+	return EMULATE_DONE;
+}
+
+static int kvmppc_h_pr_remove(struct kvm_vcpu *vcpu)
+{
+	unsigned long flags= kvmppc_get_gpr(vcpu, 4);
+	unsigned long pte_index = kvmppc_get_gpr(vcpu, 5);
+	unsigned long avpn = kvmppc_get_gpr(vcpu, 6);
+	unsigned long v = 0, pteg, rb;
+	unsigned long pte[2];
+
+	pteg = get_pteg_addr(vcpu, pte_index);
+	copy_from_user(pte, (void __user *)pteg, sizeof(pte));
+
+	if ((pte[0] & HPTE_V_VALID) == 0 ||
+	    ((flags & H_AVPN) && (pte[0] & ~0x7fUL) != avpn) ||
+	    ((flags & H_ANDCOND) && (pte[0] & avpn) != 0)) {
+		kvmppc_set_gpr(vcpu, 3, H_NOT_FOUND);
+		return EMULATE_DONE;
+	}
+
+	copy_to_user((void __user *)pteg, &v, sizeof(v));
+
+	rb = compute_tlbie_rb(pte[0], pte[1], pte_index);
+	vcpu->arch.mmu.tlbie(vcpu, rb, rb & 1 ? true : false);
+
+	kvmppc_set_gpr(vcpu, 3, H_SUCCESS);
+	kvmppc_set_gpr(vcpu, 4, pte[0]);
+	kvmppc_set_gpr(vcpu, 5, pte[1]);
+
+	return EMULATE_DONE;
+}
+
+static int kvmppc_h_pr_protect(struct kvm_vcpu *vcpu)
+{
+	unsigned long flags = kvmppc_get_gpr(vcpu, 4);
+	unsigned long pte_index = kvmppc_get_gpr(vcpu, 5);
+	unsigned long avpn = kvmppc_get_gpr(vcpu, 6);
+	unsigned long rb, pteg, r, v;
+	unsigned long pte[2];
+
+	pteg = get_pteg_addr(vcpu, pte_index);
+	copy_from_user(pte, (void __user *)pteg, sizeof(pte));
+
+	if ((pte[0] & HPTE_V_VALID) == 0 ||
+	    ((flags & H_AVPN) && (pte[0] & ~0x7fUL) != avpn)) {
+		kvmppc_set_gpr(vcpu, 3, H_NOT_FOUND);
+		return EMULATE_DONE;
+	}
+
+	v = pte[0];
+	r = pte[1];
+	r &= ~(HPTE_R_PP0 | HPTE_R_PP | HPTE_R_N | HPTE_R_KEY_HI |
+	       HPTE_R_KEY_LO);
+	r |= (flags << 55) & HPTE_R_PP0;
+	r |= (flags << 48) & HPTE_R_KEY_HI;
+	r |= flags & (HPTE_R_PP | HPTE_R_N | HPTE_R_KEY_LO);
+
+	pte[1] = r;
+
+	rb = compute_tlbie_rb(v, r, pte_index);
+	vcpu->arch.mmu.tlbie(vcpu, rb, rb & 1 ? true : false);
+	copy_to_user((void __user *)pteg, pte, sizeof(pte));
+
+	kvmppc_set_gpr(vcpu, 3, H_SUCCESS);
+
+	return EMULATE_DONE;
+}
+
+int kvmppc_h_pr(struct kvm_vcpu *vcpu, unsigned long cmd)
+{
+	switch (cmd) {
+	case H_ENTER:
+		return kvmppc_h_pr_enter(vcpu);
+	case H_REMOVE:
+		return kvmppc_h_pr_remove(vcpu);
+	case H_PROTECT:
+		return kvmppc_h_pr_protect(vcpu);
+	case H_BULK_REMOVE:
+		/* We just flush all PTEs, so user space can
+		   handle the HPT modifications */
+		kvmppc_mmu_pte_flush(vcpu, 0, 0);
+		break;
+	case H_CEDE:
+		kvm_vcpu_block(vcpu);
+		vcpu->stat.halt_wakeup++;
+		return EMULATE_DONE;
+	}
+
+	return EMULATE_FAIL;
+}
-- 
1.6.0.2

Re: [PATCH 07/10] KVM: PPC: Add PAPR hypercall code for PR mode

[Avi Kivity]

On 08/09/2011 07:31 PM, Alexander Graf wrote:
> When running a PAPR guest, we need to handle a few hypercalls in kernel space,
> most prominently the page table invalidation (to sync the shadows).
>
> So this patch adds handling for a few PAPR hypercalls to PR mode KVM. I tried
> to share the code with HV mode, but it ended up being a lot easier this way
> around, as the two differ too much in those details.
>
>
> +++ b/arch/powerpc/kvm/book3s_pr_papr.c
> @@ -0,0 +1,158 @@
> +/*
> + * Copyright (C) 2011. Freescale Inc. All rights reserved.
> + *
> + * Authors:
> + *    Alexander Graf<agraf@suse.de>
> + *    Paul Mackerras<paulus@samba.org>
> + *
> + * Description:
> + *
> + * Hypercall handling for running PAPR guests in PR KVM on Book 3S
> + * processors.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License, version 2, as
> + * published by the Free Software Foundation.
> + */

Copyright freescale, authors Paul and yourself?

> +
> +static unsigned long get_pteg_addr(struct kvm_vcpu *vcpu, long pte_index)
> +{
> +	struct kvmppc_vcpu_book3s *vcpu_book3s = to_book3s(vcpu);
> +	unsigned long pteg_addr;
> +
> +	pte_index<<= 4;
> +	pte_index&= ((1<<  ((vcpu_book3s->sdr1&  0x1f) + 11)) - 1)<<  7 | 0x70;
> +        pteg_addr = vcpu_book3s->sdr1&  0xfffffffffffc0000ULL;
> +	pteg_addr |= pte_index;
> +
> +	return pteg_addr;
> +}

Evil space crept in.


-- 
error compiling committee.c: too many arguments to function

Re: [PATCH 07/10] KVM: PPC: Add PAPR hypercall code for PR mode

[Alexander Graf]

On 08/09/2011 06:40 PM, Avi Kivity wrote:
> On 08/09/2011 07:31 PM, Alexander Graf wrote:
>> When running a PAPR guest, we need to handle a few hypercalls in 
>> kernel space,
>> most prominently the page table invalidation (to sync the shadows).
>>
>> So this patch adds handling for a few PAPR hypercalls to PR mode KVM. 
>> I tried
>> to share the code with HV mode, but it ended up being a lot easier 
>> this way
>> around, as the two differ too much in those details.
>>
>>
>> +++ b/arch/powerpc/kvm/book3s_pr_papr.c
>> @@ -0,0 +1,158 @@
>> +/*
>> + * Copyright (C) 2011. Freescale Inc. All rights reserved.
>> + *
>> + * Authors:
>> + *    Alexander Graf<agraf@suse.de>
>> + *    Paul Mackerras<paulus@samba.org>
>> + *
>> + * Description:
>> + *
>> + * Hypercall handling for running PAPR guests in PR KVM on Book 3S
>> + * processors.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License, version 2, as
>> + * published by the Free Software Foundation.
>> + */
>
> Copyright freescale, authors Paul and yourself?

Yeah, I'm reasonably clueless when it comes to legal stuff. This code is 
inspired by Paul's, but is mostly rewritten since it's so tied into the 
virtual MMU. What would the copyright be in that case?

>
>> +
>> +static unsigned long get_pteg_addr(struct kvm_vcpu *vcpu, long 
>> pte_index)
>> +{
>> +    struct kvmppc_vcpu_book3s *vcpu_book3s = to_book3s(vcpu);
>> +    unsigned long pteg_addr;
>> +
>> +    pte_index<<= 4;
>> +    pte_index&= ((1<<  ((vcpu_book3s->sdr1&  0x1f) + 11)) - 1)<<  7 
>> | 0x70;
>> +        pteg_addr = vcpu_book3s->sdr1&  0xfffffffffffc0000ULL;
>> +    pteg_addr |= pte_index;
>> +
>> +    return pteg_addr;
>> +}
>
> Evil space crept in.


Oh noez! Fixed it :)


Alex

Re: [PATCH 07/10] KVM: PPC: Add PAPR hypercall code for PR mode

[Avi Kivity]

On 08/09/2011 07:46 PM, Alexander Graf wrote:
> On 08/09/2011 06:40 PM, Avi Kivity wrote:
>> On 08/09/2011 07:31 PM, Alexander Graf wrote:
>>> When running a PAPR guest, we need to handle a few hypercalls in 
>>> kernel space,
>>> most prominently the page table invalidation (to sync the shadows).
>>>
>>> So this patch adds handling for a few PAPR hypercalls to PR mode 
>>> KVM. I tried
>>> to share the code with HV mode, but it ended up being a lot easier 
>>> this way
>>> around, as the two differ too much in those details.
>>>
>>>
>>> +++ b/arch/powerpc/kvm/book3s_pr_papr.c
>>> @@ -0,0 +1,158 @@
>>> +/*
>>> + * Copyright (C) 2011. Freescale Inc. All rights reserved.
>>> + *
>>> + * Authors:
>>> + *    Alexander Graf<agraf@suse.de>
>>> + *    Paul Mackerras<paulus@samba.org>
>>> + *
>>> + * Description:
>>> + *
>>> + * Hypercall handling for running PAPR guests in PR KVM on Book 3S
>>> + * processors.
>>> + *
>>> + * This program is free software; you can redistribute it and/or 
>>> modify
>>> + * it under the terms of the GNU General Public License, version 2, as
>>> + * published by the Free Software Foundation.
>>> + */
>>
>> Copyright freescale, authors Paul and yourself?
>
> Yeah, I'm reasonably clueless when it comes to legal stuff. This code 
> is inspired by Paul's, but is mostly rewritten since it's so tied into 
> the virtual MMU. What would the copyright be in that case?

Just put your own (or your employers').  If someone contributed to the 
code they can add their copyrights (or ask you do do it before inclusion).

It would be good to get Paul's or Ben's so that the unimportant 
characters between the whitespace get some braintime.

-- 
error compiling committee.c: too many arguments to function

Re: [PATCH 07/10] KVM: PPC: Add PAPR hypercall code for PR mode

[Alexander Graf]

On 08/09/2011 06:49 PM, Avi Kivity wrote:
> On 08/09/2011 07:46 PM, Alexander Graf wrote:
>> On 08/09/2011 06:40 PM, Avi Kivity wrote:
>>> On 08/09/2011 07:31 PM, Alexander Graf wrote:
>>>> When running a PAPR guest, we need to handle a few hypercalls in 
>>>> kernel space,
>>>> most prominently the page table invalidation (to sync the shadows).
>>>>
>>>> So this patch adds handling for a few PAPR hypercalls to PR mode 
>>>> KVM. I tried
>>>> to share the code with HV mode, but it ended up being a lot easier 
>>>> this way
>>>> around, as the two differ too much in those details.
>>>>
>>>>
>>>> +++ b/arch/powerpc/kvm/book3s_pr_papr.c
>>>> @@ -0,0 +1,158 @@
>>>> +/*
>>>> + * Copyright (C) 2011. Freescale Inc. All rights reserved.
>>>> + *
>>>> + * Authors:
>>>> + *    Alexander Graf<agraf@suse.de>
>>>> + *    Paul Mackerras<paulus@samba.org>
>>>> + *
>>>> + * Description:
>>>> + *
>>>> + * Hypercall handling for running PAPR guests in PR KVM on Book 3S
>>>> + * processors.
>>>> + *
>>>> + * This program is free software; you can redistribute it and/or 
>>>> modify
>>>> + * it under the terms of the GNU General Public License, version 
>>>> 2, as
>>>> + * published by the Free Software Foundation.
>>>> + */
>>>
>>> Copyright freescale, authors Paul and yourself?
>>
>> Yeah, I'm reasonably clueless when it comes to legal stuff. This code 
>> is inspired by Paul's, but is mostly rewritten since it's so tied 
>> into the virtual MMU. What would the copyright be in that case?
>
> Just put your own (or your employers').  If someone contributed to the 
> code they can add their copyrights (or ask you do do it before 
> inclusion).
>
> It would be good to get Paul's or Ben's so that the unimportant 
> characters between the whitespace get some braintime.

So you mean I just put both copyright statements there? That's a nice idea!


Alex

Re: [PATCH 07/10] KVM: PPC: Add PAPR hypercall code for PR mode

[Avi Kivity]

On 08/09/2011 07:51 PM, Alexander Graf wrote:
>> Just put your own (or your employers').  If someone contributed to 
>> the code they can add their copyrights (or ask you do do it before 
>> inclusion).
>>
>> It would be good to get Paul's or Ben's so that the unimportant 
>> characters between the whitespace get some braintime.
>
>
> So you mean I just put both copyright statements there? That's a nice 
> idea!
>
>

I meant Paul's or Ben's *review*.

-- 
error compiling committee.c: too many arguments to function

Re: [PATCH 07/10] KVM: PPC: Add PAPR hypercall code for PR mode

[Benjamin Herrenschmidt]

On Tue, 2011-08-09 at 20:01 +0300, Avi Kivity wrote:
> On 08/09/2011 07:51 PM, Alexander Graf wrote:
> >> Just put your own (or your employers').  If someone contributed to 
> >> the code they can add their copyrights (or ask you do do it before 
> >> inclusion).
> >>
> >> It would be good to get Paul's or Ben's so that the unimportant 
> >> characters between the whitespace get some braintime.
> >
> >
> > So you mean I just put both copyright statements there? That's a nice 
> > idea!
> >
> >
> 
> I meant Paul's or Ben's *review*.

Ben's currently travelling doing some bringup :-) I will try to have a
look but I can't promise anything for the next 2 weeks.

Cheers,
Ben.

Re: [PATCH 07/10] KVM: PPC: Add PAPR hypercall code for PR mode

[David Gibson]

On Tue, Aug 09, 2011 at 06:31:45PM +0200, Alexander Graf wrote:
> When running a PAPR guest, we need to handle a few hypercalls in kernel space,
> most prominently the page table invalidation (to sync the shadows).
> 
> So this patch adds handling for a few PAPR hypercalls to PR mode KVM. I tried
> to share the code with HV mode, but it ended up being a lot easier this way
> around, as the two differ too much in those details.

Are these strictly necessary, or just an optimization?  Because you're
using the space allocated by qemu for the guest hash table, it seems
to be you could just let h_enter fall through to qemu which will put
the right thing into the guest hash table which you can then walk in
the kernel translation code.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [PATCH 07/10] KVM: PPC: Add PAPR hypercall code for PR mode

[Alexander Graf]

Am 12.08.2011 um 05:35 schrieb David Gibson <david@gibson.dropbear.id.au>:

> On Tue, Aug 09, 2011 at 06:31:45PM +0200, Alexander Graf wrote:
>> When running a PAPR guest, we need to handle a few hypercalls in kernel s=
pace,
>> most prominently the page table invalidation (to sync the shadows).
>>=20
>> So this patch adds handling for a few PAPR hypercalls to PR mode KVM. I t=
ried
>> to share the code with HV mode, but it ended up being a lot easier this w=
ay
>> around, as the two differ too much in those details.
>=20
> Are these strictly necessary, or just an optimization?  Because you're
> using the space allocated by qemu for the guest hash table, it seems
> to be you could just let h_enter fall through to qemu which will put
> the right thing into the guest hash table which you can then walk in
> the kernel translation code.

Every time a PTE can be invalidated, we need to do so in kvm to keep the SPT=
 in sync. IIRC h_enter can evict/overwrite a previous entry, so we need to h=
andle it in kvm as well :). Removal definitely needs to happin in-kernel.


Alex

>=20

Re: [PATCH 07/10] KVM: PPC: Add PAPR hypercall code for PR mode

[David Gibson]

On Fri, Aug 12, 2011 at 07:38:54AM +0200, Alexander Graf wrote:
> 
> Am 12.08.2011 um 05:35 schrieb David Gibson <david@gibson.dropbear.id.au>:
> 
> > On Tue, Aug 09, 2011 at 06:31:45PM +0200, Alexander Graf wrote:
> >> When running a PAPR guest, we need to handle a few hypercalls in kernel space,
> >> most prominently the page table invalidation (to sync the shadows).
> >> 
> >> So this patch adds handling for a few PAPR hypercalls to PR mode KVM. I tried
> >> to share the code with HV mode, but it ended up being a lot easier this way
> >> around, as the two differ too much in those details.
> > 
> > Are these strictly necessary, or just an optimization?  Because you're
> > using the space allocated by qemu for the guest hash table, it seems
> > to be you could just let h_enter fall through to qemu which will put
> > the right thing into the guest hash table which you can then walk in
> > the kernel translation code.
> 
> Every time a PTE can be invalidated, we need to do so in kvm to keep
> the SPT in sync. IIRC h_enter can evict/overwrite a previous entry,
> so we need to handle it in kvm as well :). Removal definitely needs
> to happin in-kernel.

True.  I think you could actually delay this invalidation until the
guest issues the tlbie, but it's probably not worth it.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [PATCH 07/10] KVM: PPC: Add PAPR hypercall code for PR mode

[Alexander Graf]

Am 12.08.2011 um 09:43 schrieb David Gibson <david@gibson.dropbear.id.au>:

> On Fri, Aug 12, 2011 at 07:38:54AM +0200, Alexander Graf wrote:
>>=20
>> Am 12.08.2011 um 05:35 schrieb David Gibson <david@gibson.dropbear.id.au>=
:
>>=20
>>> On Tue, Aug 09, 2011 at 06:31:45PM +0200, Alexander Graf wrote:
>>>> When running a PAPR guest, we need to handle a few hypercalls in kernel=
 space,
>>>> most prominently the page table invalidation (to sync the shadows).
>>>>=20
>>>> So this patch adds handling for a few PAPR hypercalls to PR mode KVM. I=
 tried
>>>> to share the code with HV mode, but it ended up being a lot easier this=
 way
>>>> around, as the two differ too much in those details.
>>>=20
>>> Are these strictly necessary, or just an optimization?  Because you're
>>> using the space allocated by qemu for the guest hash table, it seems
>>> to be you could just let h_enter fall through to qemu which will put
>>> the right thing into the guest hash table which you can then walk in
>>> the kernel translation code.
>>=20
>> Every time a PTE can be invalidated, we need to do so in kvm to keep
>> the SPT in sync. IIRC h_enter can evict/overwrite a previous entry,
>> so we need to handle it in kvm as well :). Removal definitely needs
>> to happin in-kernel.
>=20
> True.  I think you could actually delay this invalidation until the
> guest issues the tlbie, but it's probably not worth it.

Well, since we need to have HTAB modification code in kvm for PR either way,=
 I'd rather have all of it at the same place :)

Alex=

[PATCH 08/10] KVM: PPC: Stub emulate CFAR and PURR SPRs

[Alexander Graf]

Recent Linux versions use the CFAR and PURR SPRs, but don't really care about
their contents (yet). So for now, we can simply return 0 when the guest wants
to read them.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 arch/powerpc/kvm/book3s_emulate.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/kvm/book3s_emulate.c b/arch/powerpc/kvm/book3s_emulate.c
index bf0ddcd..0c9dc62 100644
--- a/arch/powerpc/kvm/book3s_emulate.c
+++ b/arch/powerpc/kvm/book3s_emulate.c
@@ -473,6 +473,10 @@ int kvmppc_core_emulate_mfspr(struct kvm_vcpu *vcpu, int sprn, int rt)
 	case SPRN_HID5:
 		kvmppc_set_gpr(vcpu, rt, to_book3s(vcpu)->hid[5]);
 		break;
+	case SPRN_CFAR:
+	case SPRN_PURR:
+		kvmppc_set_gpr(vcpu, rt, 0);
+		break;
 	case SPRN_GQR0:
 	case SPRN_GQR1:
 	case SPRN_GQR2:
-- 
1.6.0.2

[PATCH 09/10] KVM: PPC: Support SC1 hypercalls for PAPR in PR mode

[Alexander Graf]

PAPR defines hypercalls as SC1 instructions. Using these, the guest modifies
page tables and does other privileged operations that it wouldn't be allowed
to do in supervisor mode.

This patch adds support for PR KVM to trap these instructions and route them
through the same PAPR hypercall interface that we already use for HV style
KVM.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 arch/powerpc/kvm/book3s_pr.c |   22 +++++++++++++++++++++-
 1 files changed, 21 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index 78dcf65..48558f6 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -648,7 +648,27 @@ program_interrupt:
 		break;
 	}
 	case BOOK3S_INTERRUPT_SYSCALL:
-		if (vcpu->arch.osi_enabled &&
+		if (vcpu->arch.papr_enabled &&
+		    (kvmppc_get_last_inst(vcpu) == 0x44000022) &&
+		    !(vcpu->arch.shared->msr & MSR_PR)) {
+			/* SC 1 papr hypercalls */
+			ulong cmd = kvmppc_get_gpr(vcpu, 3);
+			int i;
+
+			if (kvmppc_h_pr(vcpu, cmd) == EMULATE_DONE) {
+				r = RESUME_GUEST;
+				break;
+			}
+
+			run->papr_hcall.nr = cmd;
+			for (i = 0; i < 9; ++i) {
+				ulong gpr = kvmppc_get_gpr(vcpu, 4 + i);
+				run->papr_hcall.args[i] = gpr;
+			}
+			run->exit_reason = KVM_EXIT_PAPR_HCALL;
+			vcpu->arch.hcall_needed = 1;
+			r = RESUME_HOST;
+		} else if (vcpu->arch.osi_enabled &&
 		    (((u32)kvmppc_get_gpr(vcpu, 3)) == OSI_SC_MAGIC_R3) &&
 		    (((u32)kvmppc_get_gpr(vcpu, 4)) == OSI_SC_MAGIC_R4)) {
 			/* MOL hypercalls */
-- 
1.6.0.2

Re: [PATCH 09/10] KVM: PPC: Support SC1 hypercalls for PAPR in PR mode

[David Gibson]

On Tue, Aug 09, 2011 at 06:31:47PM +0200, Alexander Graf wrote:
> PAPR defines hypercalls as SC1 instructions. Using these, the guest modifies
> page tables and does other privileged operations that it wouldn't be allowed
> to do in supervisor mode.
> 
> This patch adds support for PR KVM to trap these instructions and route them
> through the same PAPR hypercall interface that we already use for HV style
> KVM.

This will work on a powermac or bare metal host.  Unfortunately, it's
not enough on a pSeries LPAR host - the sc 1 instruction from the
guest problem state will go direct to the hypervisor, which will
return an error rather than trapping to the guest kernel.

The only way around this I can see is for qemu to search for and patch
up sc 1 instructions to something else.  Obviously that would also
need some kernel support, and probably a capability to let it know if
it's necessary.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [PATCH 09/10] KVM: PPC: Support SC1 hypercalls for PAPR in PR mode

[Alexander Graf]

Am 12.08.2011 um 05:33 schrieb David Gibson <david@gibson.dropbear.id.au>:

> On Tue, Aug 09, 2011 at 06:31:47PM +0200, Alexander Graf wrote:
>> PAPR defines hypercalls as SC1 instructions. Using these, the guest modif=
ies
>> page tables and does other privileged operations that it wouldn't be allo=
wed
>> to do in supervisor mode.
>>=20
>> This patch adds support for PR KVM to trap these instructions and route t=
hem
>> through the same PAPR hypercall interface that we already use for HV styl=
e
>> KVM.
>=20
> This will work on a powermac or bare metal host.  Unfortunately, it's
> not enough on a pSeries LPAR host - the sc 1 instruction from the
> guest problem state will go direct to the hypervisor, which will
> return an error rather than trapping to the guest kernel.
>=20
> The only way around this I can see is for qemu to search for and patch
> up sc 1 instructions to something else.  Obviously that would also
> need some kernel support, and probably a capability to let it know if
> it's necessary.

Well I'd like to keep Qemu out of the patching business, so the guest kernel=
 would have to patch itself. But yes, PHyP guests can't run this target yet :=
). I'll take a stab at that too, but one continent at a time! ;)


Alex

>=20

Re: [PATCH 09/10] KVM: PPC: Support SC1 hypercalls for PAPR in PR mode

[David Gibson]

On Fri, Aug 12, 2011 at 07:35:42AM +0200, Alexander Graf wrote:
> 
> Am 12.08.2011 um 05:33 schrieb David Gibson <david@gibson.dropbear.id.au>:
> 
> > On Tue, Aug 09, 2011 at 06:31:47PM +0200, Alexander Graf wrote:
> >> PAPR defines hypercalls as SC1 instructions. Using these, the guest modifies
> >> page tables and does other privileged operations that it wouldn't be allowed
> >> to do in supervisor mode.
> >> 
> >> This patch adds support for PR KVM to trap these instructions and route them
> >> through the same PAPR hypercall interface that we already use for HV style
> >> KVM.
> > 
> > This will work on a powermac or bare metal host.  Unfortunately, it's
> > not enough on a pSeries LPAR host - the sc 1 instruction from the
> > guest problem state will go direct to the hypervisor, which will
> > return an error rather than trapping to the guest kernel.
> > 
> > The only way around this I can see is for qemu to search for and patch
> > up sc 1 instructions to something else.  Obviously that would also
> > need some kernel support, and probably a capability to let it know if
> > it's necessary.
> 
> Well I'd like to keep Qemu out of the patching business, so the
> guest kernel would have to patch itself.

Well sure, but guest patching itself means it can't run existing
kernels.  I thought qemu already patched a few things, ugly though
that approach is.

> But yes, PHyP guests can't
> run this target yet :). I'll take a stab at that too, but one
> continent at a time! ;)

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [PATCH 09/10] KVM: PPC: Support SC1 hypercalls for PAPR in PR mode

[Alexander Graf]

Am 12.08.2011 um 09:43 schrieb David Gibson <david@gibson.dropbear.id.au>:

> On Fri, Aug 12, 2011 at 07:35:42AM +0200, Alexander Graf wrote:
>>=20
>> Am 12.08.2011 um 05:33 schrieb David Gibson <david@gibson.dropbear.id.au>=
:
>>=20
>>> On Tue, Aug 09, 2011 at 06:31:47PM +0200, Alexander Graf wrote:
>>>> PAPR defines hypercalls as SC1 instructions. Using these, the guest mod=
ifies
>>>> page tables and does other privileged operations that it wouldn't be al=
lowed
>>>> to do in supervisor mode.
>>>>=20
>>>> This patch adds support for PR KVM to trap these instructions and route=
 them
>>>> through the same PAPR hypercall interface that we already use for HV st=
yle
>>>> KVM.
>>>=20
>>> This will work on a powermac or bare metal host.  Unfortunately, it's
>>> not enough on a pSeries LPAR host - the sc 1 instruction from the
>>> guest problem state will go direct to the hypervisor, which will
>>> return an error rather than trapping to the guest kernel.
>>>=20
>>> The only way around this I can see is for qemu to search for and patch
>>> up sc 1 instructions to something else.  Obviously that would also
>>> need some kernel support, and probably a capability to let it know if
>>> it's necessary.
>>=20
>> Well I'd like to keep Qemu out of the patching business, so the
>> guest kernel would have to patch itself.
>=20
> Well sure, but guest patching itself means it can't run existing
> kernels.  I thought qemu already patched a few things, ugly though
> that approach is.

Nope, qemu doesn't patch guest code by itself. The only time the guest kerne=
l doesn't patch itself is the TPR acceleration for Windows - because we can'=
t modify the guest here.

I also don't think it's that important to support older Linux guests if it m=
eans we need to patch the guest from the outside :). If you really need to u=
se PHyP, just run a newer guest kernel or -M mac99.

One thing I agree with though is that we should fail the CAP enable if we ru=
n on broken hypervisors.

Alex

>=20

[PATCH] KVM: PPC: protect use of kvmppc_h_pr

[Andreas Schwab]

kvmppc_h_pr is only available if CONFIG_KVM_BOOK3S_64_PR.

Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
---
 arch/powerpc/kvm/book3s_pr.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index bc4d50d..05473b5 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -660,10 +660,12 @@ program_interrupt:
 			ulong cmd = kvmppc_get_gpr(vcpu, 3);
 			int i;
 
+#ifdef CONFIG_KVM_BOOK3S_64_PR
 			if (kvmppc_h_pr(vcpu, cmd) == EMULATE_DONE) {
 				r = RESUME_GUEST;
 				break;
 			}
+#endif
 
 			run->papr_hcall.nr = cmd;
 			for (i = 0; i < 9; ++i) {
-- 
1.7.7.2


-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [PATCH] KVM: PPC: protect use of kvmppc_h_pr

[Alexander Graf]

On 11/08/2011 06:17 PM, Andreas Schwab wrote:
> kvmppc_h_pr is only available if CONFIG_KVM_BOOK3S_64_PR.
>
> Signed-off-by: Andreas Schwab<schwab@linux-m68k.org>

Thanks, applied to kvm-ppc-next.


Alex

[PATCH 10/10] KVM: PPC: Enable the PAPR CAP for Book3S

[Alexander Graf]

Now that Book3S PV mode can also run PAPR guests, we can add a PAPR cap and
enable it for all Book3S targets. Enabling that CAP switches KVM into PAPR
mode.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 arch/powerpc/kvm/powerpc.c |    5 +++++
 include/linux/kvm.h        |    1 +
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 17a5c83..13bc798 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -189,6 +189,7 @@ int kvm_dev_ioctl_check_extension(long ext)
 #else
 	case KVM_CAP_PPC_SEGSTATE:
 	case KVM_CAP_PPC_HIOR:
+	case KVM_CAP_PPC_PAPR:
 #endif
 	case KVM_CAP_PPC_UNSET_IRQ:
 	case KVM_CAP_PPC_IRQ_LEVEL:
@@ -572,6 +573,10 @@ static int kvm_vcpu_ioctl_enable_cap(struct kvm_vcpu *vcpu,
 		r = 0;
 		vcpu->arch.osi_enabled = true;
 		break;
+	case KVM_CAP_PPC_PAPR:
+		r = 0;
+		vcpu->arch.papr_enabled = true;
+		break;
 	default:
 		r = -EINVAL;
 		break;
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index 4d33f78..2d7161c 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -555,6 +555,7 @@ struct kvm_ppc_pvinfo {
 #define KVM_CAP_PPC_RMA	65
 #define KVM_CAP_MAX_VCPUS 66       /* returns max vcpus per vm */
 #define KVM_CAP_PPC_HIOR 67
+#define KVM_CAP_PPC_PAPR 68
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
-- 
1.6.0.2

Re: [PATCH 10/10] KVM: PPC: Enable the PAPR CAP for Book3S

[Paul Mackerras]

On Tue, Aug 09, 2011 at 06:31:48PM +0200, Alexander Graf wrote:

> Now that Book3S PV mode can also run PAPR guests, we can add a PAPR cap and
> enable it for all Book3S targets. Enabling that CAP switches KVM into PAPR
> mode.

Don't we want to enable it only for 64-bit hosts?  Trying to run a
PAPR guest on a 32-bit Book 3S host won't work very well, unless I am
missing something...

Regards,
Paul.

Re: [PATCH 10/10] KVM: PPC: Enable the PAPR CAP for Book3S

[Alexander Graf]

Am 10.08.2011 um 06:42 schrieb Paul Mackerras <paulus@samba.org>:

> On Tue, Aug 09, 2011 at 06:31:48PM +0200, Alexander Graf wrote:
>=20
>> Now that Book3S PV mode can also run PAPR guests, we can add a PAPR cap a=
nd
>> enable it for all Book3S targets. Enabling that CAP switches KVM into PAP=
R
>> mode.
>=20
> Don't we want to enable it only for 64-bit hosts?  Trying to run a
> PAPR guest on a 32-bit Book 3S host won't work very well, unless I am
> missing something...

I agree that it doesn't make sense, but if anything we should restrict it to=
 64-bit _guests_. you can also run 32-bit guests on 64-bit hosts.

And so far, we don't have a single interface setting PVR and PAPR mode at th=
e same time, so you could still enable PAPR with a 64-bit guest CPU and then=
 switch to a 32-bit CPU.

It'd be a nightmare to check all configurations on every setter function.

Unless...

We could introduce a sanity check function that gets executed every time we c=
hange PVR or enable PAPR. That could set a variable in the vcpu struct to in=
dicate that the config is ok. We could then check that on vcpu_run.


Alex

>=20

Re: [PATCH 10/10] KVM: PPC: Enable the PAPR CAP for Book3S

[Paul Mackerras]

On Wed, Aug 10, 2011 at 09:59:41AM +0200, Alexander Graf wrote:
> 
> Am 10.08.2011 um 06:42 schrieb Paul Mackerras <paulus@samba.org>:
> 
> > On Tue, Aug 09, 2011 at 06:31:48PM +0200, Alexander Graf wrote:
> > 
> >> Now that Book3S PV mode can also run PAPR guests, we can add a PAPR cap and
> >> enable it for all Book3S targets. Enabling that CAP switches KVM into PAPR
> >> mode.
> > 
> > Don't we want to enable it only for 64-bit hosts?  Trying to run a
> > PAPR guest on a 32-bit Book 3S host won't work very well, unless I am
> > missing something...
> 
> I agree that it doesn't make sense, but if anything we should
> restrict it to 64-bit _guests_. you can also run 32-bit guests on
> 64-bit hosts.

I had a look in PAPR and I didn't find anything that says the
processor has to be 64-bit, so I guess a 32-bit PAPR guest is possible
in theory.  However, I don't think there are currently any 32-bit PAPR
operating systems that would use hcalls.

> And so far, we don't have a single interface setting PVR and PAPR
> mode at the same time, so you could still enable PAPR with a 64-bit
> guest CPU and then switch to a 32-bit CPU.
> 
> It'd be a nightmare to check all configurations on every setter function.
> 
> Unless...
> 
> We could introduce a sanity check function that gets executed every
> time we change PVR or enable PAPR. That could set a variable in the
> vcpu struct to indicate that the config is ok. We could then check
> that on vcpu_run.

It's probably not worth worrying about it.

The rest of the series looks very nice.

Regards,
Paul.

Re: [PATCH 10/10] KVM: PPC: Enable the PAPR CAP for Book3S

[Alexander Graf]

On 08/10/2011 02:26 PM, Paul Mackerras wrote:
> On Wed, Aug 10, 2011 at 09:59:41AM +0200, Alexander Graf wrote:
>> Am 10.08.2011 um 06:42 schrieb Paul Mackerras<paulus@samba.org>:
>>
>>> On Tue, Aug 09, 2011 at 06:31:48PM +0200, Alexander Graf wrote:
>>>
>>>> Now that Book3S PV mode can also run PAPR guests, we can add a PAPR cap and
>>>> enable it for all Book3S targets. Enabling that CAP switches KVM into PAPR
>>>> mode.
>>> Don't we want to enable it only for 64-bit hosts?  Trying to run a
>>> PAPR guest on a 32-bit Book 3S host won't work very well, unless I am
>>> missing something...
>> I agree that it doesn't make sense, but if anything we should
>> restrict it to 64-bit _guests_. you can also run 32-bit guests on
>> 64-bit hosts.
> I had a look in PAPR and I didn't find anything that says the
> processor has to be 64-bit, so I guess a 32-bit PAPR guest is possible
> in theory.  However, I don't think there are currently any 32-bit PAPR
> operating systems that would use hcalls.

That's what I figured :). The code flow we're affecting here is pretty 
much generic.

>> And so far, we don't have a single interface setting PVR and PAPR
>> mode at the same time, so you could still enable PAPR with a 64-bit
>> guest CPU and then switch to a 32-bit CPU.
>>
>> It'd be a nightmare to check all configurations on every setter function.
>>
>> Unless...
>>
>> We could introduce a sanity check function that gets executed every
>> time we change PVR or enable PAPR. That could set a variable in the
>> vcpu struct to indicate that the config is ok. We could then check
>> that on vcpu_run.
> It's probably not worth worrying about it.

Too late, already implemented it :). It really does make sense to have 
some sort of checking here - even if it only means that our hypercall 
implementation can't handle it yet or that we didn't test it. And we can 
put the "HV KVM can only run PAPR" check in there as well.


Alex

Re: [PATCH 00/10] PAPR virtualization on PR KVM

[Avi Kivity]

On 08/09/2011 07:31 PM, Alexander Graf wrote:
> In KVM for Book3S PPC we currently have 2 implementations. There
> is the PR based implementation which works on any POWER system
> you pass in and the super fast HV implementation which requires
> libre firmware (so almost nobody can use it).

Did you mean, non-libre?

>
> Currently, the two target two different machine types, with PR KVM
> being used for bare metal system virtualization, while the HV KVM
> is used to virtualize PAPR.
>
> In an effort to make things more cozy and transparent to the user,
> this patch set implements PAPR capabilities to the PR KVM side, so
> a user doesn't have to worry what the respective kernel module
> supports. Any machine he's virtualizing "just works".
>

Nice.  I went though it and nothing shouted "I'm wrong, kill me please", 
though I don't claim to understand more than 5% of it.

-- 
error compiling committee.c: too many arguments to function

Re: [PATCH 00/10] PAPR virtualization on PR KVM

[Alexander Graf]

On 08/09/2011 06:42 PM, Avi Kivity wrote:
> On 08/09/2011 07:31 PM, Alexander Graf wrote:
>> In KVM for Book3S PPC we currently have 2 implementations. There
>> is the PR based implementation which works on any POWER system
>> you pass in and the super fast HV implementation which requires
>> libre firmware (so almost nobody can use it).
>
> Did you mean, non-libre?

No, I did mean libre :). Usually firmware on IBM POWER systems already 
uses the hypervisor mode for itself, so we can't leverage it. The only 
system that is publicly available and can run HV KVM is the YDL 
PowerStation which is running SLOF, an open source firmware.

>
>>
>> Currently, the two target two different machine types, with PR KVM
>> being used for bare metal system virtualization, while the HV KVM
>> is used to virtualize PAPR.
>>
>> In an effort to make things more cozy and transparent to the user,
>> this patch set implements PAPR capabilities to the PR KVM side, so
>> a user doesn't have to worry what the respective kernel module
>> supports. Any machine he's virtualizing "just works".
>>
>
> Nice.  I went though it and nothing shouted "I'm wrong, kill me 
> please", though I don't claim to understand more than 5% of it.

Heh :). The thing giving me the most headaches here is the ENABLE_CAP 
part on PAPR. I'd love to have a more flexible framework there that can 
configure kvm into the right mode of operation completely, so we get the 
chance of passing back "Sorry, that mode doesn't work for me" at the end 
of the day.

But I guess we can just do that with the cap enablings too. It's just 
slightly more icky.


Alex

[PATCH 11/10] KVM: PPC: Add sanity checking to vcpu_run

[Alexander Graf]

There are multiple features in PowerPC KVM that can now be enabled
depending on the user's wishes. Some of the combinations don't make
sense or don't work though.

So this patch adds a way to check if the executing environment would
actually be able to run the guest properly. It also adds sanity
checks if PVR is set (should always be true given the current code
flow), if PAPR is only used with book3s_64 where it works and that
HV KVM is only used in PAPR mode.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 arch/powerpc/include/asm/kvm.h      |    5 +++++
 arch/powerpc/include/asm/kvm_host.h |    2 ++
 arch/powerpc/include/asm/kvm_ppc.h  |    1 +
 arch/powerpc/kvm/44x.c              |    2 ++
 arch/powerpc/kvm/book3s_hv.c        |    8 ++++++++
 arch/powerpc/kvm/book3s_pr.c        |   10 ++++++++++
 arch/powerpc/kvm/booke.c            |   10 +++++++++-
 arch/powerpc/kvm/e500.c             |    2 ++
 arch/powerpc/kvm/powerpc.c          |   28 ++++++++++++++++++++++++++++
 9 files changed, 67 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/include/asm/kvm.h b/arch/powerpc/include/asm/kvm.h
index a6a253e..08fe69e 100644
--- a/arch/powerpc/include/asm/kvm.h
+++ b/arch/powerpc/include/asm/kvm.h
@@ -284,6 +284,11 @@ struct kvm_guest_debug_arch {
 #define KVM_INTERRUPT_UNSET	-2U
 #define KVM_INTERRUPT_SET_LEVEL	-3U
 
+#define KVM_CPU_440		1
+#define KVM_CPU_E500V2		2
+#define KVM_CPU_3S_32		3
+#define KVM_CPU_3S_64		4
+
 /* for KVM_CAP_SPAPR_TCE */
 struct kvm_create_spapr_tce {
 	__u64 liobn;
diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
index e681302..2b8284f 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -390,6 +390,8 @@ struct kvm_vcpu_arch {
 	u8 osi_needed;
 	u8 osi_enabled;
 	u8 papr_enabled;
+	u8 sane;
+	u8 cpu_type;
 	u8 hcall_needed;
 
 	u32 cpr0_cfgaddr; /* holds the last set cpr0_cfgaddr */
diff --git a/arch/powerpc/include/asm/kvm_ppc.h b/arch/powerpc/include/asm/kvm_ppc.h
index d121f49..46efd1a 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -66,6 +66,7 @@ extern int kvmppc_emulate_instruction(struct kvm_run *run,
 extern int kvmppc_emulate_mmio(struct kvm_run *run, struct kvm_vcpu *vcpu);
 extern void kvmppc_emulate_dec(struct kvm_vcpu *vcpu);
 extern u32 kvmppc_get_dec(struct kvm_vcpu *vcpu, u64 tb);
+extern int kvmppc_sanity_check(struct kvm_vcpu *vcpu);
 
 /* Core-specific hooks */
 
diff --git a/arch/powerpc/kvm/44x.c b/arch/powerpc/kvm/44x.c
index da3a122..ca1f88b 100644
--- a/arch/powerpc/kvm/44x.c
+++ b/arch/powerpc/kvm/44x.c
@@ -78,6 +78,8 @@ int kvmppc_core_vcpu_setup(struct kvm_vcpu *vcpu)
 	for (i = 0; i < ARRAY_SIZE(vcpu_44x->shadow_refs); i++)
 		vcpu_44x->shadow_refs[i].gtlb_index = -1;
 
+	vcpu->arch.cpu_type = KVM_CPU_440;
+
 	return 0;
 }
 
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index cc0d7f1..830e07a 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -510,6 +510,9 @@ struct kvm_vcpu *kvmppc_core_vcpu_create(struct kvm *kvm, unsigned int id)
 	spin_unlock(&vcore->lock);
 	vcpu->arch.vcore = vcore;
 
+	vcpu->arch.cpu_type = KVM_CPU_3S_64;
+	kvmppc_sanity_check(vcpu);
+
 	return vcpu;
 
 free_vcpu:
@@ -800,6 +803,11 @@ int kvmppc_vcpu_run(struct kvm_run *run, struct kvm_vcpu *vcpu)
 {
 	int r;
 
+	if (!vcpu->arch.sane) {
+		kvm_run->exit_reason = KVM_EXIT_INTERNAL_ERROR;
+		return -EINVAL;
+	}
+
 	do {
 		r = kvmppc_run_vcpu(run, vcpu);
 
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index 48558f6..6e3488b 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -153,6 +153,7 @@ void kvmppc_set_pvr(struct kvm_vcpu *vcpu, u32 pvr)
 		if (!to_book3s(vcpu)->hior_sregs)
 			to_book3s(vcpu)->hior = 0xfff00000;
 		to_book3s(vcpu)->msr_mask = 0xffffffffffffffffULL;
+		vcpu->arch.cpu_type = KVM_CPU_3S_64;
 	} else
 #endif
 	{
@@ -160,8 +161,11 @@ void kvmppc_set_pvr(struct kvm_vcpu *vcpu, u32 pvr)
 		if (!to_book3s(vcpu)->hior_sregs)
 			to_book3s(vcpu)->hior = 0;
 		to_book3s(vcpu)->msr_mask = 0xffffffffULL;
+		vcpu->arch.cpu_type = KVM_CPU_3S_32;
 	}
 
+	kvmppc_sanity_check(vcpu);
+
 	/* If we are in hypervisor level on 970, we can tell the CPU to
 	 * treat DCBZ as 32 bytes store */
 	vcpu->arch.hflags &= ~BOOK3S_HFLAG_DCBZ32;
@@ -938,6 +942,12 @@ int kvmppc_vcpu_run(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu)
 #endif
 	ulong ext_msr;
 
+	/* Check if we can run the vcpu at all */
+	if (!vcpu->arch.sane) {
+		kvm_run->exit_reason = KVM_EXIT_INTERNAL_ERROR;
+		return -EINVAL;
+	}
+
 	/* No need to go into the guest when all we do is going out */
 	if (signal_pending(current)) {
 		kvm_run->exit_reason = KVM_EXIT_INTR;
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index ee45fa0..bb6c988 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -316,6 +316,11 @@ int kvmppc_vcpu_run(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu)
 {
 	int ret;
 
+	if (!vcpu->arch.sane) {
+		kvm_run->exit_reason = KVM_EXIT_INTERNAL_ERROR;
+		return -EINVAL;
+	}
+
 	local_irq_disable();
 	kvm_guest_enter();
 	ret = __kvmppc_vcpu_run(kvm_run, vcpu);
@@ -618,6 +623,7 @@ int kvmppc_handle_exit(struct kvm_run *run, struct kvm_vcpu *vcpu,
 int kvm_arch_vcpu_setup(struct kvm_vcpu *vcpu)
 {
 	int i;
+	int r;
 
 	vcpu->arch.pc = 0;
 	vcpu->arch.shared->msr = 0;
@@ -634,7 +640,9 @@ int kvm_arch_vcpu_setup(struct kvm_vcpu *vcpu)
 
 	kvmppc_init_timing_stats(vcpu);
 
-	return kvmppc_core_vcpu_setup(vcpu);
+	r = kvmppc_core_vcpu_setup(vcpu);
+	kvmppc_sanity_check(vcpu);
+	return r;
 }
 
 int kvm_arch_vcpu_ioctl_get_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
diff --git a/arch/powerpc/kvm/e500.c b/arch/powerpc/kvm/e500.c
index 797a744..26d2090 100644
--- a/arch/powerpc/kvm/e500.c
+++ b/arch/powerpc/kvm/e500.c
@@ -73,6 +73,8 @@ int kvmppc_core_vcpu_setup(struct kvm_vcpu *vcpu)
 	/* Since booke kvm only support one core, update all vcpus' PIR to 0 */
 	vcpu->vcpu_id = 0;
 
+	vcpu->arch.cpu_type = KVM_CPU_E500V2;
+
 	return 0;
 }
 
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 13bc798..a8000ce 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -95,6 +95,31 @@ int kvmppc_kvm_pv(struct kvm_vcpu *vcpu)
 	return r;
 }
 
+int kvmppc_sanity_check(struct kvm_vcpu *vcpu)
+{
+	int r = false;
+
+	/* We have to know what CPU to virtualize */
+	if (!vcpu->arch.pvr)
+		goto out;
+
+	/* PAPR only works with book3s_64 */
+	if ((vcpu->arch.cpu_type != KVM_CPU_3S_64) && vcpu->arch.papr_enabled)
+		goto out;
+
+#ifdef CONFIG_KVM_BOOK3S_64_HV
+	/* HV KVM can only do PAPR mode for now */
+	if (!vcpu->arch.papr_enabled)
+		goto out;
+#endif
+
+	r = true;
+
+out:
+	vcpu->arch.sane = r;
+	return r ? 0 : -EINVAL;
+}
+
 int kvmppc_emulate_mmio(struct kvm_run *run, struct kvm_vcpu *vcpu)
 {
 	enum emulation_result er;
@@ -582,6 +607,9 @@ static int kvm_vcpu_ioctl_enable_cap(struct kvm_vcpu *vcpu,
 		break;
 	}
 
+	if (!r)
+		r = kvmppc_sanity_check(vcpu);
+
 	return r;
 }
 
-- 
1.6.0.2