[PATCH 00/15] KVM: PPC: MOL bringup patches

[PATCH 00/15] KVM: PPC: MOL bringup patches

[Alexander Graf]

Mac-on-Linux has always lacked PPC64 host support. This is going to
change now!

This patchset contains minor patches to enable MOL, but is mostly about
bug fixes that came out of running Mac OS X. With this set and a pretty
small patch to MOL I have 10.4.11 running as a guest on a 970MP host.

I'll send the MOl patches to the respective ML in the next days.


v1 -> v2:

 - Add documentation for EXIT_OSI and ENABLE_CAP
 - Add flags to enable_cap
 - Add build fix for !CONFIG_VSX
 - Remove in-paca register check

Alexander Graf (15):
  KVM: PPC: Ensure split mode works
  KVM: PPC: Allow userspace to unset the IRQ line
  KVM: PPC: Make DSISR 32 bits wide
  KVM: PPC: Book3S_32 guest MMU fixes
  KVM: PPC: Split instruction reading out
  KVM: PPC: Don't reload FPU with invalid values
  KVM: PPC: Load VCPU for register fetching
  KVM: PPC: Implement mfsr emulation
  KVM: PPC: Implement BAT reads
  KVM: PPC: Make XER load 32 bit
  KVM: PPC: Implement emulation for lbzux and lhax
  KVM: PPC: Implement alignment interrupt
  KVM: Add support for enabling capabilities per-vcpu
  KVM: PPC: Add OSI hypercall interface
  KVM: PPC: Make build work without CONFIG_VSX/ALTIVEC

 Documentation/kvm/api.txt               |   28 +++++++
 arch/powerpc/include/asm/kvm.h          |    3 +
 arch/powerpc/include/asm/kvm_book3s.h   |   18 +++-
 arch/powerpc/include/asm/kvm_host.h     |    4 +-
 arch/powerpc/include/asm/kvm_ppc.h      |    2 +
 arch/powerpc/kvm/book3s.c               |  130 ++++++++++++++++++++++---------
 arch/powerpc/kvm/book3s_32_mmu.c        |   30 ++++++--
 arch/powerpc/kvm/book3s_64_emulate.c    |   88 +++++++++++++++++++++
 arch/powerpc/kvm/book3s_64_interrupts.S |    2 +-
 arch/powerpc/kvm/book3s_64_slb.S        |    2 +-
 arch/powerpc/kvm/emulate.c              |   20 +++++
 arch/powerpc/kvm/powerpc.c              |   43 ++++++++++-
 include/linux/kvm.h                     |   17 ++++
 13 files changed, 335 insertions(+), 52 deletions(-)

[PATCH 01/15] KVM: PPC: Ensure split mode works

[Alexander Graf]

On PowerPC we can go into MMU Split Mode. That means that either
data relocation is on but instruction relocation is off or vice
versa.

That mode didn't work properly, as we weren't always flushing
entries when going into a new split mode, potentially mapping
different code or data that we're supposed to.

Signed-off-by: Alexander Graf <agraf-l3A5Bk7waGM@public.gmane.org>
---
 arch/powerpc/include/asm/kvm_book3s.h |    9 +++---
 arch/powerpc/kvm/book3s.c             |   46 +++++++++++++++++---------------
 2 files changed, 29 insertions(+), 26 deletions(-)

diff --git a/arch/powerpc/include/asm/kvm_book3s.h b/arch/powerpc/include/asm/kvm_book3s.h
index e6ea974..14d0262 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -99,10 +99,11 @@ struct kvmppc_vcpu_book3s {
 #define CONTEXT_GUEST		1
 #define CONTEXT_GUEST_END	2
 
-#define VSID_REAL	0xfffffffffff00000
-#define VSID_REAL_DR	0xffffffffffe00000
-#define VSID_REAL_IR	0xffffffffffd00000
-#define VSID_BAT	0xffffffffffc00000
+#define VSID_REAL_DR	0x7ffffffffff00000
+#define VSID_REAL_IR	0x7fffffffffe00000
+#define VSID_SPLIT_MASK	0x7fffffffffe00000
+#define VSID_REAL	0x7fffffffffc00000
+#define VSID_BAT	0x7fffffffffb00000
 #define VSID_PR		0x8000000000000000
 
 extern void kvmppc_mmu_pte_flush(struct kvm_vcpu *vcpu, u64 ea, u64 ea_mask);
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 94c229d..c2ffb91 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -133,6 +133,14 @@ void kvmppc_set_msr(struct kvm_vcpu *vcpu, u64 msr)
 
 	if (((vcpu->arch.msr & (MSR_IR|MSR_DR)) != (old_msr & (MSR_IR|MSR_DR))) ||
 	    (vcpu->arch.msr & MSR_PR) != (old_msr & MSR_PR)) {
+		bool dr = (vcpu->arch.msr & MSR_DR) ? true : false;
+		bool ir = (vcpu->arch.msr & MSR_IR) ? true : false;
+
+		/* Flush split mode PTEs */
+		if (dr != ir)
+			kvmppc_mmu_pte_vflush(vcpu, VSID_SPLIT_MASK,
+					      VSID_SPLIT_MASK);
+
 		kvmppc_mmu_flush_segments(vcpu);
 		kvmppc_mmu_map_segment(vcpu, vcpu->arch.pc);
 	}
@@ -395,15 +403,7 @@ static int kvmppc_xlate(struct kvm_vcpu *vcpu, ulong eaddr, bool data,
 	} else {
 		pte->eaddr = eaddr;
 		pte->raddr = eaddr & 0xffffffff;
-		pte->vpage = eaddr >> 12;
-		switch (vcpu->arch.msr & (MSR_DR|MSR_IR)) {
-		case 0:
-			pte->vpage |= VSID_REAL;
-		case MSR_DR:
-			pte->vpage |= VSID_REAL_DR;
-		case MSR_IR:
-			pte->vpage |= VSID_REAL_IR;
-		}
+		pte->vpage = VSID_REAL | eaddr >> 12;
 		pte->may_read = true;
 		pte->may_write = true;
 		pte->may_execute = true;
@@ -512,12 +512,10 @@ int kvmppc_handle_pagefault(struct kvm_run *run, struct kvm_vcpu *vcpu,
 	int page_found = 0;
 	struct kvmppc_pte pte;
 	bool is_mmio = false;
+	bool dr = (vcpu->arch.msr & MSR_DR) ? true : false;
+	bool ir = (vcpu->arch.msr & MSR_IR) ? true : false;
 
-	if ( vec == BOOK3S_INTERRUPT_DATA_STORAGE ) {
-		relocated = (vcpu->arch.msr & MSR_DR);
-	} else {
-		relocated = (vcpu->arch.msr & MSR_IR);
-	}
+	relocated = data ? dr : ir;
 
 	/* Resolve real address if translation turned on */
 	if (relocated) {
@@ -529,14 +527,18 @@ int kvmppc_handle_pagefault(struct kvm_run *run, struct kvm_vcpu *vcpu,
 		pte.raddr = eaddr & 0xffffffff;
 		pte.eaddr = eaddr;
 		pte.vpage = eaddr >> 12;
-		switch (vcpu->arch.msr & (MSR_DR|MSR_IR)) {
-		case 0:
-			pte.vpage |= VSID_REAL;
-		case MSR_DR:
-			pte.vpage |= VSID_REAL_DR;
-		case MSR_IR:
-			pte.vpage |= VSID_REAL_IR;
-		}
+	}
+
+	switch (vcpu->arch.msr & (MSR_DR|MSR_IR)) {
+	case 0:
+		pte.vpage |= VSID_REAL;
+		break;
+	case MSR_DR:
+		pte.vpage |= VSID_REAL_DR;
+		break;
+	case MSR_IR:
+		pte.vpage |= VSID_REAL_IR;
+		break;
 	}
 
 	if (vcpu->arch.mmu.is_dcbz32(vcpu) &&
-- 
1.6.0.2

[PATCH 02/15] KVM: PPC: Allow userspace to unset the IRQ line

[Alexander Graf]

Userspace can tell us that it wants to trigger an interrupt. But
so far it can't tell us that it wants to stop triggering one.

So let's interpret the parameter to the ioctl that we have anyways
to tell us if we want to raise or lower the interrupt line.

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

diff --git a/arch/powerpc/include/asm/kvm.h b/arch/powerpc/include/asm/kvm.h
index 19bae31..6c5547d 100644
--- a/arch/powerpc/include/asm/kvm.h
+++ b/arch/powerpc/include/asm/kvm.h
@@ -84,4 +84,7 @@ struct kvm_guest_debug_arch {
 #define KVM_REG_QPR		0x0040
 #define KVM_REG_FQPR		0x0060
 
+#define KVM_INTERRUPT_SET	-1U
+#define KVM_INTERRUPT_UNSET	-2U
+
 #endif /* __LINUX_KVM_POWERPC_H */
diff --git a/arch/powerpc/include/asm/kvm_ppc.h b/arch/powerpc/include/asm/kvm_ppc.h
index c7fcdd7..6a2464e 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -92,6 +92,8 @@ extern void kvmppc_core_queue_dec(struct kvm_vcpu *vcpu);
 extern void kvmppc_core_dequeue_dec(struct kvm_vcpu *vcpu);
 extern void kvmppc_core_queue_external(struct kvm_vcpu *vcpu,
                                        struct kvm_interrupt *irq);
+extern void kvmppc_core_dequeue_external(struct kvm_vcpu *vcpu,
+                                         struct kvm_interrupt *irq);
 
 extern int kvmppc_core_emulate_op(struct kvm_run *run, struct kvm_vcpu *vcpu,
                                   unsigned int op, int *advance);
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index c2ffb91..9e0bc47 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -230,6 +230,12 @@ void kvmppc_core_queue_external(struct kvm_vcpu *vcpu,
 	kvmppc_book3s_queue_irqprio(vcpu, BOOK3S_INTERRUPT_EXTERNAL);
 }
 
+void kvmppc_core_dequeue_external(struct kvm_vcpu *vcpu,
+                                  struct kvm_interrupt *irq)
+{
+	kvmppc_book3s_dequeue_irqprio(vcpu, BOOK3S_INTERRUPT_EXTERNAL);
+}
+
 int kvmppc_book3s_irqprio_deliver(struct kvm_vcpu *vcpu, unsigned int priority)
 {
 	int deliver = 1;
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 5a8eb95..a28a512 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -449,7 +449,10 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
 
 int kvm_vcpu_ioctl_interrupt(struct kvm_vcpu *vcpu, struct kvm_interrupt *irq)
 {
-	kvmppc_core_queue_external(vcpu, irq);
+	if (irq->irq == KVM_INTERRUPT_UNSET)
+		kvmppc_core_dequeue_external(vcpu, irq);
+	else
+		kvmppc_core_queue_external(vcpu, irq);
 
 	if (waitqueue_active(&vcpu->wq)) {
 		wake_up_interruptible(&vcpu->wq);
-- 
1.6.0.2

[PATCH 03/15] KVM: PPC: Make DSISR 32 bits wide

[Alexander Graf]

DSISR is only defined as 32 bits wide. So let's reflect that in the
structs too.

Signed-off-by: Alexander Graf <agraf-l3A5Bk7waGM@public.gmane.org>
---
 arch/powerpc/include/asm/kvm_book3s.h   |    2 +-
 arch/powerpc/include/asm/kvm_host.h     |    2 +-
 arch/powerpc/kvm/book3s_64_interrupts.S |    2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/include/asm/kvm_book3s.h b/arch/powerpc/include/asm/kvm_book3s.h
index 14d0262..9f5a992 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -84,8 +84,8 @@ struct kvmppc_vcpu_book3s {
 	u64 hid[6];
 	u64 gqr[8];
 	int slb_nr;
+	u32 dsisr;
 	u64 sdr1;
-	u64 dsisr;
 	u64 hior;
 	u64 msr_mask;
 	u64 vsid_first;
diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
index 119deb4..0ebda67 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -260,7 +260,7 @@ struct kvm_vcpu_arch {
 
 	u32 last_inst;
 #ifdef CONFIG_PPC64
-	ulong fault_dsisr;
+	u32 fault_dsisr;
 #endif
 	ulong fault_dear;
 	ulong fault_esr;
diff --git a/arch/powerpc/kvm/book3s_64_interrupts.S b/arch/powerpc/kvm/book3s_64_interrupts.S
index c1584d0..faca876 100644
--- a/arch/powerpc/kvm/book3s_64_interrupts.S
+++ b/arch/powerpc/kvm/book3s_64_interrupts.S
@@ -171,7 +171,7 @@ kvmppc_handler_highmem:
 	std	r3, VCPU_PC(r7)
 	std	r4, VCPU_SHADOW_SRR1(r7)
 	std	r5, VCPU_FAULT_DEAR(r7)
-	std	r6, VCPU_FAULT_DSISR(r7)
+	stw	r6, VCPU_FAULT_DSISR(r7)
 
 	ld	r5, VCPU_HFLAGS(r7)
 	rldicl.	r5, r5, 0, 63		/* CR = ((r5 & 1) == 0) */
-- 
1.6.0.2

[PATCH 04/15] KVM: PPC: Book3S_32 guest MMU fixes

[Alexander Graf]

This patch makes the VSID of mapped pages always reflecting all special cases
we have, like split mode.

It also changes the tlbie mask to 0x0ffff000 according to the spec. The mask
we used before was incorrect.

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

diff --git a/arch/powerpc/include/asm/kvm_book3s.h b/arch/powerpc/include/asm/kvm_book3s.h
index 9f5a992..b47b2f5 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -44,6 +44,7 @@ struct kvmppc_sr {
 	bool Ks;
 	bool Kp;
 	bool nx;
+	bool valid;
 };
 
 struct kvmppc_bat {
diff --git a/arch/powerpc/kvm/book3s_32_mmu.c b/arch/powerpc/kvm/book3s_32_mmu.c
index 1483a9b..7071e22 100644
--- a/arch/powerpc/kvm/book3s_32_mmu.c
+++ b/arch/powerpc/kvm/book3s_32_mmu.c
@@ -57,6 +57,8 @@ static inline bool check_debug_ip(struct kvm_vcpu *vcpu)
 
 static int kvmppc_mmu_book3s_32_xlate_bat(struct kvm_vcpu *vcpu, gva_t eaddr,
 					  struct kvmppc_pte *pte, bool data);
+static int kvmppc_mmu_book3s_32_esid_to_vsid(struct kvm_vcpu *vcpu, u64 esid,
+					     u64 *vsid);
 
 static struct kvmppc_sr *find_sr(struct kvmppc_vcpu_book3s *vcpu_book3s, gva_t eaddr)
 {
@@ -66,13 +68,14 @@ static struct kvmppc_sr *find_sr(struct kvmppc_vcpu_book3s *vcpu_book3s, gva_t e
 static u64 kvmppc_mmu_book3s_32_ea_to_vp(struct kvm_vcpu *vcpu, gva_t eaddr,
 					 bool data)
 {
-	struct kvmppc_sr *sre = find_sr(to_book3s(vcpu), eaddr);
+	u64 vsid;
 	struct kvmppc_pte pte;
 
 	if (!kvmppc_mmu_book3s_32_xlate_bat(vcpu, eaddr, &pte, data))
 		return pte.vpage;
 
-	return (((u64)eaddr >> 12) & 0xffff) | (((u64)sre->vsid) << 16);
+	kvmppc_mmu_book3s_32_esid_to_vsid(vcpu, eaddr >> SID_SHIFT, &vsid);
+	return (((u64)eaddr >> 12) & 0xffff) | (vsid << 16);
 }
 
 static void kvmppc_mmu_book3s_32_reset_msr(struct kvm_vcpu *vcpu)
@@ -142,8 +145,13 @@ static int kvmppc_mmu_book3s_32_xlate_bat(struct kvm_vcpu *vcpu, gva_t eaddr,
 				    bat->bepi_mask);
 		}
 		if ((eaddr & bat->bepi_mask) == bat->bepi) {
+			u64 vsid;
+			kvmppc_mmu_book3s_32_esid_to_vsid(vcpu,
+				eaddr >> SID_SHIFT, &vsid);
+			vsid <<= 16;
+			pte->vpage = (((u64)eaddr >> 12) & 0xffff) | vsid;
+
 			pte->raddr = bat->brpn | (eaddr & ~bat->bepi_mask);
-			pte->vpage = (eaddr >> 12) | VSID_BAT;
 			pte->may_read = bat->pp;
 			pte->may_write = bat->pp > 1;
 			pte->may_execute = true;
@@ -302,6 +310,7 @@ static void kvmppc_mmu_book3s_32_mtsrin(struct kvm_vcpu *vcpu, u32 srnum,
 	/* And then put in the new SR */
 	sre->raw = value;
 	sre->vsid = (value & 0x0fffffff);
+	sre->valid = (value & 0x80000000) ? false : true;
 	sre->Ks = (value & 0x40000000) ? true : false;
 	sre->Kp = (value & 0x20000000) ? true : false;
 	sre->nx = (value & 0x10000000) ? true : false;
@@ -312,7 +321,7 @@ static void kvmppc_mmu_book3s_32_mtsrin(struct kvm_vcpu *vcpu, u32 srnum,
 
 static void kvmppc_mmu_book3s_32_tlbie(struct kvm_vcpu *vcpu, ulong ea, bool large)
 {
-	kvmppc_mmu_pte_flush(vcpu, ea, ~0xFFFULL);
+	kvmppc_mmu_pte_flush(vcpu, ea, 0x0FFFF000);
 }
 
 static int kvmppc_mmu_book3s_32_esid_to_vsid(struct kvm_vcpu *vcpu, u64 esid,
@@ -333,15 +342,22 @@ static int kvmppc_mmu_book3s_32_esid_to_vsid(struct kvm_vcpu *vcpu, u64 esid,
 		break;
 	case MSR_DR|MSR_IR:
 	{
-		ulong ea;
-		ea = esid << SID_SHIFT;
-		*vsid = find_sr(to_book3s(vcpu), ea)->vsid;
+		ulong ea = esid << SID_SHIFT;
+		struct kvmppc_sr *sr = find_sr(to_book3s(vcpu), ea);
+
+		if (!sr->valid)
+			return -1;
+
+		*vsid = sr->vsid;
 		break;
 	}
 	default:
 		BUG();
 	}
 
+	if (vcpu->arch.msr & MSR_PR)
+		*vsid |= VSID_PR;
+
 	return 0;
 }
 
-- 
1.6.0.2

[PATCH 05/15] KVM: PPC: Split instruction reading out

[Alexander Graf]

The current check_ext function reads the instruction and then does
the checking. Let's split the reading out so we can reuse it for
different functions.

Signed-off-by: Alexander Graf <agraf-l3A5Bk7waGM@public.gmane.org>
---
 arch/powerpc/kvm/book3s.c |   24 ++++++++++++++++--------
 1 files changed, 16 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 9e0bc47..400ae0a 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -650,26 +650,34 @@ void kvmppc_giveup_ext(struct kvm_vcpu *vcpu, ulong msr)
 	kvmppc_recalc_shadow_msr(vcpu);
 }
 
-static int kvmppc_check_ext(struct kvm_vcpu *vcpu, unsigned int exit_nr)
+static int kvmppc_read_inst(struct kvm_vcpu *vcpu)
 {
 	ulong srr0 = vcpu->arch.pc;
 	int ret;
 
-	/* Need to do paired single emulation? */
-	if (!(vcpu->arch.hflags & BOOK3S_HFLAG_PAIRED_SINGLE))
-		return EMULATE_DONE;
-
-	/* Read out the instruction */
 	ret = kvmppc_ld(vcpu, &srr0, sizeof(u32), &vcpu->arch.last_inst, false);
 	if (ret == -ENOENT) {
 		vcpu->arch.msr = kvmppc_set_field(vcpu->arch.msr, 33, 33, 1);
 		vcpu->arch.msr = kvmppc_set_field(vcpu->arch.msr, 34, 36, 0);
 		vcpu->arch.msr = kvmppc_set_field(vcpu->arch.msr, 42, 47, 0);
 		kvmppc_book3s_queue_irqprio(vcpu, BOOK3S_INTERRUPT_INST_STORAGE);
-	} else if(ret == EMULATE_DONE) {
+		return EMULATE_AGAIN;
+	}
+
+	return EMULATE_DONE;
+}
+
+static int kvmppc_check_ext(struct kvm_vcpu *vcpu, unsigned int exit_nr)
+{
+
+	/* Need to do paired single emulation? */
+	if (!(vcpu->arch.hflags & BOOK3S_HFLAG_PAIRED_SINGLE))
+		return EMULATE_DONE;
+
+	/* Read out the instruction */
+	if (kvmppc_read_inst(vcpu) == EMULATE_DONE)
 		/* Need to emulate */
 		return EMULATE_FAIL;
-	}
 
 	return EMULATE_AGAIN;
 }
-- 
1.6.0.2

[PATCH 06/15] KVM: PPC: Don't reload FPU with invalid values

[Alexander Graf]

When the guest activates the FPU, we load it up. That's fine when
it wasn't activated before on the host, but if it was we end up
reloading FPU values from last time the FPU was deactivated on the
host without writing the proper values back to the vcpu struct.

This patch checks if the FPU is enabled already and if so just doesn't
bother activating it, making FPU operations survive guest context switches.

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

diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 400ae0a..029e1be 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -701,6 +701,11 @@ static int kvmppc_handle_ext(struct kvm_vcpu *vcpu, unsigned int exit_nr,
 		return RESUME_GUEST;
 	}
 
+	/* We already own the ext */
+	if (vcpu->arch.guest_owned_ext & msr) {
+		return RESUME_GUEST;
+	}
+
 #ifdef DEBUG_EXT
 	printk(KERN_INFO "Loading up ext 0x%lx\n", msr);
 #endif
-- 
1.6.0.2

[PATCH 07/15] KVM: PPC: Load VCPU for register fetching

[Alexander Graf]

When trying to read or store vcpu register data, we should also make
sure the vcpu is actually loaded, so we're 100% sure we get the correct
values.

Signed-off-by: Alexander Graf <agraf-l3A5Bk7waGM@public.gmane.org>
---
 arch/powerpc/kvm/book3s.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 029e1be..585dc91 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -955,6 +955,8 @@ int kvm_arch_vcpu_ioctl_get_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
 {
 	int i;
 
+	vcpu_load(vcpu);
+
 	regs->pc = vcpu->arch.pc;
 	regs->cr = kvmppc_get_cr(vcpu);
 	regs->ctr = vcpu->arch.ctr;
@@ -975,6 +977,8 @@ int kvm_arch_vcpu_ioctl_get_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
 	for (i = 0; i < ARRAY_SIZE(regs->gpr); i++)
 		regs->gpr[i] = kvmppc_get_gpr(vcpu, i);
 
+	vcpu_put(vcpu);
+
 	return 0;
 }
 
@@ -982,6 +986,8 @@ int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
 {
 	int i;
 
+	vcpu_load(vcpu);
+
 	vcpu->arch.pc = regs->pc;
 	kvmppc_set_cr(vcpu, regs->cr);
 	vcpu->arch.ctr = regs->ctr;
@@ -1001,6 +1007,8 @@ int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
 	for (i = 0; i < ARRAY_SIZE(regs->gpr); i++)
 		kvmppc_set_gpr(vcpu, i, regs->gpr[i]);
 
+	vcpu_put(vcpu);
+
 	return 0;
 }
 
-- 
1.6.0.2

[PATCH 08/15] KVM: PPC: Implement mfsr emulation

[Alexander Graf]

We emulate the mfsrin instruction already, that passes the SR number
in a register value. But we lacked support for mfsr that encoded the
SR number in the opcode.

So let's implement it.

Signed-off-by: Alexander Graf <agraf-l3A5Bk7waGM@public.gmane.org>
---
 arch/powerpc/kvm/book3s_64_emulate.c |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/kvm/book3s_64_emulate.c b/arch/powerpc/kvm/book3s_64_emulate.c
index c989214..8d7a78d 100644
--- a/arch/powerpc/kvm/book3s_64_emulate.c
+++ b/arch/powerpc/kvm/book3s_64_emulate.c
@@ -35,6 +35,7 @@
 #define OP_31_XOP_SLBMTE	402
 #define OP_31_XOP_SLBIE		434
 #define OP_31_XOP_SLBIA		498
+#define OP_31_XOP_MFSR		595
 #define OP_31_XOP_MFSRIN	659
 #define OP_31_XOP_SLBMFEV	851
 #define OP_31_XOP_EIOIO		854
@@ -90,6 +91,18 @@ int kvmppc_core_emulate_op(struct kvm_run *run, struct kvm_vcpu *vcpu,
 		case OP_31_XOP_MTMSR:
 			kvmppc_set_msr(vcpu, kvmppc_get_gpr(vcpu, get_rs(inst)));
 			break;
+		case OP_31_XOP_MFSR:
+		{
+			int srnum;
+
+			srnum = kvmppc_get_field(inst, 12 + 32, 15 + 32);
+			if (vcpu->arch.mmu.mfsrin) {
+				u32 sr;
+				sr = vcpu->arch.mmu.mfsrin(vcpu, srnum);
+				kvmppc_set_gpr(vcpu, get_rt(inst), sr);
+			}
+			break;
+		}
 		case OP_31_XOP_MFSRIN:
 		{
 			int srnum;
-- 
1.6.0.2

[PATCH 09/15] KVM: PPC: Implement BAT reads

[Alexander Graf]

BATs can't only be written to, you can also read them out!
So let's implement emulation for reading BAT values again.

While at it, I also made BAT setting flush the segment cache,
so we're absolutely sure there's no MMU state left when writing
BATs.

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

diff --git a/arch/powerpc/kvm/book3s_64_emulate.c b/arch/powerpc/kvm/book3s_64_emulate.c
index 8d7a78d..39d5003 100644
--- a/arch/powerpc/kvm/book3s_64_emulate.c
+++ b/arch/powerpc/kvm/book3s_64_emulate.c
@@ -239,6 +239,34 @@ void kvmppc_set_bat(struct kvm_vcpu *vcpu, struct kvmppc_bat *bat, bool upper,
 	}
 }
 
+static u32 kvmppc_read_bat(struct kvm_vcpu *vcpu, int sprn)
+{
+	struct kvmppc_vcpu_book3s *vcpu_book3s = to_book3s(vcpu);
+	struct kvmppc_bat *bat;
+
+	switch (sprn) {
+	case SPRN_IBAT0U ... SPRN_IBAT3L:
+		bat = &vcpu_book3s->ibat[(sprn - SPRN_IBAT0U) / 2];
+		break;
+	case SPRN_IBAT4U ... SPRN_IBAT7L:
+		bat = &vcpu_book3s->ibat[4 + ((sprn - SPRN_IBAT4U) / 2)];
+		break;
+	case SPRN_DBAT0U ... SPRN_DBAT3L:
+		bat = &vcpu_book3s->dbat[(sprn - SPRN_DBAT0U) / 2];
+		break;
+	case SPRN_DBAT4U ... SPRN_DBAT7L:
+		bat = &vcpu_book3s->dbat[4 + ((sprn - SPRN_DBAT4U) / 2)];
+		break;
+	default:
+		BUG();
+	}
+
+	if (sprn % 2)
+		return bat->raw >> 32;
+	else
+		return bat->raw;
+}
+
 static void kvmppc_write_bat(struct kvm_vcpu *vcpu, int sprn, u32 val)
 {
 	struct kvmppc_vcpu_book3s *vcpu_book3s = to_book3s(vcpu);
@@ -290,6 +318,7 @@ int kvmppc_core_emulate_mtspr(struct kvm_vcpu *vcpu, int sprn, int rs)
 		/* BAT writes happen so rarely that we're ok to flush
 		 * everything here */
 		kvmppc_mmu_pte_flush(vcpu, 0, 0);
+		kvmppc_mmu_flush_segments(vcpu);
 		break;
 	case SPRN_HID0:
 		to_book3s(vcpu)->hid[0] = spr_val;
@@ -373,6 +402,12 @@ int kvmppc_core_emulate_mfspr(struct kvm_vcpu *vcpu, int sprn, int rt)
 	int emulated = EMULATE_DONE;
 
 	switch (sprn) {
+	case SPRN_IBAT0U ... SPRN_IBAT3L:
+	case SPRN_IBAT4U ... SPRN_IBAT7L:
+	case SPRN_DBAT0U ... SPRN_DBAT3L:
+	case SPRN_DBAT4U ... SPRN_DBAT7L:
+		kvmppc_set_gpr(vcpu, rt, kvmppc_read_bat(vcpu, sprn));
+		break;
 	case SPRN_SDR1:
 		kvmppc_set_gpr(vcpu, rt, to_book3s(vcpu)->sdr1);
 		break;
-- 
1.6.0.2

[PATCH 10/15] KVM: PPC: Make XER load 32 bit

[Alexander Graf]

We have a 32 bit value in the PACA to store XER in. We also do an stw
when storing XER in there. But then we load it with ld, completely
screwing it up on every entry.

Welcome to the Big Endian world.

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

diff --git a/arch/powerpc/kvm/book3s_64_slb.S b/arch/powerpc/kvm/book3s_64_slb.S
index 35b7627..0919679 100644
--- a/arch/powerpc/kvm/book3s_64_slb.S
+++ b/arch/powerpc/kvm/book3s_64_slb.S
@@ -145,7 +145,7 @@ slb_do_enter:
 	lwz	r11, (PACA_KVM_CR)(r13)
 	mtcr	r11
 
-	ld	r11, (PACA_KVM_XER)(r13)
+	lwz	r11, (PACA_KVM_XER)(r13)
 	mtxer	r11
 
 	ld	r11, (PACA_KVM_R11)(r13)
-- 
1.6.0.2

[PATCH 11/15] KVM: PPC: Implement emulation for lbzux and lhax

[Alexander Graf]

We get MMIOs with the weirdest instructions. But every time we do,
we need to improve our emulator to implement them.

So let's do that - this time it's lbzux and lhax's round.

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

diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
index 2410ec2..dbb5d68 100644
--- a/arch/powerpc/kvm/emulate.c
+++ b/arch/powerpc/kvm/emulate.c
@@ -38,10 +38,12 @@
 #define OP_31_XOP_LBZX      87
 #define OP_31_XOP_STWX      151
 #define OP_31_XOP_STBX      215
+#define OP_31_XOP_LBZUX     119
 #define OP_31_XOP_STBUX     247
 #define OP_31_XOP_LHZX      279
 #define OP_31_XOP_LHZUX     311
 #define OP_31_XOP_MFSPR     339
+#define OP_31_XOP_LHAX      343
 #define OP_31_XOP_STHX      407
 #define OP_31_XOP_STHUX     439
 #define OP_31_XOP_MTSPR     467
@@ -173,6 +175,19 @@ int kvmppc_emulate_instruction(struct kvm_run *run, struct kvm_vcpu *vcpu)
 			emulated = kvmppc_handle_load(run, vcpu, rt, 1, 1);
 			break;
 
+		case OP_31_XOP_LBZUX:
+			rt = get_rt(inst);
+			ra = get_ra(inst);
+			rb = get_rb(inst);
+
+			ea = kvmppc_get_gpr(vcpu, rb);
+			if (ra)
+				ea += kvmppc_get_gpr(vcpu, ra);
+
+			emulated = kvmppc_handle_load(run, vcpu, rt, 1, 1);
+			kvmppc_set_gpr(vcpu, ra, ea);
+			break;
+
 		case OP_31_XOP_STWX:
 			rs = get_rs(inst);
 			emulated = kvmppc_handle_store(run, vcpu,
@@ -202,6 +217,11 @@ int kvmppc_emulate_instruction(struct kvm_run *run, struct kvm_vcpu *vcpu)
 			kvmppc_set_gpr(vcpu, rs, ea);
 			break;
 
+		case OP_31_XOP_LHAX:
+			rt = get_rt(inst);
+			emulated = kvmppc_handle_loads(run, vcpu, rt, 2, 1);
+			break;
+
 		case OP_31_XOP_LHZX:
 			rt = get_rt(inst);
 			emulated = kvmppc_handle_load(run, vcpu, rt, 2, 1);
-- 
1.6.0.2

[PATCH 12/15] KVM: PPC: Implement alignment interrupt

[Alexander Graf]

Mac OS X has some applications - namely the Finder - that require alignment
interrupts to work properly. So we need to implement them.

But the spec for 970 and 750 also looks different. While 750 requires the
DSISR fields to reflect some instruction bits, the 970 declares this as an
optional feature. So we need to reconstruct DSISR manually.

Signed-off-by: Alexander Graf <agraf-l3A5Bk7waGM@public.gmane.org>
---
 arch/powerpc/include/asm/kvm_book3s.h |    1 +
 arch/powerpc/kvm/book3s.c             |    9 +++++++
 arch/powerpc/kvm/book3s_64_emulate.c  |   40 +++++++++++++++++++++++++++++++++
 3 files changed, 50 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/include/asm/kvm_book3s.h b/arch/powerpc/include/asm/kvm_book3s.h
index b47b2f5..1a169f3 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -131,6 +131,7 @@ extern void kvmppc_rmcall(ulong srr0, ulong srr1);
 extern void kvmppc_load_up_fpu(void);
 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);
 
 static inline struct kvmppc_vcpu_book3s *to_book3s(struct kvm_vcpu *vcpu)
 {
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 585dc91..6b8b5ed 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -905,6 +905,15 @@ program_interrupt:
 		}
 		break;
 	}
+	case BOOK3S_INTERRUPT_ALIGNMENT:
+		vcpu->arch.dear = vcpu->arch.fault_dear;
+		if (kvmppc_read_inst(vcpu) == EMULATE_DONE) {
+			to_book3s(vcpu)->dsisr = kvmppc_alignment_dsisr(vcpu,
+				vcpu->arch.last_inst);
+			kvmppc_book3s_queue_irqprio(vcpu, exit_nr);
+		}
+		r = RESUME_GUEST;
+		break;
 	case BOOK3S_INTERRUPT_MACHINE_CHECK:
 	case BOOK3S_INTERRUPT_TRACE:
 		kvmppc_book3s_queue_irqprio(vcpu, exit_nr);
diff --git a/arch/powerpc/kvm/book3s_64_emulate.c b/arch/powerpc/kvm/book3s_64_emulate.c
index 39d5003..c401dd4 100644
--- a/arch/powerpc/kvm/book3s_64_emulate.c
+++ b/arch/powerpc/kvm/book3s_64_emulate.c
@@ -44,6 +44,8 @@
 /* DCBZ is actually 1014, but we patch it to 1010 so we get a trap */
 #define OP_31_XOP_DCBZ		1010
 
+#define OP_LFS			48
+
 #define SPRN_GQR0		912
 #define SPRN_GQR1		913
 #define SPRN_GQR2		914
@@ -474,3 +476,41 @@ int kvmppc_core_emulate_mfspr(struct kvm_vcpu *vcpu, int sprn, int rt)
 	return emulated;
 }
 
+u32 kvmppc_alignment_dsisr(struct kvm_vcpu *vcpu, unsigned int inst)
+{
+	u32 dsisr = 0;
+
+	/*
+	 * This is what the spec says about DSISR bits (not mentioned = 0):
+	 *
+	 * 12:13		[DS]	Set to bits 30:31
+	 * 15:16		[X]	Set to bits 29:30
+	 * 17			[X]	Set to bit 25
+	 *			[D/DS]	Set to bit 5
+	 * 18:21		[X]	Set to bits 21:24
+	 *			[D/DS]	Set to bits 1:4
+	 * 22:26			Set to bits 6:10 (RT/RS/FRT/FRS)
+	 * 27:31			Set to bits 11:15 (RA)
+	 */
+
+	switch (get_op(inst)) {
+	/* D-form */
+	case OP_LFS:
+		dsisr |= (inst >> 12) & 0x4000;	/* bit 17 */
+		dsisr |= (inst >> 17) & 0x3c00; /* bits 18:21 */
+		break;
+	/* X-form */
+	case 31:
+		dsisr |= (inst << 14) & 0x18000; /* bits 15:16 */
+		dsisr |= (inst << 8)  & 0x04000; /* bit 17 */
+		dsisr |= (inst << 3)  & 0x03c00; /* bits 18:21 */
+		break;
+	default:
+		printk(KERN_INFO "KVM: Unaligned instruction 0x%x\n", inst);
+		break;
+	}
+
+	dsisr |= (inst >> 16) & 0x03ff; /* bits 22:31 */
+
+	return dsisr;
+}
-- 
1.6.0.2

[PATCH 13/15] KVM: Add support for enabling capabilities per-vcpu

[Alexander Graf]

Some times we don't want all capabilities to be available to all
our vcpus. One example for that is the OSI interface, implemented
in the next patch.

In order to have a generic mechanism in how to enable capabilities
individually, this patch introduces a new ioctl that can be used
for this purpose. That way features we don't want in all guests or
userspace configurations can just not be enabled and we're good.

Signed-off-by: Alexander Graf <agraf-l3A5Bk7waGM@public.gmane.org>

---

v1 -> v2:

  - Add flags to enable_cap
  - Update documentation for kvm_enable_cap
---
 Documentation/kvm/api.txt  |   15 +++++++++++++++
 arch/powerpc/kvm/powerpc.c |   26 ++++++++++++++++++++++++++
 include/linux/kvm.h        |   11 +++++++++++
 3 files changed, 52 insertions(+), 0 deletions(-)

diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt
index d170cb4..6a19ab6 100644
--- a/Documentation/kvm/api.txt
+++ b/Documentation/kvm/api.txt
@@ -749,6 +749,21 @@ Writes debug registers into the vcpu.
 See KVM_GET_DEBUGREGS for the data structure. The flags field is unused
 yet and must be cleared on entry.
 
+4.34 KVM_ENABLE_CAP
+
+Capability: basic
+Architectures: all
+Type: vcpu ioctl
+Parameters: struct kvm_enable_cap (in)
+Returns: 0 on success; -1 on error
+
+Not all extensions are enabled by default. Using this ioctl the application
+can enable an extension, making it available to the guest.
+
+On systems that do not support this ioctl, it always fails. On systems that
+do support it, it only works for extensions that are supported for enablement.
+As of writing this the only enablement enabled extenion is KVM_CAP_PPC_OSI.
+
 
 5. The kvm_run structure
 
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index a28a512..8bd8204 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -462,6 +462,23 @@ int kvm_vcpu_ioctl_interrupt(struct kvm_vcpu *vcpu, struct kvm_interrupt *irq)
 	return 0;
 }
 
+static int kvm_vcpu_ioctl_enable_cap(struct kvm_vcpu *vcpu,
+				     struct kvm_enable_cap *cap)
+{
+	int r;
+
+	if (cap->flags)
+		return -EINVAL;
+
+	switch (cap->cap) {
+	default:
+		r = -EINVAL;
+		break;
+	}
+
+	return r;
+}
+
 int kvm_arch_vcpu_ioctl_get_mpstate(struct kvm_vcpu *vcpu,
                                     struct kvm_mp_state *mp_state)
 {
@@ -490,6 +507,15 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
 		r = kvm_vcpu_ioctl_interrupt(vcpu, &irq);
 		break;
 	}
+	case KVM_ENABLE_CAP:
+	{
+		struct kvm_enable_cap cap;
+		r = -EFAULT;
+		if (copy_from_user(&cap, argp, sizeof(cap)))
+			goto out;
+		r = kvm_vcpu_ioctl_enable_cap(vcpu, &cap);
+		break;
+	}
 	default:
 		r = -EINVAL;
 	}
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index ce28767..a18ac92 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -400,6 +400,15 @@ struct kvm_ioeventfd {
 	__u8  pad[36];
 };
 
+/* for KVM_ENABLE_CAP */
+struct kvm_enable_cap {
+	/* in */
+	__u32 cap;
+	__u32 flags;
+	__u64 args[4];
+	__u8  pad[64];
+};
+
 #define KVMIO 0xAE
 
 /*
@@ -696,6 +705,8 @@ struct kvm_clock_data {
 /* Available with KVM_CAP_DEBUGREGS */
 #define KVM_GET_DEBUGREGS         _IOR(KVMIO,  0xa1, struct kvm_debugregs)
 #define KVM_SET_DEBUGREGS         _IOW(KVMIO,  0xa2, struct kvm_debugregs)
+/* No need for CAP, because then it just always fails */
+#define KVM_ENABLE_CAP            _IOW(KVMIO,  0xa3, struct kvm_enable_cap)
 
 #define KVM_DEV_ASSIGN_ENABLE_IOMMU	(1 << 0)
 
-- 
1.6.0.2

[PATCH 14/15] KVM: PPC: Add OSI hypercall interface

[Alexander Graf]

MOL uses its own hypercall interface to call back into userspace when
the guest wants to do something.

So let's implement that as an exit reason, specify it with a CAP and
only really use it when userspace wants us to.

The only user of it so far is MOL.

Signed-off-by: Alexander Graf <agraf-l3A5Bk7waGM@public.gmane.org>

---

v1 -> v2:

  - Add documentation for OSI exit struct
---
 Documentation/kvm/api.txt             |   13 +++++++++++++
 arch/powerpc/include/asm/kvm_book3s.h |    5 +++++
 arch/powerpc/include/asm/kvm_host.h   |    2 ++
 arch/powerpc/kvm/book3s.c             |   24 ++++++++++++++++++------
 arch/powerpc/kvm/powerpc.c            |   12 ++++++++++++
 include/linux/kvm.h                   |    6 ++++++
 6 files changed, 56 insertions(+), 6 deletions(-)

diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt
index 6a19ab6..b2129e8 100644
--- a/Documentation/kvm/api.txt
+++ b/Documentation/kvm/api.txt
@@ -932,6 +932,19 @@ s390 specific.
 
 powerpc specific.
 
+		/* KVM_EXIT_OSI */
+		struct {
+			__u64 gprs[32];
+		} osi;
+
+MOL uses a special hypercall interface it calls 'OSI'. To enable it, we catch
+hypercalls and exit with this exit struct that contains all the guest gprs.
+
+If exit_reason is KVM_EXIT_OSI, then the vcpu has triggered such a hypercall.
+Userspace can now handle the hypercall and when it's done modify the gprs as
+necessary. Upon guest entry all guest GPRs will then be replaced by the values
+in this struct.
+
 		/* Fix the size of the union. */
 		char padding[256];
 	};
diff --git a/arch/powerpc/include/asm/kvm_book3s.h b/arch/powerpc/include/asm/kvm_book3s.h
index 1a169f3..54929cd 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -147,6 +147,11 @@ static inline ulong dsisr(void)
 
 extern void kvm_return_point(void);
 
+/* Magic register values loaded into r3 and r4 before the 'sc' assembly
+ * instruction for the OSI hypercalls */
+#define OSI_SC_MAGIC_R3			0x113724FA
+#define OSI_SC_MAGIC_R4			0x77810F9B
+
 #define INS_DCBZ			0x7c0007ec
 
 #endif /* __ASM_KVM_BOOK3S_H__ */
diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
index 0ebda67..486f1ca 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -273,6 +273,8 @@ struct kvm_vcpu_arch {
 	u8 mmio_sign_extend;
 	u8 dcr_needed;
 	u8 dcr_is_write;
+	u8 osi_needed;
+	u8 osi_enabled;
 
 	u32 cpr0_cfgaddr; /* holds the last set cpr0_cfgaddr */
 
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 6b8b5ed..e752a59 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -871,12 +871,24 @@ program_interrupt:
 		break;
 	}
 	case BOOK3S_INTERRUPT_SYSCALL:
-#ifdef EXIT_DEBUG
-		printk(KERN_INFO "Syscall Nr %d\n", (int)kvmppc_get_gpr(vcpu, 0));
-#endif
-		vcpu->stat.syscall_exits++;
-		kvmppc_book3s_queue_irqprio(vcpu, exit_nr);
-		r = RESUME_GUEST;
+		// XXX make user settable
+		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)) {
+			u64 *gprs = run->osi.gprs;
+			int i;
+
+			run->exit_reason = KVM_EXIT_OSI;
+			for (i = 0; i < 32; i++)
+				gprs[i] = kvmppc_get_gpr(vcpu, i);
+			vcpu->arch.osi_needed = 1;
+			r = RESUME_HOST_NV;
+
+		} else {
+			vcpu->stat.syscall_exits++;
+			kvmppc_book3s_queue_irqprio(vcpu, exit_nr);
+			r = RESUME_GUEST;
+		}
 		break;
 	case BOOK3S_INTERRUPT_FP_UNAVAIL:
 	case BOOK3S_INTERRUPT_ALTIVEC:
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 8bd8204..035bad4 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -148,6 +148,7 @@ int kvm_dev_ioctl_check_extension(long ext)
 	switch (ext) {
 	case KVM_CAP_PPC_SEGSTATE:
 	case KVM_CAP_PPC_PAIRED_SINGLES:
+	case KVM_CAP_PPC_OSI:
 		r = 1;
 		break;
 	case KVM_CAP_COALESCED_MMIO:
@@ -429,6 +430,13 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
 		if (!vcpu->arch.dcr_is_write)
 			kvmppc_complete_dcr_load(vcpu, run);
 		vcpu->arch.dcr_needed = 0;
+	} else if (vcpu->arch.osi_needed) {
+		u64 *gprs = run->osi.gprs;
+		int i;
+
+		for (i = 0; i < 32; i++)
+			kvmppc_set_gpr(vcpu, i, gprs[i]);
+		vcpu->arch.osi_needed = 0;
 	}
 
 	kvmppc_core_deliver_interrupts(vcpu);
@@ -471,6 +479,10 @@ static int kvm_vcpu_ioctl_enable_cap(struct kvm_vcpu *vcpu,
 		return -EINVAL;
 
 	switch (cap->cap) {
+	case KVM_CAP_PPC_OSI:
+		r = 0;
+		vcpu->arch.osi_enabled = true;
+		break;
 	default:
 		r = -EINVAL;
 		break;
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index a18ac92..0307961 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -160,6 +160,7 @@ struct kvm_pit_config {
 #define KVM_EXIT_DCR              15
 #define KVM_EXIT_NMI              16
 #define KVM_EXIT_INTERNAL_ERROR   17
+#define KVM_EXIT_OSI              18
 
 /* For KVM_EXIT_INTERNAL_ERROR */
 #define KVM_INTERNAL_ERROR_EMULATION 1
@@ -259,6 +260,10 @@ struct kvm_run {
 			__u32 ndata;
 			__u64 data[16];
 		} internal;
+		/* KVM_EXIT_OSI */
+		struct {
+			__u64 gprs[32];
+		} osi;
 		/* Fix the size of the union. */
 		char padding[256];
 	};
@@ -516,6 +521,7 @@ struct kvm_enable_cap {
 #define KVM_CAP_DEBUGREGS 50
 #endif
 #define KVM_CAP_X86_ROBUST_SINGLESTEP 51
+#define KVM_CAP_PPC_OSI 52
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
-- 
1.6.0.2

[PATCH 15/15] KVM: PPC: Make build work without CONFIG_VSX/ALTIVEC

[Alexander Graf]

The FPU/Altivec/VSX enablement also brought access to some structure
elements that are only defined when the respective config options
are enabled.

Unfortuately I forgot to check for the config options at some places,
so let's do that now.

Unbreaks the build when CONFIG_VSX is not set.

Signed-off-by: Alexander Graf <agraf-l3A5Bk7waGM@public.gmane.org>
---
 arch/powerpc/kvm/book3s.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index e752a59..00e9684 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -608,7 +608,9 @@ void kvmppc_giveup_ext(struct kvm_vcpu *vcpu, ulong msr)
 {
 	struct thread_struct *t = &current->thread;
 	u64 *vcpu_fpr = vcpu->arch.fpr;
+#ifdef CONFIG_VSX
 	u64 *vcpu_vsx = vcpu->arch.vsr;
+#endif
 	u64 *thread_fpr = (u64*)t->fpr;
 	int i;
 
@@ -688,7 +690,9 @@ static int kvmppc_handle_ext(struct kvm_vcpu *vcpu, unsigned int exit_nr,
 {
 	struct thread_struct *t = &current->thread;
 	u64 *vcpu_fpr = vcpu->arch.fpr;
+#ifdef CONFIG_VSX
 	u64 *vcpu_vsx = vcpu->arch.vsr;
+#endif
 	u64 *thread_fpr = (u64*)t->fpr;
 	int i;
 
@@ -1218,8 +1222,12 @@ int __kvmppc_vcpu_run(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu)
 {
 	int ret;
 	struct thread_struct ext_bkp;
+#ifdef CONFIG_ALTIVEC
 	bool save_vec = current->thread.used_vr;
+#endif
+#ifdef CONFIG_VSX
 	bool save_vsx = current->thread.used_vsr;
+#endif
 	ulong ext_msr;
 
 	/* No need to go into the guest when all we do is going out */
-- 
1.6.0.2

Re: [PATCH 00/15] KVM: PPC: MOL bringup patches

[Alexander Graf]

Alexander Graf wrote:
> Mac-on-Linux has always lacked PPC64 host support. This is going to
> change now!
>
> This patchset contains minor patches to enable MOL, but is mostly about
> bug fixes that came out of running Mac OS X. With this set and a pretty
> small patch to MOL I have 10.4.11 running as a guest on a 970MP host.
>
> I'll send the MOl patches to the respective ML in the next days.
>   

The patches for MOL are integrated in their SVN already. Forgot to
change the description.


Alex

Re: [PATCH 02/15] KVM: PPC: Allow userspace to unset the IRQ line

[Avi Kivity]

On 03/08/2010 08:03 PM, Alexander Graf wrote:
> Userspace can tell us that it wants to trigger an interrupt. But
> so far it can't tell us that it wants to stop triggering one.
>
> So let's interpret the parameter to the ioctl that we have anyways
> to tell us if we want to raise or lower the interrupt line.
>    

I asked for a KVM_CAP_ for this.  What was the conclusion of that thread?

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

Re: [PATCH 02/15] KVM: PPC: Allow userspace to unset the IRQ line

[Alexander Graf]

On 09.03.2010, at 13:50, Avi Kivity wrote:

> On 03/08/2010 08:03 PM, Alexander Graf wrote:
>> Userspace can tell us that it wants to trigger an interrupt. But
>> so far it can't tell us that it wants to stop triggering one.
>> 
>> So let's interpret the parameter to the ioctl that we have anyways
>> to tell us if we want to raise or lower the interrupt line.
>>   
> 
> I asked for a KVM_CAP_ for this.  What was the conclusion of that thread?

Uh - did we come to one?

The last thing you said about it was:

> Having individual capabilities makes backporting a lot easier (otherwise you have to backport the whole thing).  If the changes are logically separate, I prefer 500 separate capabilities.
> 
> However, for a platform bringup, it's okay to have just one capability, assuming none of the changes are applicable to other platforms.

So I assumed it'd be ok to not have one. If you like I can send an additional patch adding the CAP.


Alex--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 13/15] KVM: Add support for enabling capabilities per-vcpu

[Avi Kivity]

On 03/08/2010 08:03 PM, Alexander Graf wrote:
> Some times we don't want all capabilities to be available to all
> our vcpus. One example for that is the OSI interface, implemented
> in the next patch.
>
> In order to have a generic mechanism in how to enable capabilities
> individually, this patch introduces a new ioctl that can be used
> for this purpose. That way features we don't want in all guests or
> userspace configurations can just not be enabled and we're good.
>
>
> diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt
> index d170cb4..6a19ab6 100644
> --- a/Documentation/kvm/api.txt
> +++ b/Documentation/kvm/api.txt
> @@ -749,6 +749,21 @@ Writes debug registers into the vcpu.
>   See KVM_GET_DEBUGREGS for the data structure. The flags field is unused
>   yet and must be cleared on entry.
>
> +4.34 KVM_ENABLE_CAP
> +
> +Capability: basic
>    

Capability: basic means that the feature was present in 2.6.22.  
Otherwise you need to specify the KVM_CAP_ that presents this feature.

> +Architectures: all
>
>    

But it's implemented for ppc only (other arches will get ENOTTY).

> +Not all extensions are enabled by default. Using this ioctl the application
> +can enable an extension, making it available to the guest.
> +
> +On systems that do not support this ioctl, it always fails. On systems that
> +do support it, it only works for extensions that are supported for enablement.
> +As of writing this the only enablement enabled extenion is KVM_CAP_PPC_OSI.
>    

That needs to be documented.  It also needs to be discoverable 
separately - we can have a kernel with KVM_ENABLE_CAP but without 
KVM_CAP_PPC_OSI.

btw, KVM_CAP_PPC_OSI conflicts with the KVM_CAP_ namespace.  Please 
choose another namespace.

Need to document the structure fields.

>
>   /*
> @@ -696,6 +705,8 @@ struct kvm_clock_data {
>   /* Available with KVM_CAP_DEBUGREGS */
>   #define KVM_GET_DEBUGREGS         _IOR(KVMIO,  0xa1, struct kvm_debugregs)
>   #define KVM_SET_DEBUGREGS         _IOW(KVMIO,  0xa2, struct kvm_debugregs)
> +/* No need for CAP, because then it just always fails */
> +#define KVM_ENABLE_CAP            _IOW(KVMIO,  0xa3, struct kvm_enable_cap)
>    
The CAPs are needed so you can discover what you have without running guests.



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

Re: [PATCH 14/15] KVM: PPC: Add OSI hypercall interface

[Avi Kivity]

On 03/08/2010 08:03 PM, Alexander Graf wrote:
> MOL uses its own hypercall interface to call back into userspace when
> the guest wants to do something.
>
> So let's implement that as an exit reason, specify it with a CAP and
> only really use it when userspace wants us to.
>
> The only user of it so far is MOL.
>
> Signed-off-by: Alexander Graf<agraf@suse.de>
>
> ---
>
> v1 ->  v2:
>
>    - Add documentation for OSI exit struct
> ---
>   Documentation/kvm/api.txt             |   13 +++++++++++++
>   arch/powerpc/include/asm/kvm_book3s.h |    5 +++++
>   arch/powerpc/include/asm/kvm_host.h   |    2 ++
>   arch/powerpc/kvm/book3s.c             |   24 ++++++++++++++++++------
>   arch/powerpc/kvm/powerpc.c            |   12 ++++++++++++
>   include/linux/kvm.h                   |    6 ++++++
>   6 files changed, 56 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt
> index 6a19ab6..b2129e8 100644
> --- a/Documentation/kvm/api.txt
> +++ b/Documentation/kvm/api.txt
> @@ -932,6 +932,19 @@ s390 specific.
>
>   powerpc specific.
>
> +		/* KVM_EXIT_OSI */
> +		struct {
> +			__u64 gprs[32];
> +		} osi;
> +
> +MOL uses a special hypercall interface it calls 'OSI'. To enable it, we catch
> +hypercalls and exit with this exit struct that contains all the guest gprs.
> +
> +If exit_reason is KVM_EXIT_OSI, then the vcpu has triggered such a hypercall.
> +Userspace can now handle the hypercall and when it's done modify the gprs as
> +necessary. Upon guest entry all guest GPRs will then be replaced by the values
> +in this struct.
> +
>    

That's migration unsafe.  There may not be next guest entry on this host.

Is using KVM_[GS]ET_REGS problematic for some reason?

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

Re: [PATCH 13/15] KVM: Add support for enabling capabilities per-vcpu

[Alexander Graf]

On 09.03.2010, at 13:56, Avi Kivity wrote:

> On 03/08/2010 08:03 PM, Alexander Graf wrote:
>> Some times we don't want all capabilities to be available to all
>> our vcpus. One example for that is the OSI interface, implemented
>> in the next patch.
>> 
>> In order to have a generic mechanism in how to enable capabilities
>> individually, this patch introduces a new ioctl that can be used
>> for this purpose. That way features we don't want in all guests or
>> userspace configurations can just not be enabled and we're good.
>> 
>> 
>> diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt
>> index d170cb4..6a19ab6 100644
>> --- a/Documentation/kvm/api.txt
>> +++ b/Documentation/kvm/api.txt
>> @@ -749,6 +749,21 @@ Writes debug registers into the vcpu.
>>  See KVM_GET_DEBUGREGS for the data structure. The flags field is unused
>>  yet and must be cleared on entry.
>> 
>> +4.34 KVM_ENABLE_CAP
>> +
>> +Capability: basic
>>   
> 
> Capability: basic means that the feature was present in 2.6.22.  Otherwise you need to specify the KVM_CAP_ that presents this feature.
> 
>> +Architectures: all
>> 
>>   
> 
> But it's implemented for ppc only (other arches will get ENOTTY).

That was the whole idea behind it. if it fails it fails. Nothing we can do about it. If it succeeds - great.

> 
>> +Not all extensions are enabled by default. Using this ioctl the application
>> +can enable an extension, making it available to the guest.
>> +
>> +On systems that do not support this ioctl, it always fails. On systems that
>> +do support it, it only works for extensions that are supported for enablement.
>> +As of writing this the only enablement enabled extenion is KVM_CAP_PPC_OSI.
>>   
> 
> That needs to be documented.  It also needs to be discoverable separately - we can have a kernel with KVM_ENABLE_CAP but without KVM_CAP_PPC_OSI.
> 
> btw, KVM_CAP_PPC_OSI conflicts with the KVM_CAP_ namespace.  Please choose another namespace.

Well I figured it'd be slick to have capabilities get enabled or disabled. That's the whole idea behind making it generic. If I wanted a specific interface I'd go in and create an ioctl ENABLE_OSI_INTERFACE.

But this way the detection if a capability exists can be done using the existing CAP detection. It can then be enabled using ENABLE_CAP.

> Need to document the structure fields.
> 
>> 
>>  /*
>> @@ -696,6 +705,8 @@ struct kvm_clock_data {
>>  /* Available with KVM_CAP_DEBUGREGS */
>>  #define KVM_GET_DEBUGREGS         _IOR(KVMIO,  0xa1, struct kvm_debugregs)
>>  #define KVM_SET_DEBUGREGS         _IOW(KVMIO,  0xa2, struct kvm_debugregs)
>> +/* No need for CAP, because then it just always fails */
>> +#define KVM_ENABLE_CAP            _IOW(KVMIO,  0xa3, struct kvm_enable_cap)
>>   
> The CAPs are needed so you can discover what you have without running guests.

The whole point of this extension was to make CAPs not always enabled, but make them possibly enable on demand.


Alex

Re: [PATCH 14/15] KVM: PPC: Add OSI hypercall interface

[Alexander Graf]

On 09.03.2010, at 14:00, Avi Kivity wrote:

> On 03/08/2010 08:03 PM, Alexander Graf wrote:
>> MOL uses its own hypercall interface to call back into userspace when
>> the guest wants to do something.
>> 
>> So let's implement that as an exit reason, specify it with a CAP and
>> only really use it when userspace wants us to.
>> 
>> The only user of it so far is MOL.
>> 
>> Signed-off-by: Alexander Graf<agraf@suse.de>
>> 
>> ---
>> 
>> v1 ->  v2:
>> 
>>   - Add documentation for OSI exit struct
>> ---
>>  Documentation/kvm/api.txt             |   13 +++++++++++++
>>  arch/powerpc/include/asm/kvm_book3s.h |    5 +++++
>>  arch/powerpc/include/asm/kvm_host.h   |    2 ++
>>  arch/powerpc/kvm/book3s.c             |   24 ++++++++++++++++++------
>>  arch/powerpc/kvm/powerpc.c            |   12 ++++++++++++
>>  include/linux/kvm.h                   |    6 ++++++
>>  6 files changed, 56 insertions(+), 6 deletions(-)
>> 
>> diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt
>> index 6a19ab6..b2129e8 100644
>> --- a/Documentation/kvm/api.txt
>> +++ b/Documentation/kvm/api.txt
>> @@ -932,6 +932,19 @@ s390 specific.
>> 
>>  powerpc specific.
>> 
>> +		/* KVM_EXIT_OSI */
>> +		struct {
>> +			__u64 gprs[32];
>> +		} osi;
>> +
>> +MOL uses a special hypercall interface it calls 'OSI'. To enable it, we catch
>> +hypercalls and exit with this exit struct that contains all the guest gprs.
>> +
>> +If exit_reason is KVM_EXIT_OSI, then the vcpu has triggered such a hypercall.
>> +Userspace can now handle the hypercall and when it's done modify the gprs as
>> +necessary. Upon guest entry all guest GPRs will then be replaced by the values
>> +in this struct.
>> +
>>   
> 
> That's migration unsafe.  There may not be next guest entry on this host.

It's as unsafe as MMIO then.

> Is using KVM_[GS]ET_REGS problematic for some reason?

It's two additional ioctls for no good reason. We know the interface, so we can model towards it.


Alex

Re: [PATCH 02/15] KVM: PPC: Allow userspace to unset the IRQ line

[Avi Kivity]

On 03/09/2010 02:54 PM, Alexander Graf wrote:
> On 09.03.2010, at 13:50, Avi Kivity wrote:
>
>    
>> On 03/08/2010 08:03 PM, Alexander Graf wrote:
>>      
>>> Userspace can tell us that it wants to trigger an interrupt. But
>>> so far it can't tell us that it wants to stop triggering one.
>>>
>>> So let's interpret the parameter to the ioctl that we have anyways
>>> to tell us if we want to raise or lower the interrupt line.
>>>
>>>        
>> I asked for a KVM_CAP_ for this.  What was the conclusion of that thread?
>>      
> Uh - did we come to one?
>
> The last thing you said about it was:
>
>    
>> Having individual capabilities makes backporting a lot easier (otherwise you have to backport the whole thing).  If the changes are logically separate, I prefer 500 separate capabilities.
>>
>> However, for a platform bringup, it's okay to have just one capability, assuming none of the changes are applicable to other platforms.
>>      
> So I assumed it'd be ok to not have one. If you like I can send an additional patch adding the CAP.
>
>    

Well, what's the capability for this patchset?

Things like "if you have KVM_CAP_OSI you can assume you have 
KVM_INTERRUPT_LOWER" don't work for me.  A platform cap would be called 
KVM_CAP_MOL and explicitly document everything in there.

And it commits you to not deprecating things individually.  Really, 
individual caps are better.

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

Re: [PATCH 13/15] KVM: Add support for enabling capabilities per-vcpu

[Avi Kivity]

On 03/09/2010 03:01 PM, Alexander Graf wrote:
> On 09.03.2010, at 13:56, Avi Kivity wrote:
>
>    
>> On 03/08/2010 08:03 PM, Alexander Graf wrote:
>>      
>>> Some times we don't want all capabilities to be available to all
>>> our vcpus. One example for that is the OSI interface, implemented
>>> in the next patch.
>>>
>>> In order to have a generic mechanism in how to enable capabilities
>>> individually, this patch introduces a new ioctl that can be used
>>> for this purpose. That way features we don't want in all guests or
>>> userspace configurations can just not be enabled and we're good.
>>>
>>>
>>> diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt
>>> index d170cb4..6a19ab6 100644
>>> --- a/Documentation/kvm/api.txt
>>> +++ b/Documentation/kvm/api.txt
>>> @@ -749,6 +749,21 @@ Writes debug registers into the vcpu.
>>>   See KVM_GET_DEBUGREGS for the data structure. The flags field is unused
>>>   yet and must be cleared on entry.
>>>
>>> +4.34 KVM_ENABLE_CAP
>>> +
>>> +Capability: basic
>>>
>>>        
>> Capability: basic means that the feature was present in 2.6.22.  Otherwise you need to specify the KVM_CAP_ that presents this feature.
>>
>>      
>>> +Architectures: all
>>>
>>>
>>>        
>> But it's implemented for ppc only (other arches will get ENOTTY).
>>      
> That was the whole idea behind it. if it fails it fails. Nothing we can do about it. If it succeeds - great.
>    

If KVM_CAP_ENABLE_CAP is present, it means the KVM_ENABLE_CAP ioctl will 
not return ENOTTY (it may return EINVAL if wrong values are present).

ENOTTY means not implemented.  'Architectures: all' means implemented.

>>> +Not all extensions are enabled by default. Using this ioctl the application
>>> +can enable an extension, making it available to the guest.
>>> +
>>> +On systems that do not support this ioctl, it always fails. On systems that
>>> +do support it, it only works for extensions that are supported for enablement.
>>> +As of writing this the only enablement enabled extenion is KVM_CAP_PPC_OSI.
>>>
>>>        
>> That needs to be documented.  It also needs to be discoverable separately - we can have a kernel with KVM_ENABLE_CAP but without KVM_CAP_PPC_OSI.
>>
>> btw, KVM_CAP_PPC_OSI conflicts with the KVM_CAP_ namespace.  Please choose another namespace.
>>      
> Well I figured it'd be slick to have capabilities get enabled or disabled. That's the whole idea behind making it generic. If I wanted a specific interface I'd go in and create an ioctl ENABLE_OSI_INTERFACE.
>    

Ah, I see.  Well, that makes sense.  Please document it.

> But this way the detection if a capability exists can be done using the existing CAP detection. It can then be enabled using ENABLE_CAP.
>    

Okay, I agree.

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

Re: [PATCH 14/15] KVM: PPC: Add OSI hypercall interface

[Avi Kivity]

On 03/09/2010 03:04 PM, Alexander Graf wrote:
>
>>> +		/* KVM_EXIT_OSI */
>>> +		struct {
>>> +			__u64 gprs[32];
>>> +		} osi;
>>> +
>>> +MOL uses a special hypercall interface it calls 'OSI'. To enable it, we catch
>>> +hypercalls and exit with this exit struct that contains all the guest gprs.
>>> +
>>> +If exit_reason is KVM_EXIT_OSI, then the vcpu has triggered such a hypercall.
>>> +Userspace can now handle the hypercall and when it's done modify the gprs as
>>> +necessary. Upon guest entry all guest GPRs will then be replaced by the values
>>> +in this struct.
>>> +
>>>
>>>        
>> That's migration unsafe.  There may not be next guest entry on this host.
>>      
> It's as unsafe as MMIO then.
>
>    

 From api.txt:

> NOTE: For KVM_EXIT_IO and KVM_EXIT_MMIO, the corresponding operations
> are complete (and guest state is consistent) only after userspace has
> re-entered the kernel with KVM_RUN.  The kernel side will first finish
> incomplete operations and then check for pending signals.  Userspace
> can re-enter the guest with an unmasked signal pending to complete
> pending operations.


>> Is using KVM_[GS]ET_REGS problematic for some reason?
>>      
> It's two additional ioctls for no good reason. We know the interface, so we can model towards it.
>    

But we need to be migration safe.  If the interface is not heavily used, 
let's not add complications.

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

Re: [PATCH 14/15] KVM: PPC: Add OSI hypercall interface

[Alexander Graf]

On 09.03.2010, at 14:11, Avi Kivity wrote:

> On 03/09/2010 03:04 PM, Alexander Graf wrote:
>> 
>>>> +		/* KVM_EXIT_OSI */
>>>> +		struct {
>>>> +			__u64 gprs[32];
>>>> +		} osi;
>>>> +
>>>> +MOL uses a special hypercall interface it calls 'OSI'. To enable it, we catch
>>>> +hypercalls and exit with this exit struct that contains all the guest gprs.
>>>> +
>>>> +If exit_reason is KVM_EXIT_OSI, then the vcpu has triggered such a hypercall.
>>>> +Userspace can now handle the hypercall and when it's done modify the gprs as
>>>> +necessary. Upon guest entry all guest GPRs will then be replaced by the values
>>>> +in this struct.
>>>> +
>>>> 
>>>>       
>>> That's migration unsafe.  There may not be next guest entry on this host.
>>>     
>> It's as unsafe as MMIO then.
>> 
>>   
> 
> From api.txt:
> 
>> NOTE: For KVM_EXIT_IO and KVM_EXIT_MMIO, the corresponding operations
>> are complete (and guest state is consistent) only after userspace has
>> re-entered the kernel with KVM_RUN.  The kernel side will first finish
>> incomplete operations and then check for pending signals.  Userspace
>> can re-enter the guest with an unmasked signal pending to complete
>> pending operations.
> 

Alright - so I add KVM_EXIT_OSI there and be good? :)

> 
>>> Is using KVM_[GS]ET_REGS problematic for some reason?
>>>     
>> It's two additional ioctls for no good reason. We know the interface, so we can model towards it.
>>   
> 
> But we need to be migration safe.  If the interface is not heavily used, let's not add complications.

MOL uses OSI calls instead of MMIO. So yes, it is heavily used.


Alex

Re: [PATCH 14/15] KVM: PPC: Add OSI hypercall interface

[Avi Kivity]

On 03/09/2010 03:12 PM, Alexander Graf wrote:
> On 09.03.2010, at 14:11, Avi Kivity wrote:
>
>    
>> On 03/09/2010 03:04 PM, Alexander Graf wrote:
>>      
>>>        
>>>>> +		/* KVM_EXIT_OSI */
>>>>> +		struct {
>>>>> +			__u64 gprs[32];
>>>>> +		} osi;
>>>>> +
>>>>> +MOL uses a special hypercall interface it calls 'OSI'. To enable it, we catch
>>>>> +hypercalls and exit with this exit struct that contains all the guest gprs.
>>>>> +
>>>>> +If exit_reason is KVM_EXIT_OSI, then the vcpu has triggered such a hypercall.
>>>>> +Userspace can now handle the hypercall and when it's done modify the gprs as
>>>>> +necessary. Upon guest entry all guest GPRs will then be replaced by the values
>>>>> +in this struct.
>>>>> +
>>>>>
>>>>>
>>>>>            
>>>> That's migration unsafe.  There may not be next guest entry on this host.
>>>>
>>>>          
>>> It's as unsafe as MMIO then.
>>>
>>>
>>>        
>>  From api.txt:
>>
>>      
>>> NOTE: For KVM_EXIT_IO and KVM_EXIT_MMIO, the corresponding operations
>>> are complete (and guest state is consistent) only after userspace has
>>> re-entered the kernel with KVM_RUN.  The kernel side will first finish
>>> incomplete operations and then check for pending signals.  Userspace
>>> can re-enter the guest with an unmasked signal pending to complete
>>> pending operations.
>>>        
>>      
> Alright - so I add KVM_EXIT_OSI there and be good? :)
>    

Sure, just verify that the note holds for that case too.

>> But we need to be migration safe.  If the interface is not heavily used, let's not add complications.
>>      
> MOL uses OSI calls instead of MMIO. So yes, it is heavily used.
>
>    

Ok.

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

Re: [PATCH 14/15] KVM: PPC: Add OSI hypercall interface

[Alexander Graf]

On 09.03.2010, at 14:19, Avi Kivity wrote:

> On 03/09/2010 03:12 PM, Alexander Graf wrote:
>> On 09.03.2010, at 14:11, Avi Kivity wrote:
>> 
>>   
>>> On 03/09/2010 03:04 PM, Alexander Graf wrote:
>>>     
>>>>       
>>>>>> +		/* KVM_EXIT_OSI */
>>>>>> +		struct {
>>>>>> +			__u64 gprs[32];
>>>>>> +		} osi;
>>>>>> +
>>>>>> +MOL uses a special hypercall interface it calls 'OSI'. To enable it, we catch
>>>>>> +hypercalls and exit with this exit struct that contains all the guest gprs.
>>>>>> +
>>>>>> +If exit_reason is KVM_EXIT_OSI, then the vcpu has triggered such a hypercall.
>>>>>> +Userspace can now handle the hypercall and when it's done modify the gprs as
>>>>>> +necessary. Upon guest entry all guest GPRs will then be replaced by the values
>>>>>> +in this struct.
>>>>>> +
>>>>>> 
>>>>>> 
>>>>>>           
>>>>> That's migration unsafe.  There may not be next guest entry on this host.
>>>>> 
>>>>>         
>>>> It's as unsafe as MMIO then.
>>>> 
>>>> 
>>>>       
>>> From api.txt:
>>> 
>>>     
>>>> NOTE: For KVM_EXIT_IO and KVM_EXIT_MMIO, the corresponding operations
>>>> are complete (and guest state is consistent) only after userspace has
>>>> re-entered the kernel with KVM_RUN.  The kernel side will first finish
>>>> incomplete operations and then check for pending signals.  Userspace
>>>> can re-enter the guest with an unmasked signal pending to complete
>>>> pending operations.
>>>>       
>>>     
>> Alright - so I add KVM_EXIT_OSI there and be good? :)
>>   
> 
> Sure, just verify that the note holds for that case too.

The handling of the hypercall write-back is in the same region as the mmio one. So whatever applies for MMIO entries applies for OSI entries too.

Alex--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html