[PATCH 0 of 5] PowerPC patches for 2.6.27

[PATCH 0 of 5] PowerPC patches for 2.6.27

[Hollis Blanchard]

Hi Avi, can these patches go upstream for 2.6.27? There's a bug fix,
the addition of hardware breakpoint functionality, and three very significant
performance improvements.

By the way, I will be on vacation for a few weeks starting Monday, but
Christian Ehrhardt should be able to take care of any technical issues.

-Hollis

[PATCH 0 of 5] PowerPC patches for 2.6.27

[Hollis Blanchard]

Hi Avi, can these patches go upstream for 2.6.27? There's a bug fix,
the addition of hardware breakpoint functionality, and three very significant
performance improvements.

By the way, I will be on vacation for a few weeks starting Monday, but
Christian Ehrhardt should be able to take care of any technical issues.

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

[PATCH 1 of 5] kvm: ppc: guest breakpoint support

[Hollis Blanchard]

# HG changeset patch
# User Jerone Young <jyoung5@us.ibm.com>
# Date 1217011175 18000
# Node ID 506dc135741a12e86fbdd327293966ebdd26c5f7
# Parent  9db6f60ca91f7d08ce45dcc2d9581681947ef5ce
kvm: ppc: guest breakpoint support


Allow host userspace to program hardware debug registers to set breakpoints
inside guests.

Signed-off-by: Jerone Young <jyoung5@us.ibm.com>
Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>

---
4 files changed, 113 insertions(+), 2 deletions(-)
arch/powerpc/kvm/booke_guest.c      |   15 ++++++
arch/powerpc/kvm/booke_interrupts.S |   11 ++++
arch/powerpc/kvm/powerpc.c          |   84 ++++++++++++++++++++++++++++++++++-
include/asm-powerpc/kvm_host.h      |    5 ++

diff --git a/arch/powerpc/kvm/booke_guest.c b/arch/powerpc/kvm/booke_guest.c
--- a/arch/powerpc/kvm/booke_guest.c
+++ b/arch/powerpc/kvm/booke_guest.c
@@ -410,6 +410,21 @@ int kvmppc_handle_exit(struct kvm_run *r
 		break;
 	}
 
+	case BOOKE_INTERRUPT_DEBUG: {
+		u32 dbsr;
+
+		vcpu->arch.pc = mfspr(SPRN_CSRR0);
+
+		/* clear IAC events in DBSR register */
+		dbsr = mfspr(SPRN_DBSR);
+		dbsr &= DBSR_IAC1 | DBSR_IAC2 | DBSR_IAC3 | DBSR_IAC4;
+		mtspr(SPRN_DBSR, dbsr);
+
+		run->exit_reason = KVM_EXIT_DEBUG;
+		r = RESUME_HOST;
+		break;
+	}
+
 	default:
 		printk(KERN_EMERG "exit_nr %d\n", exit_nr);
 		BUG();
diff --git a/arch/powerpc/kvm/booke_interrupts.S b/arch/powerpc/kvm/booke_interrupts.S
--- a/arch/powerpc/kvm/booke_interrupts.S
+++ b/arch/powerpc/kvm/booke_interrupts.S
@@ -42,7 +42,8 @@
 #define HOST_STACK_LR   (HOST_STACK_SIZE + 4) /* In caller stack frame. */
 
 #define NEED_INST_MASK ((1<<BOOKE_INTERRUPT_PROGRAM) | \
-                        (1<<BOOKE_INTERRUPT_DTLB_MISS))
+                        (1<<BOOKE_INTERRUPT_DTLB_MISS) | \
+                        (1<<BOOKE_INTERRUPT_DEBUG))
 
 #define NEED_DEAR_MASK ((1<<BOOKE_INTERRUPT_DATA_STORAGE) | \
                         (1<<BOOKE_INTERRUPT_DTLB_MISS))
@@ -431,6 +432,14 @@ 1:
 	oris	r3, r3, KVMPPC_MSR_MASK@h
 	ori	r3, r3, KVMPPC_MSR_MASK@l
 	mtsrr1	r3
+
+	/* Clear any debug events which occurred since we disabled MSR[DE].
+	 * XXX This gives us a 3-instruction window in which a breakpoint
+	 * intended for guest context could fire in the host instead. */
+	lis	r3, 0xffff
+	ori	r3, r3, 0xffff
+	mtspr	SPRN_DBSR, r3
+
 	lwz	r3, VCPU_GPR(r3)(r4)
 	lwz	r4, VCPU_GPR(r4)(r4)
 	rfi
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -239,18 +239,100 @@ void kvm_arch_vcpu_uninit(struct kvm_vcp
 {
 }
 
+/* Note: clearing MSR[DE] just means that the debug interrupt will not be
+ * delivered *immediately*. Instead, it simply sets the appropriate DBSR bits.
+ * If those DBSR bits are still set when MSR[DE] is re-enabled, the interrupt
+ * will be delivered as an "imprecise debug event" (which is indicated by
+ * DBSR[IDE].
+ */
+static void kvmppc_disable_debug_interrupts(void)
+{
+	mtmsr(mfmsr() & ~MSR_DE);
+}
+
+static void kvmppc_restore_host_debug_state(struct kvm_vcpu *vcpu)
+{
+	kvmppc_disable_debug_interrupts();
+
+	mtspr(SPRN_IAC1, vcpu->arch.host_iac[0]);
+	mtspr(SPRN_IAC2, vcpu->arch.host_iac[1]);
+	mtspr(SPRN_IAC3, vcpu->arch.host_iac[2]);
+	mtspr(SPRN_IAC4, vcpu->arch.host_iac[3]);
+	mtspr(SPRN_DBCR1, vcpu->arch.host_dbcr1);
+	mtspr(SPRN_DBCR2, vcpu->arch.host_dbcr2);
+	mtspr(SPRN_DBCR0, vcpu->arch.host_dbcr0);
+	mtmsr(vcpu->arch.host_msr);
+}
+
+static void kvmppc_load_guest_debug_registers(struct kvm_vcpu *vcpu)
+{
+	struct kvm_guest_debug *dbg = &vcpu->guest_debug;
+	u32 dbcr0 = 0;
+
+	vcpu->arch.host_msr = mfmsr();
+	kvmppc_disable_debug_interrupts();
+
+	/* Save host debug register state. */
+	vcpu->arch.host_iac[0] = mfspr(SPRN_IAC1);
+	vcpu->arch.host_iac[1] = mfspr(SPRN_IAC2);
+	vcpu->arch.host_iac[2] = mfspr(SPRN_IAC3);
+	vcpu->arch.host_iac[3] = mfspr(SPRN_IAC4);
+	vcpu->arch.host_dbcr0 = mfspr(SPRN_DBCR0);
+	vcpu->arch.host_dbcr1 = mfspr(SPRN_DBCR1);
+	vcpu->arch.host_dbcr2 = mfspr(SPRN_DBCR2);
+
+	/* set registers up for guest */
+
+	if (dbg->bp[0]) {
+		mtspr(SPRN_IAC1, dbg->bp[0]);
+		dbcr0 |= DBCR0_IAC1 | DBCR0_IDM;
+	}
+	if (dbg->bp[1]) {
+		mtspr(SPRN_IAC2, dbg->bp[1]);
+		dbcr0 |= DBCR0_IAC2 | DBCR0_IDM;
+	}
+	if (dbg->bp[2]) {
+		mtspr(SPRN_IAC3, dbg->bp[2]);
+		dbcr0 |= DBCR0_IAC3 | DBCR0_IDM;
+	}
+	if (dbg->bp[3]) {
+		mtspr(SPRN_IAC4, dbg->bp[3]);
+		dbcr0 |= DBCR0_IAC4 | DBCR0_IDM;
+	}
+
+	mtspr(SPRN_DBCR0, dbcr0);
+	mtspr(SPRN_DBCR1, 0);
+	mtspr(SPRN_DBCR2, 0);
+}
+
 void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
 {
+	if (vcpu->guest_debug.enabled)
+		kvmppc_load_guest_debug_registers(vcpu);
 }
 
 void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
 {
+	if (vcpu->guest_debug.enabled)
+		kvmppc_restore_host_debug_state(vcpu);
 }
 
 int kvm_arch_vcpu_ioctl_debug_guest(struct kvm_vcpu *vcpu,
                                     struct kvm_debug_guest *dbg)
 {
-	return -ENOTSUPP;
+	int i;
+
+	vcpu->guest_debug.enabled = dbg->enabled;
+	if (vcpu->guest_debug.enabled) {
+		for (i=0; i < ARRAY_SIZE(vcpu->guest_debug.bp); i++) {
+			if (dbg->breakpoints[i].enabled)
+				vcpu->guest_debug.bp[i] = dbg->breakpoints[i].address;
+			else
+				vcpu->guest_debug.bp[i] = 0;
+		}
+	}
+
+	return 0;
 }
 
 static void kvmppc_complete_dcr_load(struct kvm_vcpu *vcpu,
diff --git a/include/asm-powerpc/kvm_host.h b/include/asm-powerpc/kvm_host.h
--- a/include/asm-powerpc/kvm_host.h
+++ b/include/asm-powerpc/kvm_host.h
@@ -86,6 +86,11 @@ struct kvm_vcpu_arch {
 
 	u32 host_stack;
 	u32 host_pid;
+	u32 host_dbcr0;
+	u32 host_dbcr1;
+	u32 host_dbcr2;
+	u32 host_iac[4];
+	u32 host_msr;
 
 	u64 fpr[32];
 	u32 gpr[32];

[PATCH 1 of 5] kvm: ppc: guest breakpoint support

[Hollis Blanchard]

# HG changeset patch
# User Jerone Young <jyoung5-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
# Date 1217011175 18000
# Node ID 506dc135741a12e86fbdd327293966ebdd26c5f7
# Parent  9db6f60ca91f7d08ce45dcc2d9581681947ef5ce
kvm: ppc: guest breakpoint support


Allow host userspace to program hardware debug registers to set breakpoints
inside guests.

Signed-off-by: Jerone Young <jyoung5-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Hollis Blanchard <hollisb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>

---
4 files changed, 113 insertions(+), 2 deletions(-)
arch/powerpc/kvm/booke_guest.c      |   15 ++++++
arch/powerpc/kvm/booke_interrupts.S |   11 ++++
arch/powerpc/kvm/powerpc.c          |   84 ++++++++++++++++++++++++++++++++++-
include/asm-powerpc/kvm_host.h      |    5 ++

diff --git a/arch/powerpc/kvm/booke_guest.c b/arch/powerpc/kvm/booke_guest.c
--- a/arch/powerpc/kvm/booke_guest.c
+++ b/arch/powerpc/kvm/booke_guest.c
@@ -410,6 +410,21 @@ int kvmppc_handle_exit(struct kvm_run *r
 		break;
 	}
 
+	case BOOKE_INTERRUPT_DEBUG: {
+		u32 dbsr;
+
+		vcpu->arch.pc = mfspr(SPRN_CSRR0);
+
+		/* clear IAC events in DBSR register */
+		dbsr = mfspr(SPRN_DBSR);
+		dbsr &= DBSR_IAC1 | DBSR_IAC2 | DBSR_IAC3 | DBSR_IAC4;
+		mtspr(SPRN_DBSR, dbsr);
+
+		run->exit_reason = KVM_EXIT_DEBUG;
+		r = RESUME_HOST;
+		break;
+	}
+
 	default:
 		printk(KERN_EMERG "exit_nr %d\n", exit_nr);
 		BUG();
diff --git a/arch/powerpc/kvm/booke_interrupts.S b/arch/powerpc/kvm/booke_interrupts.S
--- a/arch/powerpc/kvm/booke_interrupts.S
+++ b/arch/powerpc/kvm/booke_interrupts.S
@@ -42,7 +42,8 @@
 #define HOST_STACK_LR   (HOST_STACK_SIZE + 4) /* In caller stack frame. */
 
 #define NEED_INST_MASK ((1<<BOOKE_INTERRUPT_PROGRAM) | \
-                        (1<<BOOKE_INTERRUPT_DTLB_MISS))
+                        (1<<BOOKE_INTERRUPT_DTLB_MISS) | \
+                        (1<<BOOKE_INTERRUPT_DEBUG))
 
 #define NEED_DEAR_MASK ((1<<BOOKE_INTERRUPT_DATA_STORAGE) | \
                         (1<<BOOKE_INTERRUPT_DTLB_MISS))
@@ -431,6 +432,14 @@ 1:
 	oris	r3, r3, KVMPPC_MSR_MASK@h
 	ori	r3, r3, KVMPPC_MSR_MASK@l
 	mtsrr1	r3
+
+	/* Clear any debug events which occurred since we disabled MSR[DE].
+	 * XXX This gives us a 3-instruction window in which a breakpoint
+	 * intended for guest context could fire in the host instead. */
+	lis	r3, 0xffff
+	ori	r3, r3, 0xffff
+	mtspr	SPRN_DBSR, r3
+
 	lwz	r3, VCPU_GPR(r3)(r4)
 	lwz	r4, VCPU_GPR(r4)(r4)
 	rfi
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -239,18 +239,100 @@ void kvm_arch_vcpu_uninit(struct kvm_vcp
 {
 }
 
+/* Note: clearing MSR[DE] just means that the debug interrupt will not be
+ * delivered *immediately*. Instead, it simply sets the appropriate DBSR bits.
+ * If those DBSR bits are still set when MSR[DE] is re-enabled, the interrupt
+ * will be delivered as an "imprecise debug event" (which is indicated by
+ * DBSR[IDE].
+ */
+static void kvmppc_disable_debug_interrupts(void)
+{
+	mtmsr(mfmsr() & ~MSR_DE);
+}
+
+static void kvmppc_restore_host_debug_state(struct kvm_vcpu *vcpu)
+{
+	kvmppc_disable_debug_interrupts();
+
+	mtspr(SPRN_IAC1, vcpu->arch.host_iac[0]);
+	mtspr(SPRN_IAC2, vcpu->arch.host_iac[1]);
+	mtspr(SPRN_IAC3, vcpu->arch.host_iac[2]);
+	mtspr(SPRN_IAC4, vcpu->arch.host_iac[3]);
+	mtspr(SPRN_DBCR1, vcpu->arch.host_dbcr1);
+	mtspr(SPRN_DBCR2, vcpu->arch.host_dbcr2);
+	mtspr(SPRN_DBCR0, vcpu->arch.host_dbcr0);
+	mtmsr(vcpu->arch.host_msr);
+}
+
+static void kvmppc_load_guest_debug_registers(struct kvm_vcpu *vcpu)
+{
+	struct kvm_guest_debug *dbg = &vcpu->guest_debug;
+	u32 dbcr0 = 0;
+
+	vcpu->arch.host_msr = mfmsr();
+	kvmppc_disable_debug_interrupts();
+
+	/* Save host debug register state. */
+	vcpu->arch.host_iac[0] = mfspr(SPRN_IAC1);
+	vcpu->arch.host_iac[1] = mfspr(SPRN_IAC2);
+	vcpu->arch.host_iac[2] = mfspr(SPRN_IAC3);
+	vcpu->arch.host_iac[3] = mfspr(SPRN_IAC4);
+	vcpu->arch.host_dbcr0 = mfspr(SPRN_DBCR0);
+	vcpu->arch.host_dbcr1 = mfspr(SPRN_DBCR1);
+	vcpu->arch.host_dbcr2 = mfspr(SPRN_DBCR2);
+
+	/* set registers up for guest */
+
+	if (dbg->bp[0]) {
+		mtspr(SPRN_IAC1, dbg->bp[0]);
+		dbcr0 |= DBCR0_IAC1 | DBCR0_IDM;
+	}
+	if (dbg->bp[1]) {
+		mtspr(SPRN_IAC2, dbg->bp[1]);
+		dbcr0 |= DBCR0_IAC2 | DBCR0_IDM;
+	}
+	if (dbg->bp[2]) {
+		mtspr(SPRN_IAC3, dbg->bp[2]);
+		dbcr0 |= DBCR0_IAC3 | DBCR0_IDM;
+	}
+	if (dbg->bp[3]) {
+		mtspr(SPRN_IAC4, dbg->bp[3]);
+		dbcr0 |= DBCR0_IAC4 | DBCR0_IDM;
+	}
+
+	mtspr(SPRN_DBCR0, dbcr0);
+	mtspr(SPRN_DBCR1, 0);
+	mtspr(SPRN_DBCR2, 0);
+}
+
 void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
 {
+	if (vcpu->guest_debug.enabled)
+		kvmppc_load_guest_debug_registers(vcpu);
 }
 
 void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
 {
+	if (vcpu->guest_debug.enabled)
+		kvmppc_restore_host_debug_state(vcpu);
 }
 
 int kvm_arch_vcpu_ioctl_debug_guest(struct kvm_vcpu *vcpu,
                                     struct kvm_debug_guest *dbg)
 {
-	return -ENOTSUPP;
+	int i;
+
+	vcpu->guest_debug.enabled = dbg->enabled;
+	if (vcpu->guest_debug.enabled) {
+		for (i=0; i < ARRAY_SIZE(vcpu->guest_debug.bp); i++) {
+			if (dbg->breakpoints[i].enabled)
+				vcpu->guest_debug.bp[i] = dbg->breakpoints[i].address;
+			else
+				vcpu->guest_debug.bp[i] = 0;
+		}
+	}
+
+	return 0;
 }
 
 static void kvmppc_complete_dcr_load(struct kvm_vcpu *vcpu,
diff --git a/include/asm-powerpc/kvm_host.h b/include/asm-powerpc/kvm_host.h
--- a/include/asm-powerpc/kvm_host.h
+++ b/include/asm-powerpc/kvm_host.h
@@ -86,6 +86,11 @@ struct kvm_vcpu_arch {
 
 	u32 host_stack;
 	u32 host_pid;
+	u32 host_dbcr0;
+	u32 host_dbcr1;
+	u32 host_dbcr2;
+	u32 host_iac[4];
+	u32 host_msr;
 
 	u64 fpr[32];
 	u32 gpr[32];
--
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

[PATCH 2 of 5] kvm: ppc: fix invalidation of large guest pages

# HG changeset patch
# User Liu Yu <yu.liu@freescale.com>
# Date 1217011851 18000
# Node ID 323134066eeafb9e5258b74d05935447ffdf90f1
# Parent  506dc135741a12e86fbdd327293966ebdd26c5f7
kvm: ppc: fix invalidation of large guest pages

When guest invalidates a large tlb map, there may be more than one
corresponding shadow tlb maps that need to be invalidated. Use eaddr and eend
to find these shadow tlb maps.

Signed-off-by: Liu Yu <yu.liu@freescale.com>
Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>

---
3 files changed, 6 insertions(+), 4 deletions(-)
arch/powerpc/kvm/44x_tlb.c    |    5 +++--
arch/powerpc/kvm/emulate.c    |    2 +-
include/asm-powerpc/kvm_ppc.h |    3 ++-

diff --git a/arch/powerpc/kvm/44x_tlb.c b/arch/powerpc/kvm/44x_tlb.c
--- a/arch/powerpc/kvm/44x_tlb.c
+++ b/arch/powerpc/kvm/44x_tlb.c
@@ -182,7 +182,8 @@ void kvmppc_mmu_map(struct kvm_vcpu *vcp
 			handler);
 }
 
-void kvmppc_mmu_invalidate(struct kvm_vcpu *vcpu, u64 eaddr, u64 asid)
+void kvmppc_mmu_invalidate(struct kvm_vcpu *vcpu, gva_t eaddr,
+                           gva_t eend, u32 asid)
 {
 	unsigned int pid = asid & 0xff;
 	int i;
@@ -196,7 +197,7 @@ void kvmppc_mmu_invalidate(struct kvm_vc
 		if (!get_tlb_v(stlbe))
 			continue;
 
-		if (eaddr < get_tlb_eaddr(stlbe))
+		if (eend < get_tlb_eaddr(stlbe))
 			continue;
 
 		if (eaddr > get_tlb_end(stlbe))
diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
--- a/arch/powerpc/kvm/emulate.c
+++ b/arch/powerpc/kvm/emulate.c
@@ -137,7 +137,7 @@ static int kvmppc_emul_tlbwe(struct kvm_
 	if (tlbe->word0 & PPC44x_TLB_VALID) {
 		eaddr = get_tlb_eaddr(tlbe);
 		asid = (tlbe->word0 & PPC44x_TLB_TS) | tlbe->tid;
-		kvmppc_mmu_invalidate(vcpu, eaddr, asid);
+		kvmppc_mmu_invalidate(vcpu, eaddr, get_tlb_end(tlbe), asid);
 	}
 
 	switch (ws) {
diff --git a/include/asm-powerpc/kvm_ppc.h b/include/asm-powerpc/kvm_ppc.h
--- a/include/asm-powerpc/kvm_ppc.h
+++ b/include/asm-powerpc/kvm_ppc.h
@@ -61,7 +61,8 @@ extern int kvmppc_emulate_mmio(struct kv
 
 extern void kvmppc_mmu_map(struct kvm_vcpu *vcpu, u64 gvaddr, gfn_t gfn,
                            u64 asid, u32 flags);
-extern void kvmppc_mmu_invalidate(struct kvm_vcpu *vcpu, u64 eaddr, u64 asid);
+extern void kvmppc_mmu_invalidate(struct kvm_vcpu *vcpu, gva_t eaddr,
+                                  gva_t eend, u32 asid);
 extern void kvmppc_mmu_priv_switch(struct kvm_vcpu *vcpu, int usermode);
 
 extern void kvmppc_check_and_deliver_interrupts(struct kvm_vcpu *vcpu);

[PATCH 2 of 5] kvm: ppc: fix invalidation of large guest pages

[Hollis Blanchard]

# HG changeset patch
# User Liu Yu <yu.liu-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
# Date 1217011851 18000
# Node ID 323134066eeafb9e5258b74d05935447ffdf90f1
# Parent  506dc135741a12e86fbdd327293966ebdd26c5f7
kvm: ppc: fix invalidation of large guest pages

When guest invalidates a large tlb map, there may be more than one
corresponding shadow tlb maps that need to be invalidated. Use eaddr and eend
to find these shadow tlb maps.

Signed-off-by: Liu Yu <yu.liu-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Signed-off-by: Hollis Blanchard <hollisb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>

---
3 files changed, 6 insertions(+), 4 deletions(-)
arch/powerpc/kvm/44x_tlb.c    |    5 +++--
arch/powerpc/kvm/emulate.c    |    2 +-
include/asm-powerpc/kvm_ppc.h |    3 ++-

diff --git a/arch/powerpc/kvm/44x_tlb.c b/arch/powerpc/kvm/44x_tlb.c
--- a/arch/powerpc/kvm/44x_tlb.c
+++ b/arch/powerpc/kvm/44x_tlb.c
@@ -182,7 +182,8 @@ void kvmppc_mmu_map(struct kvm_vcpu *vcp
 			handler);
 }
 
-void kvmppc_mmu_invalidate(struct kvm_vcpu *vcpu, u64 eaddr, u64 asid)
+void kvmppc_mmu_invalidate(struct kvm_vcpu *vcpu, gva_t eaddr,
+                           gva_t eend, u32 asid)
 {
 	unsigned int pid = asid & 0xff;
 	int i;
@@ -196,7 +197,7 @@ void kvmppc_mmu_invalidate(struct kvm_vc
 		if (!get_tlb_v(stlbe))
 			continue;
 
-		if (eaddr < get_tlb_eaddr(stlbe))
+		if (eend < get_tlb_eaddr(stlbe))
 			continue;
 
 		if (eaddr > get_tlb_end(stlbe))
diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
--- a/arch/powerpc/kvm/emulate.c
+++ b/arch/powerpc/kvm/emulate.c
@@ -137,7 +137,7 @@ static int kvmppc_emul_tlbwe(struct kvm_
 	if (tlbe->word0 & PPC44x_TLB_VALID) {
 		eaddr = get_tlb_eaddr(tlbe);
 		asid = (tlbe->word0 & PPC44x_TLB_TS) | tlbe->tid;
-		kvmppc_mmu_invalidate(vcpu, eaddr, asid);
+		kvmppc_mmu_invalidate(vcpu, eaddr, get_tlb_end(tlbe), asid);
 	}
 
 	switch (ws) {
diff --git a/include/asm-powerpc/kvm_ppc.h b/include/asm-powerpc/kvm_ppc.h
--- a/include/asm-powerpc/kvm_ppc.h
+++ b/include/asm-powerpc/kvm_ppc.h
@@ -61,7 +61,8 @@ extern int kvmppc_emulate_mmio(struct kv
 
 extern void kvmppc_mmu_map(struct kvm_vcpu *vcpu, u64 gvaddr, gfn_t gfn,
                            u64 asid, u32 flags);
-extern void kvmppc_mmu_invalidate(struct kvm_vcpu *vcpu, u64 eaddr, u64 asid);
+extern void kvmppc_mmu_invalidate(struct kvm_vcpu *vcpu, gva_t eaddr,
+                                  gva_t eend, u32 asid);
 extern void kvmppc_mmu_priv_switch(struct kvm_vcpu *vcpu, int usermode);
 
 extern void kvmppc_check_and_deliver_interrupts(struct kvm_vcpu *vcpu);
--
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

[PATCH 3 of 5] kvm: ppc: Stop saving host TLB state

[Hollis Blanchard]

# HG changeset patch
# User Hollis Blanchard <hollisb@us.ibm.com>
# Date 1217011851 18000
# Node ID 1971b4293f12f227a61828d536f6e3b106d1a60c
# Parent  323134066eeafb9e5258b74d05935447ffdf90f1
kvm: ppc: Stop saving host TLB state.

We're saving the host TLB state to memory on every exit, but never using it.
Originally I had thought that we'd want to restore host TLB for heavyweight
exits, but that could actually hurt when context switching to an unrelated host
process (i.e. not qemu).

Since this decreases the performance penalty of all exits, this patch improves
guest boot time by about 15%.

Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>

---
3 files changed, 3 insertions(+), 17 deletions(-)
arch/powerpc/kernel/asm-offsets.c   |    1 -
arch/powerpc/kvm/booke_interrupts.S |   17 +++--------------
include/asm-powerpc/kvm_host.h      |    2 --

diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -356,7 +356,6 @@ int main(void)
 
 	DEFINE(VCPU_HOST_STACK, offsetof(struct kvm_vcpu, arch.host_stack));
 	DEFINE(VCPU_HOST_PID, offsetof(struct kvm_vcpu, arch.host_pid));
-	DEFINE(VCPU_HOST_TLB, offsetof(struct kvm_vcpu, arch.host_tlb));
 	DEFINE(VCPU_SHADOW_TLB, offsetof(struct kvm_vcpu, arch.shadow_tlb));
 	DEFINE(VCPU_GPRS, offsetof(struct kvm_vcpu, arch.gpr));
 	DEFINE(VCPU_LR, offsetof(struct kvm_vcpu, arch.lr));
diff --git a/arch/powerpc/kvm/booke_interrupts.S b/arch/powerpc/kvm/booke_interrupts.S
--- a/arch/powerpc/kvm/booke_interrupts.S
+++ b/arch/powerpc/kvm/booke_interrupts.S
@@ -342,26 +342,15 @@ lightweight_exit:
 	andc	r6, r5, r6
 	mtmsr	r6
 
-	/* Save the host's non-pinned TLB mappings, and load the guest mappings
-	 * over them. Leave the host's "pinned" kernel mappings in place. */
-	/* XXX optimization: use generation count to avoid swapping unmodified
-	 * entries. */
+	/* Load the guest mappings, leaving the host's "pinned" kernel mappings
+	 * in place. */
+	/* XXX optimization: load only modified guest entries. */
 	mfspr	r10, SPRN_MMUCR			/* Save host MMUCR. */
 	lis	r8, tlb_44x_hwater@ha
 	lwz	r8, tlb_44x_hwater@l(r8)
-	addi	r3, r4, VCPU_HOST_TLB - 4
 	addi	r9, r4, VCPU_SHADOW_TLB - 4
 	li	r6, 0
 1:
-	/* Save host entry. */
-	tlbre	r7, r6, PPC44x_TLB_PAGEID
-	mfspr	r5, SPRN_MMUCR
-	stwu	r5, 4(r3)
-	stwu	r7, 4(r3)
-	tlbre	r7, r6, PPC44x_TLB_XLAT
-	stwu	r7, 4(r3)
-	tlbre	r7, r6, PPC44x_TLB_ATTRIB
-	stwu	r7, 4(r3)
 	/* Load guest entry. */
 	lwzu	r7, 4(r9)
 	mtspr	SPRN_MMUCR, r7
diff --git a/include/asm-powerpc/kvm_host.h b/include/asm-powerpc/kvm_host.h
--- a/include/asm-powerpc/kvm_host.h
+++ b/include/asm-powerpc/kvm_host.h
@@ -81,8 +81,6 @@ struct kvm_vcpu_arch {
 	struct tlbe shadow_tlb[PPC44x_TLB_SIZE];
 	/* Pages which are referenced in the shadow TLB. */
 	struct page *shadow_pages[PPC44x_TLB_SIZE];
-	/* Copy of the host's TLB. */
-	struct tlbe host_tlb[PPC44x_TLB_SIZE];
 
 	u32 host_stack;
 	u32 host_pid;

[PATCH 3 of 5] kvm: ppc: Stop saving host TLB state

[Hollis Blanchard]

# HG changeset patch
# User Hollis Blanchard <hollisb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
# Date 1217011851 18000
# Node ID 1971b4293f12f227a61828d536f6e3b106d1a60c
# Parent  323134066eeafb9e5258b74d05935447ffdf90f1
kvm: ppc: Stop saving host TLB state.

We're saving the host TLB state to memory on every exit, but never using it.
Originally I had thought that we'd want to restore host TLB for heavyweight
exits, but that could actually hurt when context switching to an unrelated host
process (i.e. not qemu).

Since this decreases the performance penalty of all exits, this patch improves
guest boot time by about 15%.

Signed-off-by: Hollis Blanchard <hollisb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>

---
3 files changed, 3 insertions(+), 17 deletions(-)
arch/powerpc/kernel/asm-offsets.c   |    1 -
arch/powerpc/kvm/booke_interrupts.S |   17 +++--------------
include/asm-powerpc/kvm_host.h      |    2 --

diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -356,7 +356,6 @@ int main(void)
 
 	DEFINE(VCPU_HOST_STACK, offsetof(struct kvm_vcpu, arch.host_stack));
 	DEFINE(VCPU_HOST_PID, offsetof(struct kvm_vcpu, arch.host_pid));
-	DEFINE(VCPU_HOST_TLB, offsetof(struct kvm_vcpu, arch.host_tlb));
 	DEFINE(VCPU_SHADOW_TLB, offsetof(struct kvm_vcpu, arch.shadow_tlb));
 	DEFINE(VCPU_GPRS, offsetof(struct kvm_vcpu, arch.gpr));
 	DEFINE(VCPU_LR, offsetof(struct kvm_vcpu, arch.lr));
diff --git a/arch/powerpc/kvm/booke_interrupts.S b/arch/powerpc/kvm/booke_interrupts.S
--- a/arch/powerpc/kvm/booke_interrupts.S
+++ b/arch/powerpc/kvm/booke_interrupts.S
@@ -342,26 +342,15 @@ lightweight_exit:
 	andc	r6, r5, r6
 	mtmsr	r6
 
-	/* Save the host's non-pinned TLB mappings, and load the guest mappings
-	 * over them. Leave the host's "pinned" kernel mappings in place. */
-	/* XXX optimization: use generation count to avoid swapping unmodified
-	 * entries. */
+	/* Load the guest mappings, leaving the host's "pinned" kernel mappings
+	 * in place. */
+	/* XXX optimization: load only modified guest entries. */
 	mfspr	r10, SPRN_MMUCR			/* Save host MMUCR. */
 	lis	r8, tlb_44x_hwater@ha
 	lwz	r8, tlb_44x_hwater@l(r8)
-	addi	r3, r4, VCPU_HOST_TLB - 4
 	addi	r9, r4, VCPU_SHADOW_TLB - 4
 	li	r6, 0
 1:
-	/* Save host entry. */
-	tlbre	r7, r6, PPC44x_TLB_PAGEID
-	mfspr	r5, SPRN_MMUCR
-	stwu	r5, 4(r3)
-	stwu	r7, 4(r3)
-	tlbre	r7, r6, PPC44x_TLB_XLAT
-	stwu	r7, 4(r3)
-	tlbre	r7, r6, PPC44x_TLB_ATTRIB
-	stwu	r7, 4(r3)
 	/* Load guest entry. */
 	lwzu	r7, 4(r9)
 	mtspr	SPRN_MMUCR, r7
diff --git a/include/asm-powerpc/kvm_host.h b/include/asm-powerpc/kvm_host.h
--- a/include/asm-powerpc/kvm_host.h
+++ b/include/asm-powerpc/kvm_host.h
@@ -81,8 +81,6 @@ struct kvm_vcpu_arch {
 	struct tlbe shadow_tlb[PPC44x_TLB_SIZE];
 	/* Pages which are referenced in the shadow TLB. */
 	struct page *shadow_pages[PPC44x_TLB_SIZE];
-	/* Copy of the host's TLB. */
-	struct tlbe host_tlb[PPC44x_TLB_SIZE];
 
 	u32 host_stack;
 	u32 host_pid;
--
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

[PATCH 4 of 5] kvm: ppc: Write only modified shadow entries into the

[Hollis Blanchard]

# HG changeset patch
# User Hollis Blanchard <hollisb@us.ibm.com>
# Date 1217011852 18000
# Node ID c832dfc7a6b50ace3c37d00b16ef9f5b46284b3e
# Parent  1971b4293f12f227a61828d536f6e3b106d1a60c
kvm: ppc: Write only modified shadow entries into the TLB on exit

Track which TLB entries need to be written, instead of overwriting everything
below the high water mark. Typically only a single guest TLB entry will be
modified in a single exit.

Guest boot time performance improvement: about 15%.

Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>

---
6 files changed, 66 insertions(+), 20 deletions(-)
arch/powerpc/kernel/asm-offsets.c   |    1 
arch/powerpc/kvm/44x_tlb.c          |    9 +++++
arch/powerpc/kvm/booke_interrupts.S |   55 ++++++++++++++++++++++-------------
arch/powerpc/kvm/powerpc.c          |   15 +++++++++
include/asm-powerpc/kvm_host.h      |    3 +
include/asm-powerpc/kvm_ppc.h       |    3 +

diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -357,6 +357,7 @@ int main(void)
 	DEFINE(VCPU_HOST_STACK, offsetof(struct kvm_vcpu, arch.host_stack));
 	DEFINE(VCPU_HOST_PID, offsetof(struct kvm_vcpu, arch.host_pid));
 	DEFINE(VCPU_SHADOW_TLB, offsetof(struct kvm_vcpu, arch.shadow_tlb));
+	DEFINE(VCPU_SHADOW_MOD, offsetof(struct kvm_vcpu, arch.shadow_tlb_mod));
 	DEFINE(VCPU_GPRS, offsetof(struct kvm_vcpu, arch.gpr));
 	DEFINE(VCPU_LR, offsetof(struct kvm_vcpu, arch.lr));
 	DEFINE(VCPU_CR, offsetof(struct kvm_vcpu, arch.cr));
diff --git a/arch/powerpc/kvm/44x_tlb.c b/arch/powerpc/kvm/44x_tlb.c
--- a/arch/powerpc/kvm/44x_tlb.c
+++ b/arch/powerpc/kvm/44x_tlb.c
@@ -125,6 +125,11 @@ static void kvmppc_44x_shadow_release(st
 	}
 }
 
+void kvmppc_tlbe_set_modified(struct kvm_vcpu *vcpu, unsigned int i)
+{
+    vcpu->arch.shadow_tlb_mod[i] = 1;
+}
+
 /* Caller must ensure that the specified guest TLB entry is safe to insert into
  * the shadow TLB. */
 void kvmppc_mmu_map(struct kvm_vcpu *vcpu, u64 gvaddr, gfn_t gfn, u64 asid,
@@ -172,10 +177,10 @@ void kvmppc_mmu_map(struct kvm_vcpu *vcp
 	 * use host large pages in the future. */
 	stlbe->word0 = (gvaddr & PAGE_MASK) | PPC44x_TLB_VALID | PPC44x_TLB_TS
 	               | PPC44x_TLB_4K;
-
 	stlbe->word1 = (hpaddr & 0xfffffc00) | ((hpaddr >> 32) & 0xf);
 	stlbe->word2 = kvmppc_44x_tlb_shadow_attrib(flags,
 	                                            vcpu->arch.msr & MSR_PR);
+	kvmppc_tlbe_set_modified(vcpu, victim);
 
 	KVMTRACE_5D(STLB_WRITE, vcpu, victim,
 			stlbe->tid, stlbe->word0, stlbe->word1, stlbe->word2,
@@ -209,6 +214,7 @@ void kvmppc_mmu_invalidate(struct kvm_vc
 
 		kvmppc_44x_shadow_release(vcpu, i);
 		stlbe->word0 = 0;
+		kvmppc_tlbe_set_modified(vcpu, i);
 		KVMTRACE_5D(STLB_INVAL, vcpu, i,
 				stlbe->tid, stlbe->word0, stlbe->word1,
 				stlbe->word2, handler);
@@ -229,6 +235,7 @@ void kvmppc_mmu_priv_switch(struct kvm_v
 
 		kvmppc_44x_shadow_release(vcpu, i);
 		stlbe->word0 = 0;
+		kvmppc_tlbe_set_modified(vcpu, i);
 		KVMTRACE_5D(STLB_INVAL, vcpu, i,
 				stlbe->tid, stlbe->word0, stlbe->word1,
 				stlbe->word2, handler);
diff --git a/arch/powerpc/kvm/booke_interrupts.S b/arch/powerpc/kvm/booke_interrupts.S
--- a/arch/powerpc/kvm/booke_interrupts.S
+++ b/arch/powerpc/kvm/booke_interrupts.S
@@ -335,7 +335,7 @@ lightweight_exit:
 	lwz	r3, VCPU_PID(r4)
 	mtspr	SPRN_PID, r3
 
-	/* Prevent all TLB updates. */
+	/* Prevent all asynchronous TLB updates. */
 	mfmsr	r5
 	lis	r6, (MSR_EE|MSR_CE|MSR_ME|MSR_DE)@h
 	ori	r6, r6, (MSR_EE|MSR_CE|MSR_ME|MSR_DE)@l
@@ -344,27 +344,44 @@ lightweight_exit:
 
 	/* Load the guest mappings, leaving the host's "pinned" kernel mappings
 	 * in place. */
-	/* XXX optimization: load only modified guest entries. */
 	mfspr	r10, SPRN_MMUCR			/* Save host MMUCR. */
-	lis	r8, tlb_44x_hwater@ha
-	lwz	r8, tlb_44x_hwater@l(r8)
-	addi	r9, r4, VCPU_SHADOW_TLB - 4
+	li	r5, PPC44x_TLB_SIZE
+	lis	r5, tlb_44x_hwater@ha
+	lwz	r5, tlb_44x_hwater@l(r5)
+	mtctr	r5
+	addi	r9, r4, VCPU_SHADOW_TLB
+	addi	r5, r4, VCPU_SHADOW_MOD
+	li	r3, 0
+1:
+	lbzx	r7, r3, r5
+	cmpwi	r7, 0
+	beq	3f
+
+	/* Load guest entry. */
+	mulli	r11, r3, TLBE_BYTES
+	add	r11, r11, r9
+	lwz	r7, 0(r11)
+	mtspr	SPRN_MMUCR, r7
+	lwz	r7, 4(r11)
+	tlbwe	r7, r3, PPC44x_TLB_PAGEID
+	lwz	r7, 8(r11)
+	tlbwe	r7, r3, PPC44x_TLB_XLAT
+	lwz	r7, 12(r11)
+	tlbwe	r7, r3, PPC44x_TLB_ATTRIB
+3:
+	addi	r3, r3, 1                       /* Increment index. */
+	bdnz	1b
+
+	mtspr	SPRN_MMUCR, r10			/* Restore host MMUCR. */
+
+	/* Clear bitmap of modified TLB entries */
+	li	r5, PPC44x_TLB_SIZE>>2
+	mtctr	r5
+	addi	r5, r4, VCPU_SHADOW_MOD - 4
 	li	r6, 0
 1:
-	/* Load guest entry. */
-	lwzu	r7, 4(r9)
-	mtspr	SPRN_MMUCR, r7
-	lwzu	r7, 4(r9)
-	tlbwe	r7, r6, PPC44x_TLB_PAGEID
-	lwzu	r7, 4(r9)
-	tlbwe	r7, r6, PPC44x_TLB_XLAT
-	lwzu	r7, 4(r9)
-	tlbwe	r7, r6, PPC44x_TLB_ATTRIB
-	/* Increment index. */
-	addi	r6, r6, 1
-	cmpw	r6, r8
-	blt	1b
-	mtspr	SPRN_MMUCR, r10			/* Restore host MMUCR. */
+	stwu	r6, 4(r5)
+	bdnz	1b
 
 	iccci	0, 0 /* XXX hack */
 
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -27,6 +27,7 @@
 #include <asm/cputable.h>
 #include <asm/uaccess.h>
 #include <asm/kvm_ppc.h>
+#include <asm/tlbflush.h>
 
 
 gfn_t unalias_gfn(struct kvm *kvm, gfn_t gfn)
@@ -307,14 +308,28 @@ static void kvmppc_load_guest_debug_regi
 
 void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
 {
+	int i;
+
 	if (vcpu->guest_debug.enabled)
 		kvmppc_load_guest_debug_registers(vcpu);
+
+	/* Mark every guest entry in the shadow TLB entry modified, so that they
+	 * will all be reloaded on the next vcpu run (instead of being
+	 * demand-faulted). */
+	for (i = 0; i <= tlb_44x_hwater; i++)
+		kvmppc_tlbe_set_modified(vcpu, i);
 }
 
 void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
 {
 	if (vcpu->guest_debug.enabled)
 		kvmppc_restore_host_debug_state(vcpu);
+
+	/* Don't leave guest TLB entries resident when being de-scheduled. */
+	/* XXX It would be nice to differentiate between heavyweight exit and
+	 * sched_out here, since we could avoid the TLB flush for heavyweight
+	 * exits. */
+	_tlbia();
 }
 
 int kvm_arch_vcpu_ioctl_debug_guest(struct kvm_vcpu *vcpu,
diff --git a/include/asm-powerpc/kvm_host.h b/include/asm-powerpc/kvm_host.h
--- a/include/asm-powerpc/kvm_host.h
+++ b/include/asm-powerpc/kvm_host.h
@@ -82,6 +82,9 @@ struct kvm_vcpu_arch {
 	/* Pages which are referenced in the shadow TLB. */
 	struct page *shadow_pages[PPC44x_TLB_SIZE];
 
+	/* Track which TLB entries we've modified in the current exit. */
+	u8 shadow_tlb_mod[PPC44x_TLB_SIZE];
+
 	u32 host_stack;
 	u32 host_pid;
 	u32 host_dbcr0;
diff --git a/include/asm-powerpc/kvm_ppc.h b/include/asm-powerpc/kvm_ppc.h
--- a/include/asm-powerpc/kvm_ppc.h
+++ b/include/asm-powerpc/kvm_ppc.h
@@ -65,6 +65,9 @@ extern void kvmppc_mmu_invalidate(struct
                                   gva_t eend, u32 asid);
 extern void kvmppc_mmu_priv_switch(struct kvm_vcpu *vcpu, int usermode);
 
+/* XXX Book E specific */
+extern void kvmppc_tlbe_set_modified(struct kvm_vcpu *vcpu, unsigned int i);
+
 extern void kvmppc_check_and_deliver_interrupts(struct kvm_vcpu *vcpu);
 
 static inline void kvmppc_queue_exception(struct kvm_vcpu *vcpu, int exception)

[PATCH 4 of 5] kvm: ppc: Write only modified shadow entries into the TLB on exit

[Hollis Blanchard]

# HG changeset patch
# User Hollis Blanchard <hollisb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
# Date 1217011852 18000
# Node ID c832dfc7a6b50ace3c37d00b16ef9f5b46284b3e
# Parent  1971b4293f12f227a61828d536f6e3b106d1a60c
kvm: ppc: Write only modified shadow entries into the TLB on exit

Track which TLB entries need to be written, instead of overwriting everything
below the high water mark. Typically only a single guest TLB entry will be
modified in a single exit.

Guest boot time performance improvement: about 15%.

Signed-off-by: Hollis Blanchard <hollisb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>

---
6 files changed, 66 insertions(+), 20 deletions(-)
arch/powerpc/kernel/asm-offsets.c   |    1 
arch/powerpc/kvm/44x_tlb.c          |    9 +++++
arch/powerpc/kvm/booke_interrupts.S |   55 ++++++++++++++++++++++-------------
arch/powerpc/kvm/powerpc.c          |   15 +++++++++
include/asm-powerpc/kvm_host.h      |    3 +
include/asm-powerpc/kvm_ppc.h       |    3 +

diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -357,6 +357,7 @@ int main(void)
 	DEFINE(VCPU_HOST_STACK, offsetof(struct kvm_vcpu, arch.host_stack));
 	DEFINE(VCPU_HOST_PID, offsetof(struct kvm_vcpu, arch.host_pid));
 	DEFINE(VCPU_SHADOW_TLB, offsetof(struct kvm_vcpu, arch.shadow_tlb));
+	DEFINE(VCPU_SHADOW_MOD, offsetof(struct kvm_vcpu, arch.shadow_tlb_mod));
 	DEFINE(VCPU_GPRS, offsetof(struct kvm_vcpu, arch.gpr));
 	DEFINE(VCPU_LR, offsetof(struct kvm_vcpu, arch.lr));
 	DEFINE(VCPU_CR, offsetof(struct kvm_vcpu, arch.cr));
diff --git a/arch/powerpc/kvm/44x_tlb.c b/arch/powerpc/kvm/44x_tlb.c
--- a/arch/powerpc/kvm/44x_tlb.c
+++ b/arch/powerpc/kvm/44x_tlb.c
@@ -125,6 +125,11 @@ static void kvmppc_44x_shadow_release(st
 	}
 }
 
+void kvmppc_tlbe_set_modified(struct kvm_vcpu *vcpu, unsigned int i)
+{
+    vcpu->arch.shadow_tlb_mod[i] = 1;
+}
+
 /* Caller must ensure that the specified guest TLB entry is safe to insert into
  * the shadow TLB. */
 void kvmppc_mmu_map(struct kvm_vcpu *vcpu, u64 gvaddr, gfn_t gfn, u64 asid,
@@ -172,10 +177,10 @@ void kvmppc_mmu_map(struct kvm_vcpu *vcp
 	 * use host large pages in the future. */
 	stlbe->word0 = (gvaddr & PAGE_MASK) | PPC44x_TLB_VALID | PPC44x_TLB_TS
 	               | PPC44x_TLB_4K;
-
 	stlbe->word1 = (hpaddr & 0xfffffc00) | ((hpaddr >> 32) & 0xf);
 	stlbe->word2 = kvmppc_44x_tlb_shadow_attrib(flags,
 	                                            vcpu->arch.msr & MSR_PR);
+	kvmppc_tlbe_set_modified(vcpu, victim);
 
 	KVMTRACE_5D(STLB_WRITE, vcpu, victim,
 			stlbe->tid, stlbe->word0, stlbe->word1, stlbe->word2,
@@ -209,6 +214,7 @@ void kvmppc_mmu_invalidate(struct kvm_vc
 
 		kvmppc_44x_shadow_release(vcpu, i);
 		stlbe->word0 = 0;
+		kvmppc_tlbe_set_modified(vcpu, i);
 		KVMTRACE_5D(STLB_INVAL, vcpu, i,
 				stlbe->tid, stlbe->word0, stlbe->word1,
 				stlbe->word2, handler);
@@ -229,6 +235,7 @@ void kvmppc_mmu_priv_switch(struct kvm_v
 
 		kvmppc_44x_shadow_release(vcpu, i);
 		stlbe->word0 = 0;
+		kvmppc_tlbe_set_modified(vcpu, i);
 		KVMTRACE_5D(STLB_INVAL, vcpu, i,
 				stlbe->tid, stlbe->word0, stlbe->word1,
 				stlbe->word2, handler);
diff --git a/arch/powerpc/kvm/booke_interrupts.S b/arch/powerpc/kvm/booke_interrupts.S
--- a/arch/powerpc/kvm/booke_interrupts.S
+++ b/arch/powerpc/kvm/booke_interrupts.S
@@ -335,7 +335,7 @@ lightweight_exit:
 	lwz	r3, VCPU_PID(r4)
 	mtspr	SPRN_PID, r3
 
-	/* Prevent all TLB updates. */
+	/* Prevent all asynchronous TLB updates. */
 	mfmsr	r5
 	lis	r6, (MSR_EE|MSR_CE|MSR_ME|MSR_DE)@h
 	ori	r6, r6, (MSR_EE|MSR_CE|MSR_ME|MSR_DE)@l
@@ -344,27 +344,44 @@ lightweight_exit:
 
 	/* Load the guest mappings, leaving the host's "pinned" kernel mappings
 	 * in place. */
-	/* XXX optimization: load only modified guest entries. */
 	mfspr	r10, SPRN_MMUCR			/* Save host MMUCR. */
-	lis	r8, tlb_44x_hwater@ha
-	lwz	r8, tlb_44x_hwater@l(r8)
-	addi	r9, r4, VCPU_SHADOW_TLB - 4
+	li	r5, PPC44x_TLB_SIZE
+	lis	r5, tlb_44x_hwater@ha
+	lwz	r5, tlb_44x_hwater@l(r5)
+	mtctr	r5
+	addi	r9, r4, VCPU_SHADOW_TLB
+	addi	r5, r4, VCPU_SHADOW_MOD
+	li	r3, 0
+1:
+	lbzx	r7, r3, r5
+	cmpwi	r7, 0
+	beq	3f
+
+	/* Load guest entry. */
+	mulli	r11, r3, TLBE_BYTES
+	add	r11, r11, r9
+	lwz	r7, 0(r11)
+	mtspr	SPRN_MMUCR, r7
+	lwz	r7, 4(r11)
+	tlbwe	r7, r3, PPC44x_TLB_PAGEID
+	lwz	r7, 8(r11)
+	tlbwe	r7, r3, PPC44x_TLB_XLAT
+	lwz	r7, 12(r11)
+	tlbwe	r7, r3, PPC44x_TLB_ATTRIB
+3:
+	addi	r3, r3, 1                       /* Increment index. */
+	bdnz	1b
+
+	mtspr	SPRN_MMUCR, r10			/* Restore host MMUCR. */
+
+	/* Clear bitmap of modified TLB entries */
+	li	r5, PPC44x_TLB_SIZE>>2
+	mtctr	r5
+	addi	r5, r4, VCPU_SHADOW_MOD - 4
 	li	r6, 0
 1:
-	/* Load guest entry. */
-	lwzu	r7, 4(r9)
-	mtspr	SPRN_MMUCR, r7
-	lwzu	r7, 4(r9)
-	tlbwe	r7, r6, PPC44x_TLB_PAGEID
-	lwzu	r7, 4(r9)
-	tlbwe	r7, r6, PPC44x_TLB_XLAT
-	lwzu	r7, 4(r9)
-	tlbwe	r7, r6, PPC44x_TLB_ATTRIB
-	/* Increment index. */
-	addi	r6, r6, 1
-	cmpw	r6, r8
-	blt	1b
-	mtspr	SPRN_MMUCR, r10			/* Restore host MMUCR. */
+	stwu	r6, 4(r5)
+	bdnz	1b
 
 	iccci	0, 0 /* XXX hack */
 
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -27,6 +27,7 @@
 #include <asm/cputable.h>
 #include <asm/uaccess.h>
 #include <asm/kvm_ppc.h>
+#include <asm/tlbflush.h>
 
 
 gfn_t unalias_gfn(struct kvm *kvm, gfn_t gfn)
@@ -307,14 +308,28 @@ static void kvmppc_load_guest_debug_regi
 
 void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
 {
+	int i;
+
 	if (vcpu->guest_debug.enabled)
 		kvmppc_load_guest_debug_registers(vcpu);
+
+	/* Mark every guest entry in the shadow TLB entry modified, so that they
+	 * will all be reloaded on the next vcpu run (instead of being
+	 * demand-faulted). */
+	for (i = 0; i <= tlb_44x_hwater; i++)
+		kvmppc_tlbe_set_modified(vcpu, i);
 }
 
 void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
 {
 	if (vcpu->guest_debug.enabled)
 		kvmppc_restore_host_debug_state(vcpu);
+
+	/* Don't leave guest TLB entries resident when being de-scheduled. */
+	/* XXX It would be nice to differentiate between heavyweight exit and
+	 * sched_out here, since we could avoid the TLB flush for heavyweight
+	 * exits. */
+	_tlbia();
 }
 
 int kvm_arch_vcpu_ioctl_debug_guest(struct kvm_vcpu *vcpu,
diff --git a/include/asm-powerpc/kvm_host.h b/include/asm-powerpc/kvm_host.h
--- a/include/asm-powerpc/kvm_host.h
+++ b/include/asm-powerpc/kvm_host.h
@@ -82,6 +82,9 @@ struct kvm_vcpu_arch {
 	/* Pages which are referenced in the shadow TLB. */
 	struct page *shadow_pages[PPC44x_TLB_SIZE];
 
+	/* Track which TLB entries we've modified in the current exit. */
+	u8 shadow_tlb_mod[PPC44x_TLB_SIZE];
+
 	u32 host_stack;
 	u32 host_pid;
 	u32 host_dbcr0;
diff --git a/include/asm-powerpc/kvm_ppc.h b/include/asm-powerpc/kvm_ppc.h
--- a/include/asm-powerpc/kvm_ppc.h
+++ b/include/asm-powerpc/kvm_ppc.h
@@ -65,6 +65,9 @@ extern void kvmppc_mmu_invalidate(struct
                                   gva_t eend, u32 asid);
 extern void kvmppc_mmu_priv_switch(struct kvm_vcpu *vcpu, int usermode);
 
+/* XXX Book E specific */
+extern void kvmppc_tlbe_set_modified(struct kvm_vcpu *vcpu, unsigned int i);
+
 extern void kvmppc_check_and_deliver_interrupts(struct kvm_vcpu *vcpu);
 
 static inline void kvmppc_queue_exception(struct kvm_vcpu *vcpu, int exception)
--
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 4 of 5] kvm: ppc: Write only modified shadow entries into theTLB on exit

[Liu Yu]

> -----Original Message-----
> From: kvm-ppc-owner@vger.kernel.org 
> [mailto:kvm-ppc-owner@vger.kernel.org] On Behalf Of Hollis Blanchard
> Sent: Saturday, July 26, 2008 2:55 AM
> To: avi@qumranet.com
> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
> Subject: [PATCH 4 of 5] kvm: ppc: Write only modified shadow 
> entries into theTLB on exit
> 
> @@ -229,6 +235,7 @@ void kvmppc_mmu_priv_switch(struct kvm_v
>  
>  		kvmppc_44x_shadow_release(vcpu, i);
>  		stlbe->word0 = 0;
> +		kvmppc_tlbe_set_modified(vcpu, i);
>  		KVMTRACE_5D(STLB_INVAL, vcpu, i,
>  				stlbe->tid, stlbe->word0, stlbe->word1,
>  				stlbe->word2, handler);

Can this place use "_tlbia()" instead?

Re: [PATCH 4 of 5] kvm: ppc: Write only modified shadow entries into

[Christian Ehrhardt]

Liu Yu wrote:
>
>   
>> -----Original Message-----
>> From: kvm-ppc-owner@vger.kernel.org 
>> [mailto:kvm-ppc-owner@vger.kernel.org] On Behalf Of Hollis Blanchard
>> Sent: Saturday, July 26, 2008 2:55 AM
>> To: avi@qumranet.com
>> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
>> Subject: [PATCH 4 of 5] kvm: ppc: Write only modified shadow 
>> entries into theTLB on exit
>>
>> @@ -229,6 +235,7 @@ void kvmppc_mmu_priv_switch(struct kvm_v
>>  
>>  		kvmppc_44x_shadow_release(vcpu, i);
>>  		stlbe->word0 = 0;
>> +		kvmppc_tlbe_set_modified(vcpu, i);
>>  		KVMTRACE_5D(STLB_INVAL, vcpu, i,
>>  				stlbe->tid, stlbe->word0, stlbe->word1,
>>  				stlbe->word2, handler);
>>     
>
> Can this place use "_tlbia()" instead?
>   
Hi Liu,
when we exit&reenter a guest on the lightweight path this patch saves us 
from rebuilding too much of the tlb.
It's just the point of the patch to not invalidate all tlb entries on 
every exit, but keeping as much as possible.
Additionally I'm not even sure if tlbia is available on all cores used.

Am I overlooking something ? - what do you think would be the benefit of 
using _tlbia() here?
Do you mean the loop to clear up to the hwater mark where this patch 
makes changes and not this patch itself?

-- 

Grüsse / regards, 
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization

RE: [PATCH 4 of 5] kvm: ppc: Write only modified shadow entries into theTLB on exit

[Liu Yu]

> -----Original Message-----
> From: Christian Ehrhardt [mailto:ehrhardt@linux.vnet.ibm.com] 
> Sent: Monday, August 11, 2008 4:33 PM
> To: Liu Yu
> Cc: Hollis Blanchard; kvm-ppc@vger.kernel.org
> Subject: Re: [PATCH 4 of 5] kvm: ppc: Write only modified 
> shadow entries into theTLB on exit
> 
> Liu Yu wrote:
> >
> >   
> >> -----Original Message-----
> >> From: kvm-ppc-owner@vger.kernel.org
> >> [mailto:kvm-ppc-owner@vger.kernel.org] On Behalf Of Hollis 
> Blanchard
> >> Sent: Saturday, July 26, 2008 2:55 AM
> >> To: avi@qumranet.com
> >> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
> >> Subject: [PATCH 4 of 5] kvm: ppc: Write only modified 
> shadow entries 
> >> into theTLB on exit
> >>
> >> @@ -229,6 +235,7 @@ void kvmppc_mmu_priv_switch(struct kvm_v
> >>  
> >>  		kvmppc_44x_shadow_release(vcpu, i);
> >>  		stlbe->word0 = 0;
> >> +		kvmppc_tlbe_set_modified(vcpu, i);
> >>  		KVMTRACE_5D(STLB_INVAL, vcpu, i,
> >>  				stlbe->tid, stlbe->word0, stlbe->word1,
> >>  				stlbe->word2, handler);
> >>     
> >
> > Can this place use "_tlbia()" instead?
> >   
> Hi Liu,
> when we exit&reenter a guest on the lightweight path this 
> patch saves us from rebuilding too much of the tlb.
> It's just the point of the patch to not invalidate all tlb 
> entries on every exit, but keeping as much as possible.
> Additionally I'm not even sure if tlbia is available on all 
> cores used.
> 
> Am I overlooking something ? - what do you think would be the 
> benefit of using _tlbia() here?
> Do you mean the loop to clear up to the hwater mark where 
> this patch makes changes and not this patch itself?
> 

Yes.

When you set nearly all tlb entries modified in this loop,
you have to write all of them back before entering the guest in booke_interrupts.S.

So, why not "_tlbia()" here outside this loop, and don't set them modified.
Then, you needn't write them back.
In fact, the shadow tlb entries are still consistent with the hardware, as all of them are invalidated.

Am I overlooking something ?

Re: [PATCH 4 of 5] kvm: ppc: Write only modified shadow entries into

[Christian Ehrhardt]

Liu Yu wrote:
>> -----Original Message-----
>> From: Christian Ehrhardt [mailto:ehrhardt@linux.vnet.ibm.com] 
>> Sent: Monday, August 11, 2008 4:33 PM
>> To: Liu Yu
>> Cc: Hollis Blanchard; kvm-ppc@vger.kernel.org
>> Subject: Re: [PATCH 4 of 5] kvm: ppc: Write only modified 
>> shadow entries into theTLB on exit
>>
>> Liu Yu wrote:
>>     
>>>   
>>>       
>>>> -----Original Message-----
>>>> From: kvm-ppc-owner@vger.kernel.org
>>>> [mailto:kvm-ppc-owner@vger.kernel.org] On Behalf Of Hollis 
>>>>         
>> Blanchard
>>     
>>>> Sent: Saturday, July 26, 2008 2:55 AM
>>>> To: avi@qumranet.com
>>>> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
>>>> Subject: [PATCH 4 of 5] kvm: ppc: Write only modified 
>>>>         
>> shadow entries 
>>     
>>>> into theTLB on exit
>>>>
>>>> @@ -229,6 +235,7 @@ void kvmppc_mmu_priv_switch(struct kvm_v
>>>>  
>>>>  		kvmppc_44x_shadow_release(vcpu, i);
>>>>  		stlbe->word0 = 0;
>>>> +		kvmppc_tlbe_set_modified(vcpu, i);
>>>>  		KVMTRACE_5D(STLB_INVAL, vcpu, i,
>>>>  				stlbe->tid, stlbe->word0, stlbe->word1,
>>>>  				stlbe->word2, handler);
>>>>     
>>>>         
>>> Can this place use "_tlbia()" instead?
>>>   
>>>       
>> Hi Liu,
>> when we exit&reenter a guest on the lightweight path this 
>> patch saves us from rebuilding too much of the tlb.
>> It's just the point of the patch to not invalidate all tlb 
>> entries on every exit, but keeping as much as possible.
>> Additionally I'm not even sure if tlbia is available on all 
>> cores used.
>>
>> Am I overlooking something ? - what do you think would be the 
>> benefit of using _tlbia() here?
>> Do you mean the loop to clear up to the hwater mark where 
>> this patch makes changes and not this patch itself?
>>
>>     
>
> Yes.
>
> When you set nearly all tlb entries modified in this loop,
> you have to write all of them back before entering the guest in booke_interrupts.S.
>
> So, why not "_tlbia()" here outside this loop, and don't set them modified.
> Then, you needn't write them back.
> In fact, the shadow tlb entries are still consistent with the hardware, as all of them are invalidated.
>
> Am I overlooking something ?
>   
As Hollis wrote in his patch comment usually just one tlb entry is 
modified which saves a lot of updates.
If we invalidate all we later on would have to satisfy the misses we 
cause by doing so.

With some free time we could test _tlbia() here, but I expect it to be 
slower by causing the need for tlb re-population compared to what we 
save here.

-- 

Grüsse / regards, 
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization

RE: [PATCH 4 of 5] kvm: ppc: Write only modified shadow entries into theTLB on exit

[Liu Yu]

> -----Original Message-----
> From: Christian Ehrhardt [mailto:ehrhardt@linux.vnet.ibm.com] 
> Sent: Monday, August 11, 2008 7:48 PM
> To: Liu Yu
> Cc: Hollis Blanchard; kvm-ppc@vger.kernel.org
> Subject: Re: [PATCH 4 of 5] kvm: ppc: Write only modified 
> shadow entries into theTLB on exit
> >
> > When you set nearly all tlb entries modified in this loop, 
> you have to 
> > write all of them back before entering the guest in 
> booke_interrupts.S.
> >
> > So, why not "_tlbia()" here outside this loop, and don't 
> set them modified.
> > Then, you needn't write them back.
> > In fact, the shadow tlb entries are still consistent with 
> the hardware, as all of them are invalidated.
> >
> > Am I overlooking something ?
> >   
> As Hollis wrote in his patch comment usually just one tlb 
> entry is modified which saves a lot of updates.
> If we invalidate all we later on would have to satisfy the 
> misses we cause by doing so.

In this loop, aren't you invalidating them all?

> 
> With some free time we could test _tlbia() here, but I expect 
> it to be slower by causing the need for tlb re-population 
> compared to what we save here.
> 

I don't understand why it will be slower.
I think _tlbia will take the same effect as what you do here.
That is to say, it will always cause the need for tlb re-population.
And what's more, _tlbia will save some time when it enter the guest.

Re: [PATCH 4 of 5] kvm: ppc: Write only modified shadow entries into

[Christian Ehrhardt]

Liu Yu wrote:
>> -----Original Message-----
>> From: Christian Ehrhardt [mailto:ehrhardt@linux.vnet.ibm.com] 
>> Sent: Monday, August 11, 2008 7:48 PM
>> To: Liu Yu
>> Cc: Hollis Blanchard; kvm-ppc@vger.kernel.org
>> Subject: Re: [PATCH 4 of 5] kvm: ppc: Write only modified 
>> shadow entries into theTLB on exit
>>     
>>> When you set nearly all tlb entries modified in this loop, 
>>>       
>> you have to 
>>     
>>> write all of them back before entering the guest in 
>>>       
>> booke_interrupts.S.
>>     
>>> So, why not "_tlbia()" here outside this loop, and don't 
>>>       
>> set them modified.
>>     
>>> Then, you needn't write them back.
>>> In fact, the shadow tlb entries are still consistent with 
>>>       
>> the hardware, as all of them are invalidated.
>>     
>>> Am I overlooking something ?
>>>   
>>>       
>> As Hollis wrote in his patch comment usually just one tlb 
>> entry is modified which saves a lot of updates.
>> If we invalidate all we later on would have to satisfy the 
>> misses we cause by doing so.
>>     
>
> In this loop, aren't you invalidating them all?
>
>   
>> With some free time we could test _tlbia() here, but I expect 
>> it to be slower by causing the need for tlb re-population 
>> compared to what we save here.
>>
>>     
>
> I don't understand why it will be slower.
> I think _tlbia will take the same effect as what you do here.
> That is to say, it will always cause the need for tlb re-population.
> And what's more, _tlbia will save some time when it enter the guest.
>
>   
On 440 which this file 440x_tlb.c is for, the implementation of tlbia is 
more or less the same than Hollis code when reentering the guest (there 
is no tlbia instruction on 440) with the addition of a check of the 
shadow modified flag.

I agree with you that the code in the kvmppc_mmu_priv_switch effectively 
releases all tlbe's to the high water mark, marks them modified and 
later on pushes them (being invalid) when entering the guest.
That means that the part of revoking all tlbe's to the high water mark 
can be done with tlbia() instead of using the kvmppc_tlbe_set_modified 
call for all indexes here.

I also agree that this can save us memory accesses from 0 to 
tlb_44x_hwater for the setting of the shadow modified flag, but 
everything else will be the same. Don't get me wrong I usually embrace 
any performance improvement, but when you look in the patched source 
file the is a comment just above the patched section:
   /* Future optimization: clear only userspace mappings. */
Once we do that (or anything similar if we get other ideas here) keeping 
the guest kernel mapping we can't use _tlbia() anymore because it clears 
everyting. That as an example would save us a guest exit which should 
save more time than some memory accesses.

Alltogether thats just my opinion, maybe we both wait for Hollis come 
back from vacation next week and add a third opinion to this discussion 
making decisions easier.


P.S. as I stated above this code is from the 440 tlb implementation, so 
if e.g. there is hardware support for it on some platforms that might 
make that improvement more beneficial we need an abstraction here.

-- 

Grüsse / regards, 
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization

RE: [PATCH 4 of 5] kvm: ppc: Write only modified shadow entries into theTLB on exit

[Liu Yu]

> -----Original Message-----
> From: Christian Ehrhardt [mailto:ehrhardt@linux.vnet.ibm.com] 
> Sent: Tuesday, August 12, 2008 4:04 PM
> To: Liu Yu
> Cc: Hollis Blanchard; kvm-ppc@vger.kernel.org
> Subject: Re: [PATCH 4 of 5] kvm: ppc: Write only modified 
> shadow entries into theTLB on exit
> 
> Liu Yu wrote:
> >> -----Original Message-----
> >> From: Christian Ehrhardt [mailto:ehrhardt@linux.vnet.ibm.com]
> >> Sent: Monday, August 11, 2008 7:48 PM
> >> To: Liu Yu
> >> Cc: Hollis Blanchard; kvm-ppc@vger.kernel.org
> >> Subject: Re: [PATCH 4 of 5] kvm: ppc: Write only modified shadow 
> >> entries into theTLB on exit
> >>     
> >>> When you set nearly all tlb entries modified in this loop,
> >>>       
> >> you have to
> >>     
> >>> write all of them back before entering the guest in
> >>>       
> >> booke_interrupts.S.
> >>     
> >>> So, why not "_tlbia()" here outside this loop, and don't
> >>>       
> >> set them modified.
> >>     
> >>> Then, you needn't write them back.
> >>> In fact, the shadow tlb entries are still consistent with
> >>>       
> >> the hardware, as all of them are invalidated.
> >>     
> >>> Am I overlooking something ?
> >>>   
> >>>       
> >> As Hollis wrote in his patch comment usually just one tlb entry is 
> >> modified which saves a lot of updates.
> >> If we invalidate all we later on would have to satisfy the 
> misses we 
> >> cause by doing so.
> >>     
> >
> > In this loop, aren't you invalidating them all?
> >
> >   
> >> With some free time we could test _tlbia() here, but I 
> expect it to 
> >> be slower by causing the need for tlb re-population 
> compared to what 
> >> we save here.
> >>
> >>     
> >
> > I don't understand why it will be slower.
> > I think _tlbia will take the same effect as what you do here.
> > That is to say, it will always cause the need for tlb re-population.
> > And what's more, _tlbia will save some time when it enter the guest.
> >
> >   
> On 440 which this file 440x_tlb.c is for, the implementation 
> of tlbia is more or less the same than Hollis code when 
> reentering the guest (there is no tlbia instruction on 440) 
> with the addition of a check of the shadow modified flag.

Well, this is a problem. I overlooked it.

> 
> I agree with you that the code in the kvmppc_mmu_priv_switch 
> effectively releases all tlbe's to the high water mark, marks 
> them modified and later on pushes them (being invalid) when 
> entering the guest.
> That means that the part of revoking all tlbe's to the high 
> water mark can be done with tlbia() instead of using the 
> kvmppc_tlbe_set_modified call for all indexes here.
> 
> I also agree that this can save us memory accesses from 0 to 
> tlb_44x_hwater for the setting of the shadow modified flag, 
> but everything else will be the same. Don't get me wrong I 
> usually embrace any performance improvement, but when you 
> look in the patched source file the is a comment just above 
> the patched section:
>    /* Future optimization: clear only userspace mappings. */ 
> Once we do that (or anything similar if we get other ideas 
> here) keeping the guest kernel mapping we can't use _tlbia() 
> anymore because it clears everyting. That as an example would 
> save us a guest exit which should save more time than some 
> memory accesses.

Reasonable.

[PATCH 5 of 5] kvm: powerpc: Map guest userspace with TID=0 mappings

[Hollis Blanchard]

# HG changeset patch
# User Hollis Blanchard <hollisb@us.ibm.com>
# Date 1217011852 18000
# Node ID 080b9c9515a5593babc8cac73687b053d7d3f124
# Parent  c832dfc7a6b50ace3c37d00b16ef9f5b46284b3e
kvm: powerpc: Map guest userspace with TID=0 mappings.

When we use TID=N userspace mappings, we must ensure that kernel mappings have
been destroyed when entering userspace. Using TID=1/TID=0 for kernel/user
mappings and running userspace with PID=0 means that userspace can't access the
kernel mappings, but the kernel can directly access userspace.

The net is that we don't need to flush the TLB on privilege switches, but we do
on guest context switches (which are far more infrequent). Guest boot time
performance improvement: about 30%.

Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>

---
7 files changed, 40 insertions(+), 18 deletions(-)
arch/powerpc/kernel/asm-offsets.c   |    2 -
arch/powerpc/kvm/44x_tlb.c          |   37 ++++++++++++++++++++---------------
arch/powerpc/kvm/booke_guest.c      |    2 +
arch/powerpc/kvm/booke_interrupts.S |    2 -
arch/powerpc/kvm/emulate.c          |    2 -
include/asm-powerpc/kvm_host.h      |    4 +++
include/asm-powerpc/kvm_ppc.h       |    9 ++++++++

diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -369,7 +369,7 @@ int main(void)
 	DEFINE(VCPU_SPRG5, offsetof(struct kvm_vcpu, arch.sprg5));
 	DEFINE(VCPU_SPRG6, offsetof(struct kvm_vcpu, arch.sprg6));
 	DEFINE(VCPU_SPRG7, offsetof(struct kvm_vcpu, arch.sprg7));
-	DEFINE(VCPU_PID, offsetof(struct kvm_vcpu, arch.pid));
+	DEFINE(VCPU_SHADOW_PID, offsetof(struct kvm_vcpu, arch.shadow_pid));
 
 	DEFINE(VCPU_LAST_INST, offsetof(struct kvm_vcpu, arch.last_inst));
 	DEFINE(VCPU_FAULT_DEAR, offsetof(struct kvm_vcpu, arch.fault_dear));
diff --git a/arch/powerpc/kvm/44x_tlb.c b/arch/powerpc/kvm/44x_tlb.c
--- a/arch/powerpc/kvm/44x_tlb.c
+++ b/arch/powerpc/kvm/44x_tlb.c
@@ -170,7 +170,7 @@ void kvmppc_mmu_map(struct kvm_vcpu *vcp
 
 	/* XXX what about AS? */
 
-	stlbe->tid = asid & 0xff;
+	stlbe->tid = !(asid & 0xff);
 
 	/* Force TS=1 for all guest mappings. */
 	/* For now we hardcode 4KB mappings, but it will be important to
@@ -190,7 +190,7 @@ void kvmppc_mmu_invalidate(struct kvm_vc
 void kvmppc_mmu_invalidate(struct kvm_vcpu *vcpu, gva_t eaddr,
                            gva_t eend, u32 asid)
 {
-	unsigned int pid = asid & 0xff;
+	unsigned int pid = !(asid & 0xff);
 	int i;
 
 	/* XXX Replace loop with fancy data structures. */
@@ -222,23 +222,30 @@ void kvmppc_mmu_invalidate(struct kvm_vc
 	up_write(&current->mm->mmap_sem);
 }
 
-/* Invalidate all mappings, so that when they fault back in they will get the
- * proper permission bits. */
+/* Invalidate all mappings on the privilege switch after PID has been changed.
+ * The guest always runs with PID=1, so we must clear the entire TLB when
+ * switching address spaces. */
 void kvmppc_mmu_priv_switch(struct kvm_vcpu *vcpu, int usermode)
 {
 	int i;
 
-	/* XXX Replace loop with fancy data structures. */
-	down_write(&current->mm->mmap_sem);
-	for (i = 0; i <= tlb_44x_hwater; i++) {
-		struct tlbe *stlbe = &vcpu->arch.shadow_tlb[i];
+	if (vcpu->arch.swap_pid) {
+		/* XXX Replace loop with fancy data structures. */
+		down_write(&current->mm->mmap_sem);
+		for (i = 0; i <= tlb_44x_hwater; i++) {
+			struct tlbe *stlbe = &vcpu->arch.shadow_tlb[i];
 
-		kvmppc_44x_shadow_release(vcpu, i);
-		stlbe->word0 = 0;
-		kvmppc_tlbe_set_modified(vcpu, i);
-		KVMTRACE_5D(STLB_INVAL, vcpu, i,
-				stlbe->tid, stlbe->word0, stlbe->word1,
-				stlbe->word2, handler);
+			/* Future optimization: clear only userspace mappings. */
+			kvmppc_44x_shadow_release(vcpu, i);
+			stlbe->word0 = 0;
+			kvmppc_tlbe_set_modified(vcpu, i);
+			KVMTRACE_5D(STLB_INVAL, vcpu, i,
+			            stlbe->tid, stlbe->word0, stlbe->word1,
+			            stlbe->word2, handler);
+		}
+		up_write(&current->mm->mmap_sem);
+		vcpu->arch.swap_pid = 0;
 	}
-	up_write(&current->mm->mmap_sem);
+
+	vcpu->arch.shadow_pid = !usermode;
 }
diff --git a/arch/powerpc/kvm/booke_guest.c b/arch/powerpc/kvm/booke_guest.c
--- a/arch/powerpc/kvm/booke_guest.c
+++ b/arch/powerpc/kvm/booke_guest.c
@@ -486,6 +486,8 @@ int kvm_arch_vcpu_setup(struct kvm_vcpu 
 	vcpu->arch.msr = 0;
 	vcpu->arch.gpr[1] = (16<<20) - 8; /* -8 for the callee-save LR slot */
 
+	vcpu->arch.shadow_pid = 1;
+
 	/* Eye-catching number so we know if the guest takes an interrupt
 	 * before it's programmed its own IVPR. */
 	vcpu->arch.ivpr = 0x55550000;
diff --git a/arch/powerpc/kvm/booke_interrupts.S b/arch/powerpc/kvm/booke_interrupts.S
--- a/arch/powerpc/kvm/booke_interrupts.S
+++ b/arch/powerpc/kvm/booke_interrupts.S
@@ -332,7 +332,7 @@ lightweight_exit:
 
 	mfspr	r3, SPRN_PID
 	stw	r3, VCPU_HOST_PID(r4)
-	lwz	r3, VCPU_PID(r4)
+	lwz	r3, VCPU_SHADOW_PID(r4)
 	mtspr	SPRN_PID, r3
 
 	/* Prevent all asynchronous TLB updates. */
diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
--- a/arch/powerpc/kvm/emulate.c
+++ b/arch/powerpc/kvm/emulate.c
@@ -508,7 +508,7 @@ int kvmppc_emulate_instruction(struct kv
 			case SPRN_MMUCR:
 				vcpu->arch.mmucr = vcpu->arch.gpr[rs]; break;
 			case SPRN_PID:
-				vcpu->arch.pid = vcpu->arch.gpr[rs]; break;
+				kvmppc_set_pid(vcpu, vcpu->arch.gpr[rs]); break;
 			case SPRN_CCR0:
 				vcpu->arch.ccr0 = vcpu->arch.gpr[rs]; break;
 			case SPRN_CCR1:
diff --git a/include/asm-powerpc/kvm_host.h b/include/asm-powerpc/kvm_host.h
--- a/include/asm-powerpc/kvm_host.h
+++ b/include/asm-powerpc/kvm_host.h
@@ -129,7 +129,11 @@ struct kvm_vcpu_arch {
 	u32 ivor[16];
 	u32 ivpr;
 	u32 pir;
+
+	u32 shadow_pid;
 	u32 pid;
+	u32 swap_pid;
+
 	u32 pvr;
 	u32 ccr0;
 	u32 ccr1;
diff --git a/include/asm-powerpc/kvm_ppc.h b/include/asm-powerpc/kvm_ppc.h
--- a/include/asm-powerpc/kvm_ppc.h
+++ b/include/asm-powerpc/kvm_ppc.h
@@ -64,6 +64,7 @@ extern void kvmppc_mmu_invalidate(struct
 extern void kvmppc_mmu_invalidate(struct kvm_vcpu *vcpu, gva_t eaddr,
                                   gva_t eend, u32 asid);
 extern void kvmppc_mmu_priv_switch(struct kvm_vcpu *vcpu, int usermode);
+extern void kvmppc_mmu_switch_pid(struct kvm_vcpu *vcpu, u32 pid);
 
 /* XXX Book E specific */
 extern void kvmppc_tlbe_set_modified(struct kvm_vcpu *vcpu, unsigned int i);
@@ -95,4 +96,12 @@ static inline void kvmppc_set_msr(struct
 		kvm_vcpu_block(vcpu);
 }
 
+static inline void kvmppc_set_pid(struct kvm_vcpu *vcpu, u32 new_pid)
+{
+	if (vcpu->arch.pid != new_pid) {
+		vcpu->arch.pid = new_pid;
+		vcpu->arch.swap_pid = 1;
+	}
+}
+
 #endif /* __POWERPC_KVM_PPC_H__ */

[PATCH 5 of 5] kvm: powerpc: Map guest userspace with TID=0 mappings

[Hollis Blanchard]

# HG changeset patch
# User Hollis Blanchard <hollisb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
# Date 1217011852 18000
# Node ID 080b9c9515a5593babc8cac73687b053d7d3f124
# Parent  c832dfc7a6b50ace3c37d00b16ef9f5b46284b3e
kvm: powerpc: Map guest userspace with TID=0 mappings.

When we use TID=N userspace mappings, we must ensure that kernel mappings have
been destroyed when entering userspace. Using TID=1/TID=0 for kernel/user
mappings and running userspace with PID=0 means that userspace can't access the
kernel mappings, but the kernel can directly access userspace.

The net is that we don't need to flush the TLB on privilege switches, but we do
on guest context switches (which are far more infrequent). Guest boot time
performance improvement: about 30%.

Signed-off-by: Hollis Blanchard <hollisb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>

---
7 files changed, 40 insertions(+), 18 deletions(-)
arch/powerpc/kernel/asm-offsets.c   |    2 -
arch/powerpc/kvm/44x_tlb.c          |   37 ++++++++++++++++++++---------------
arch/powerpc/kvm/booke_guest.c      |    2 +
arch/powerpc/kvm/booke_interrupts.S |    2 -
arch/powerpc/kvm/emulate.c          |    2 -
include/asm-powerpc/kvm_host.h      |    4 +++
include/asm-powerpc/kvm_ppc.h       |    9 ++++++++

diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -369,7 +369,7 @@ int main(void)
 	DEFINE(VCPU_SPRG5, offsetof(struct kvm_vcpu, arch.sprg5));
 	DEFINE(VCPU_SPRG6, offsetof(struct kvm_vcpu, arch.sprg6));
 	DEFINE(VCPU_SPRG7, offsetof(struct kvm_vcpu, arch.sprg7));
-	DEFINE(VCPU_PID, offsetof(struct kvm_vcpu, arch.pid));
+	DEFINE(VCPU_SHADOW_PID, offsetof(struct kvm_vcpu, arch.shadow_pid));
 
 	DEFINE(VCPU_LAST_INST, offsetof(struct kvm_vcpu, arch.last_inst));
 	DEFINE(VCPU_FAULT_DEAR, offsetof(struct kvm_vcpu, arch.fault_dear));
diff --git a/arch/powerpc/kvm/44x_tlb.c b/arch/powerpc/kvm/44x_tlb.c
--- a/arch/powerpc/kvm/44x_tlb.c
+++ b/arch/powerpc/kvm/44x_tlb.c
@@ -170,7 +170,7 @@ void kvmppc_mmu_map(struct kvm_vcpu *vcp
 
 	/* XXX what about AS? */
 
-	stlbe->tid = asid & 0xff;
+	stlbe->tid = !(asid & 0xff);
 
 	/* Force TS=1 for all guest mappings. */
 	/* For now we hardcode 4KB mappings, but it will be important to
@@ -190,7 +190,7 @@ void kvmppc_mmu_invalidate(struct kvm_vc
 void kvmppc_mmu_invalidate(struct kvm_vcpu *vcpu, gva_t eaddr,
                            gva_t eend, u32 asid)
 {
-	unsigned int pid = asid & 0xff;
+	unsigned int pid = !(asid & 0xff);
 	int i;
 
 	/* XXX Replace loop with fancy data structures. */
@@ -222,23 +222,30 @@ void kvmppc_mmu_invalidate(struct kvm_vc
 	up_write(&current->mm->mmap_sem);
 }
 
-/* Invalidate all mappings, so that when they fault back in they will get the
- * proper permission bits. */
+/* Invalidate all mappings on the privilege switch after PID has been changed.
+ * The guest always runs with PID=1, so we must clear the entire TLB when
+ * switching address spaces. */
 void kvmppc_mmu_priv_switch(struct kvm_vcpu *vcpu, int usermode)
 {
 	int i;
 
-	/* XXX Replace loop with fancy data structures. */
-	down_write(&current->mm->mmap_sem);
-	for (i = 0; i <= tlb_44x_hwater; i++) {
-		struct tlbe *stlbe = &vcpu->arch.shadow_tlb[i];
+	if (vcpu->arch.swap_pid) {
+		/* XXX Replace loop with fancy data structures. */
+		down_write(&current->mm->mmap_sem);
+		for (i = 0; i <= tlb_44x_hwater; i++) {
+			struct tlbe *stlbe = &vcpu->arch.shadow_tlb[i];
 
-		kvmppc_44x_shadow_release(vcpu, i);
-		stlbe->word0 = 0;
-		kvmppc_tlbe_set_modified(vcpu, i);
-		KVMTRACE_5D(STLB_INVAL, vcpu, i,
-				stlbe->tid, stlbe->word0, stlbe->word1,
-				stlbe->word2, handler);
+			/* Future optimization: clear only userspace mappings. */
+			kvmppc_44x_shadow_release(vcpu, i);
+			stlbe->word0 = 0;
+			kvmppc_tlbe_set_modified(vcpu, i);
+			KVMTRACE_5D(STLB_INVAL, vcpu, i,
+			            stlbe->tid, stlbe->word0, stlbe->word1,
+			            stlbe->word2, handler);
+		}
+		up_write(&current->mm->mmap_sem);
+		vcpu->arch.swap_pid = 0;
 	}
-	up_write(&current->mm->mmap_sem);
+
+	vcpu->arch.shadow_pid = !usermode;
 }
diff --git a/arch/powerpc/kvm/booke_guest.c b/arch/powerpc/kvm/booke_guest.c
--- a/arch/powerpc/kvm/booke_guest.c
+++ b/arch/powerpc/kvm/booke_guest.c
@@ -486,6 +486,8 @@ int kvm_arch_vcpu_setup(struct kvm_vcpu 
 	vcpu->arch.msr = 0;
 	vcpu->arch.gpr[1] = (16<<20) - 8; /* -8 for the callee-save LR slot */
 
+	vcpu->arch.shadow_pid = 1;
+
 	/* Eye-catching number so we know if the guest takes an interrupt
 	 * before it's programmed its own IVPR. */
 	vcpu->arch.ivpr = 0x55550000;
diff --git a/arch/powerpc/kvm/booke_interrupts.S b/arch/powerpc/kvm/booke_interrupts.S
--- a/arch/powerpc/kvm/booke_interrupts.S
+++ b/arch/powerpc/kvm/booke_interrupts.S
@@ -332,7 +332,7 @@ lightweight_exit:
 
 	mfspr	r3, SPRN_PID
 	stw	r3, VCPU_HOST_PID(r4)
-	lwz	r3, VCPU_PID(r4)
+	lwz	r3, VCPU_SHADOW_PID(r4)
 	mtspr	SPRN_PID, r3
 
 	/* Prevent all asynchronous TLB updates. */
diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
--- a/arch/powerpc/kvm/emulate.c
+++ b/arch/powerpc/kvm/emulate.c
@@ -508,7 +508,7 @@ int kvmppc_emulate_instruction(struct kv
 			case SPRN_MMUCR:
 				vcpu->arch.mmucr = vcpu->arch.gpr[rs]; break;
 			case SPRN_PID:
-				vcpu->arch.pid = vcpu->arch.gpr[rs]; break;
+				kvmppc_set_pid(vcpu, vcpu->arch.gpr[rs]); break;
 			case SPRN_CCR0:
 				vcpu->arch.ccr0 = vcpu->arch.gpr[rs]; break;
 			case SPRN_CCR1:
diff --git a/include/asm-powerpc/kvm_host.h b/include/asm-powerpc/kvm_host.h
--- a/include/asm-powerpc/kvm_host.h
+++ b/include/asm-powerpc/kvm_host.h
@@ -129,7 +129,11 @@ struct kvm_vcpu_arch {
 	u32 ivor[16];
 	u32 ivpr;
 	u32 pir;
+
+	u32 shadow_pid;
 	u32 pid;
+	u32 swap_pid;
+
 	u32 pvr;
 	u32 ccr0;
 	u32 ccr1;
diff --git a/include/asm-powerpc/kvm_ppc.h b/include/asm-powerpc/kvm_ppc.h
--- a/include/asm-powerpc/kvm_ppc.h
+++ b/include/asm-powerpc/kvm_ppc.h
@@ -64,6 +64,7 @@ extern void kvmppc_mmu_invalidate(struct
 extern void kvmppc_mmu_invalidate(struct kvm_vcpu *vcpu, gva_t eaddr,
                                   gva_t eend, u32 asid);
 extern void kvmppc_mmu_priv_switch(struct kvm_vcpu *vcpu, int usermode);
+extern void kvmppc_mmu_switch_pid(struct kvm_vcpu *vcpu, u32 pid);
 
 /* XXX Book E specific */
 extern void kvmppc_tlbe_set_modified(struct kvm_vcpu *vcpu, unsigned int i);
@@ -95,4 +96,12 @@ static inline void kvmppc_set_msr(struct
 		kvm_vcpu_block(vcpu);
 }
 
+static inline void kvmppc_set_pid(struct kvm_vcpu *vcpu, u32 new_pid)
+{
+	if (vcpu->arch.pid != new_pid) {
+		vcpu->arch.pid = new_pid;
+		vcpu->arch.swap_pid = 1;
+	}
+}
+
 #endif /* __POWERPC_KVM_PPC_H__ */
--
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 5 of 5] kvm: powerpc: Map guest userspace with TID=0 mappings

[Liu Yu]

I have a question that I could not think through.
While multiple qemu/kvm processes are running at the same time, how to
prevent one guest from using others' TLB? For all the guests have the
same TID=0 for userspace and TID=1 for kernel.


> -----Original Message-----
> From: kvm-ppc-owner@vger.kernel.org 
> [mailto:kvm-ppc-owner@vger.kernel.org] On Behalf Of Hollis Blanchard
> Sent: Saturday, July 26, 2008 2:55 AM
> To: avi@qumranet.com
> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
> Subject: [PATCH 5 of 5] kvm: powerpc: Map guest userspace 
> with TID=0 mappings
> 
> # HG changeset patch
> # User Hollis Blanchard <hollisb@us.ibm.com> # Date 
> 1217011852 18000 # Node ID 080b9c9515a5593babc8cac73687b053d7d3f124
> # Parent  c832dfc7a6b50ace3c37d00b16ef9f5b46284b3e
> kvm: powerpc: Map guest userspace with TID=0 mappings.
> 
> When we use TID=N userspace mappings, we must ensure that 
> kernel mappings have been destroyed when entering userspace. 
> Using TID=1/TID=0 for kernel/user mappings and running 
> userspace with PID=0 means that userspace can't access the 
> kernel mappings, but the kernel can directly access userspace.
> 
> The net is that we don't need to flush the TLB on privilege 
> switches, but we do on guest context switches (which are far 
> more infrequent). Guest boot time performance improvement: about 30%.
> 
> Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>
> 
> ---
> 7 files changed, 40 insertions(+), 18 deletions(-)
> arch/powerpc/kernel/asm-offsets.c   |    2 -
> arch/powerpc/kvm/44x_tlb.c          |   37 
> ++++++++++++++++++++---------------
> arch/powerpc/kvm/booke_guest.c      |    2 +
> arch/powerpc/kvm/booke_interrupts.S |    2 -
> arch/powerpc/kvm/emulate.c          |    2 -
> include/asm-powerpc/kvm_host.h      |    4 +++
> include/asm-powerpc/kvm_ppc.h       |    9 ++++++++
> 

RE: [PATCH 5 of 5] kvm: powerpc: Map guest userspace with TID=0 mappings

[Liu Yu]

I have a question that I could not think through.
While multiple qemu/kvm processes are running at the same time, how to
prevent one guest from using others' TLB? For all the guests have the
same TID=0 for userspace and TID=1 for kernel.


> -----Original Message-----
> From: kvm-ppc-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org 
> [mailto:kvm-ppc-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org] On Behalf Of Hollis Blanchard
> Sent: Saturday, July 26, 2008 2:55 AM
> To: avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org
> Cc: kvm-ppc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Subject: [PATCH 5 of 5] kvm: powerpc: Map guest userspace 
> with TID=0 mappings
> 
> # HG changeset patch
> # User Hollis Blanchard <hollisb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> # Date 
> 1217011852 18000 # Node ID 080b9c9515a5593babc8cac73687b053d7d3f124
> # Parent  c832dfc7a6b50ace3c37d00b16ef9f5b46284b3e
> kvm: powerpc: Map guest userspace with TID=0 mappings.
> 
> When we use TID=N userspace mappings, we must ensure that 
> kernel mappings have been destroyed when entering userspace. 
> Using TID=1/TID=0 for kernel/user mappings and running 
> userspace with PID=0 means that userspace can't access the 
> kernel mappings, but the kernel can directly access userspace.
> 
> The net is that we don't need to flush the TLB on privilege 
> switches, but we do on guest context switches (which are far 
> more infrequent). Guest boot time performance improvement: about 30%.
> 
> Signed-off-by: Hollis Blanchard <hollisb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
> 
> ---
> 7 files changed, 40 insertions(+), 18 deletions(-)
> arch/powerpc/kernel/asm-offsets.c   |    2 -
> arch/powerpc/kvm/44x_tlb.c          |   37 
> ++++++++++++++++++++---------------
> arch/powerpc/kvm/booke_guest.c      |    2 +
> arch/powerpc/kvm/booke_interrupts.S |    2 -
> arch/powerpc/kvm/emulate.c          |    2 -
> include/asm-powerpc/kvm_host.h      |    4 +++
> include/asm-powerpc/kvm_ppc.h       |    9 ++++++++
> 
--
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 5 of 5] kvm: powerpc: Map guest userspace with TID=0 mappings

[Christian Ehrhardt]

On Monday 28 July 2008 12:33:41 Liu Yu wrote:
> I have a question that I could not think through.
> While multiple qemu/kvm processes are running at the same time, how to
> prevent one guest from using others' TLB? For all the guests have the
> same TID=0 for userspace and TID=1 for kernel.
[...]

Hi Yu Liu, thats a good question.
Afaik thats solved by the fact that the shadow tlb which is used when entering 
guest context is per vcpu. Therefor a guest has always it's own shadow tlb 
active and no mappings to the content of other guests.

This patch just allows us that a single guest userspace process accessing the 
kernel 20 times (and changing privilege level 20 times by doing so) can run 
without tlb flushes.
Guest-userspace context switch (pid is changing) -> tlb flush; and guest 
switches (guest A -> guest B) -> other shadow tlb active; should still be 
working fine.

> >
> > The net is that we don't need to flush the TLB on privilege
> > switches, but we do on guest context switches (which are far
> > more infrequent). Guest boot time performance improvement: about 30%.
> >

-- 

Grüsse / regards, 
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization

Re: [PATCH 5 of 5] kvm: powerpc: Map guest userspace with TID=0 mappings

[Christian Ehrhardt]

On Monday 28 July 2008 12:33:41 Liu Yu wrote:
> I have a question that I could not think through.
> While multiple qemu/kvm processes are running at the same time, how to
> prevent one guest from using others' TLB? For all the guests have the
> same TID=0 for userspace and TID=1 for kernel.
[...]

Hi Yu Liu, thats a good question.
Afaik thats solved by the fact that the shadow tlb which is used when entering 
guest context is per vcpu. Therefor a guest has always it's own shadow tlb 
active and no mappings to the content of other guests.

This patch just allows us that a single guest userspace process accessing the 
kernel 20 times (and changing privilege level 20 times by doing so) can run 
without tlb flushes.
Guest-userspace context switch (pid is changing) -> tlb flush; and guest 
switches (guest A -> guest B) -> other shadow tlb active; should still be 
working fine.

> >
> > The net is that we don't need to flush the TLB on privilege
> > switches, but we do on guest context switches (which are far
> > more infrequent). Guest boot time performance improvement: about 30%.
> >

-- 

Grüsse / regards, 
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization

RE: [PATCH 5 of 5] kvm: powerpc: Map guest userspace with TID=0 mappings

[Liu Yu]

> -----Original Message-----
> From: Christian Ehrhardt [mailto:ehrhardt@linux.vnet.ibm.com] 
> Sent: Tuesday, July 29, 2008 3:03 PM
> To: Liu Yu
> Cc: Hollis Blanchard; avi@qumranet.com; 
> kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
> Subject: Re: [PATCH 5 of 5] kvm: powerpc: Map guest userspace 
> with TID=0 mappings
> 
> On Monday 28 July 2008 12:33:41 Liu Yu wrote:
> > I have a question that I could not think through.
> > While multiple qemu/kvm processes are running at the same 
> time, how to 
> > prevent one guest from using others' TLB? For all the 
> guests have the 
> > same TID=0 for userspace and TID=1 for kernel.
> [...]
> 
> Hi Yu Liu, thats a good question.
> Afaik thats solved by the fact that the shadow tlb which is 
> used when entering guest context is per vcpu. Therefor a 
> guest has always it's own shadow tlb active and no mappings 
> to the content of other guests.

Yes, shadow tlb is per vcpu.
But in the patch 4/5, before entering guest context, not all shadow tlb will be written back.
So if (guest A -> guest B) happen, after entering guest B, is there any possibility that A's tlb is still existing in hardware?


> 
> This patch just allows us that a single guest userspace 
> process accessing the kernel 20 times (and changing privilege 
> level 20 times by doing so) can run without tlb flushes.
> Guest-userspace context switch (pid is changing) -> tlb 
> flush; and guest switches (guest A -> guest B) -> other 
> shadow tlb active; should still be working fine.
> 
> > >
> > > The net is that we don't need to flush the TLB on privilege
> > > switches, but we do on guest context switches (which are far
> > > more infrequent). Guest boot time performance 
> improvement: about 30%.
> > >
> 
> -- 
> 
> Grüsse / regards, 
> Christian Ehrhardt
> IBM Linux Technology Center, Open Virtualization
> 

RE: [PATCH 5 of 5] kvm: powerpc: Map guest userspace with TID=0 mappings

[Liu Yu]

> -----Original Message-----
> From: Christian Ehrhardt [mailto:ehrhardt@linux.vnet.ibm.com] 
> Sent: Tuesday, July 29, 2008 3:03 PM
> To: Liu Yu
> Cc: Hollis Blanchard; avi@qumranet.com; 
> kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
> Subject: Re: [PATCH 5 of 5] kvm: powerpc: Map guest userspace 
> with TID=0 mappings
> 
> On Monday 28 July 2008 12:33:41 Liu Yu wrote:
> > I have a question that I could not think through.
> > While multiple qemu/kvm processes are running at the same 
> time, how to 
> > prevent one guest from using others' TLB? For all the 
> guests have the 
> > same TID=0 for userspace and TID=1 for kernel.
> [...]
> 
> Hi Yu Liu, thats a good question.
> Afaik thats solved by the fact that the shadow tlb which is 
> used when entering guest context is per vcpu. Therefor a 
> guest has always it's own shadow tlb active and no mappings 
> to the content of other guests.

Yes, shadow tlb is per vcpu.
But in the patch 4/5, before entering guest context, not all shadow tlb will be written back.
So if (guest A -> guest B) happen, after entering guest B, is there any possibility that A's tlb is still existing in hardware?


> 
> This patch just allows us that a single guest userspace 
> process accessing the kernel 20 times (and changing privilege 
> level 20 times by doing so) can run without tlb flushes.
> Guest-userspace context switch (pid is changing) -> tlb 
> flush; and guest switches (guest A -> guest B) -> other 
> shadow tlb active; should still be working fine.
> 
> > >
> > > The net is that we don't need to flush the TLB on privilege
> > > switches, but we do on guest context switches (which are far
> > > more infrequent). Guest boot time performance 
> improvement: about 30%.
> > >
> 
> -- 
> 
> Grüsse / regards, 
> Christian Ehrhardt
> IBM Linux Technology Center, Open Virtualization
> 

RE: [PATCH 5 of 5] kvm: powerpc: Map guest userspace with TID=0 mappings

[Liu Yu]

=-

> -----Original Message-----
> From: kvm-ppc-owner@vger.kernel.org 
> [mailto:kvm-ppc-owner@vger.kernel.org] On Behalf Of Liu Yu
> Sent: Tuesday, July 29, 2008 3:48 PM
> To: Christian Ehrhardt
> Cc: Hollis Blanchard; avi@qumranet.com; 
> kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
> Subject: RE: [PATCH 5 of 5] kvm: powerpc: Map guest userspace 
> with TID=0 mappings
> 
> 
> > -----Original Message-----
> > From: Christian Ehrhardt [mailto:ehrhardt@linux.vnet.ibm.com]
> > Sent: Tuesday, July 29, 2008 3:03 PM
> > To: Liu Yu
> > Cc: Hollis Blanchard; avi@qumranet.com; kvm-ppc@vger.kernel.org; 
> > kvm@vger.kernel.org
> > Subject: Re: [PATCH 5 of 5] kvm: powerpc: Map guest userspace with 
> > TID=0 mappings
> > 
> > On Monday 28 July 2008 12:33:41 Liu Yu wrote:
> > > I have a question that I could not think through.
> > > While multiple qemu/kvm processes are running at the same
> > time, how to
> > > prevent one guest from using others' TLB? For all the
> > guests have the
> > > same TID=0 for userspace and TID=1 for kernel.
> > [...]
> > 
> > Hi Yu Liu, thats a good question.
> > Afaik thats solved by the fact that the shadow tlb which is 
> used when 
> > entering guest context is per vcpu. Therefor a guest has 
> always it's 
> > own shadow tlb active and no mappings to the content of 
> other guests.
> 
> Yes, shadow tlb is per vcpu.
> But in the patch 4/5, before entering guest context, not all 
> shadow tlb will be written back.
> So if (guest A -> guest B) happen, after entering guest B, is 
> there any possibility that A's tlb is still existing in hardware?

I see.
'kvm_arch_vcpu_load' and 'kvm_arch_vcpu_put' will handle this in preempt hooker.

> 
> 
> > 
> > This patch just allows us that a single guest userspace process 
> > accessing the kernel 20 times (and changing privilege level 
> 20 times 
> > by doing so) can run without tlb flushes.
> > Guest-userspace context switch (pid is changing) -> tlb flush; and 
> > guest switches (guest A -> guest B) -> other shadow tlb 
> active; should 
> > still be working fine.
> > 
> > > >
> > > > The net is that we don't need to flush the TLB on privilege 
> > > > switches, but we do on guest context switches (which 
> are far more 
> > > > infrequent). Guest boot time performance
> > improvement: about 30%.
> > > >
> > 
> > --
> > 
> > Grüsse / regards,
> > Christian Ehrhardt
> > IBM Linux Technology Center, Open Virtualization
> > 
> --
> To unsubscribe from this list: send the line "unsubscribe 
> kvm-ppc" in the body of a message to 
> majordomo@vger.kernel.org More majordomo info at  
> http://vger.kernel.org/majordomo-info.html
> 

RE: [PATCH 5 of 5] kvm: powerpc: Map guest userspace with TID=0 mappings

[Liu Yu]

=-

> -----Original Message-----
> From: kvm-ppc-owner@vger.kernel.org 
> [mailto:kvm-ppc-owner@vger.kernel.org] On Behalf Of Liu Yu
> Sent: Tuesday, July 29, 2008 3:48 PM
> To: Christian Ehrhardt
> Cc: Hollis Blanchard; avi@qumranet.com; 
> kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
> Subject: RE: [PATCH 5 of 5] kvm: powerpc: Map guest userspace 
> with TID=0 mappings
> 
> 
> > -----Original Message-----
> > From: Christian Ehrhardt [mailto:ehrhardt@linux.vnet.ibm.com]
> > Sent: Tuesday, July 29, 2008 3:03 PM
> > To: Liu Yu
> > Cc: Hollis Blanchard; avi@qumranet.com; kvm-ppc@vger.kernel.org; 
> > kvm@vger.kernel.org
> > Subject: Re: [PATCH 5 of 5] kvm: powerpc: Map guest userspace with 
> > TID=0 mappings
> > 
> > On Monday 28 July 2008 12:33:41 Liu Yu wrote:
> > > I have a question that I could not think through.
> > > While multiple qemu/kvm processes are running at the same
> > time, how to
> > > prevent one guest from using others' TLB? For all the
> > guests have the
> > > same TID=0 for userspace and TID=1 for kernel.
> > [...]
> > 
> > Hi Yu Liu, thats a good question.
> > Afaik thats solved by the fact that the shadow tlb which is 
> used when 
> > entering guest context is per vcpu. Therefor a guest has 
> always it's 
> > own shadow tlb active and no mappings to the content of 
> other guests.
> 
> Yes, shadow tlb is per vcpu.
> But in the patch 4/5, before entering guest context, not all 
> shadow tlb will be written back.
> So if (guest A -> guest B) happen, after entering guest B, is 
> there any possibility that A's tlb is still existing in hardware?

I see.
'kvm_arch_vcpu_load' and 'kvm_arch_vcpu_put' will handle this in preempt hooker.

> 
> 
> > 
> > This patch just allows us that a single guest userspace process 
> > accessing the kernel 20 times (and changing privilege level 
> 20 times 
> > by doing so) can run without tlb flushes.
> > Guest-userspace context switch (pid is changing) -> tlb flush; and 
> > guest switches (guest A -> guest B) -> other shadow tlb 
> active; should 
> > still be working fine.
> > 
> > > >
> > > > The net is that we don't need to flush the TLB on privilege 
> > > > switches, but we do on guest context switches (which 
> are far more 
> > > > infrequent). Guest boot time performance
> > improvement: about 30%.
> > > >
> > 
> > --
> > 
> > Grüsse / regards,
> > Christian Ehrhardt
> > IBM Linux Technology Center, Open Virtualization
> > 
> --
> To unsubscribe from this list: send the line "unsubscribe 
> kvm-ppc" in the body of a message to 
> majordomo@vger.kernel.org More majordomo info at  
> http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH 0 of 5] PowerPC patches for 2.6.27

[Avi Kivity]

Hollis Blanchard wrote:
> Hi Avi, can these patches go upstream for 2.6.27? There's a bug fix,
> the addition of hardware breakpoint functionality, and three very significant
> performance improvements.
>
> By the way, I will be on vacation for a few weeks starting Monday, but
> Christian Ehrhardt should be able to take care of any technical issues.
>   

Applied all; thanks.  I prefer to only merge bug fixes at this time for 
2.6.27.  As far as I can tell, patch 2 is independent of the rest so 
I'll queue that.  Let me know if that works.

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

Re: [PATCH 0 of 5] PowerPC patches for 2.6.27

[Avi Kivity]

Hollis Blanchard wrote:
> Hi Avi, can these patches go upstream for 2.6.27? There's a bug fix,
> the addition of hardware breakpoint functionality, and three very significant
> performance improvements.
>
> By the way, I will be on vacation for a few weeks starting Monday, but
> Christian Ehrhardt should be able to take care of any technical issues.
>   

Applied all; thanks.  I prefer to only merge bug fixes at this time for 
2.6.27.  As far as I can tell, patch 2 is independent of the rest so 
I'll queue that.  Let me know if that works.

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

--
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 0 of 5] PowerPC patches for 2.6.27

[Christian Ehrhardt]

On Sunday 27 July 2008 10:50:38 Avi Kivity wrote:
> Hollis Blanchard wrote:
> > Hi Avi, can these patches go upstream for 2.6.27? There's a bug fix,
> > the addition of hardware breakpoint functionality, and three very
> > significant performance improvements.
> >
> > By the way, I will be on vacation for a few weeks starting Monday, but
> > Christian Ehrhardt should be able to take care of any technical issues.
>
> Applied all; thanks.  I prefer to only merge bug fixes at this time for
> 2.6.27.  As far as I can tell, patch 2 is independent of the rest so
> I'll queue that.  Let me know if that works.

Yes these patches are independent - for the type question you can consider
1/5 - feature
2/5 - bug fix
3,4,5/5 - yeah what is it .. neither a pure bug fix nor a feature let's call 
it "performance fix"

We tested most of those performance fixes at least 1.5 Months now, having them 
applied while developing new things on top and I feel very good with 3&4.
It would be nice if at least the performance fixes 3&4 could go in now under 
the bug fix label too, but it's up to you.

-- 

Grüsse / regards, 
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization

Re: [PATCH 0 of 5] PowerPC patches for 2.6.27

[Christian Ehrhardt]

On Sunday 27 July 2008 10:50:38 Avi Kivity wrote:
> Hollis Blanchard wrote:
> > Hi Avi, can these patches go upstream for 2.6.27? There's a bug fix,
> > the addition of hardware breakpoint functionality, and three very
> > significant performance improvements.
> >
> > By the way, I will be on vacation for a few weeks starting Monday, but
> > Christian Ehrhardt should be able to take care of any technical issues.
>
> Applied all; thanks.  I prefer to only merge bug fixes at this time for
> 2.6.27.  As far as I can tell, patch 2 is independent of the rest so
> I'll queue that.  Let me know if that works.

Yes these patches are independent - for the type question you can consider
1/5 - feature
2/5 - bug fix
3,4,5/5 - yeah what is it .. neither a pure bug fix nor a feature let's call 
it "performance fix"

We tested most of those performance fixes at least 1.5 Months now, having them 
applied while developing new things on top and I feel very good with 3&4.
It would be nice if at least the performance fixes 3&4 could go in now under 
the bug fix label too, but it's up to you.

-- 

Grüsse / regards, 
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization
--
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 0 of 5] PowerPC patches for 2.6.27

[Avi Kivity]

Christian Ehrhardt wrote:
>> Applied all; thanks.  I prefer to only merge bug fixes at this time for
>> 2.6.27.  As far as I can tell, patch 2 is independent of the rest so
>> I'll queue that.  Let me know if that works.
>>     
>
> Yes these patches are independent - for the type question you can consider
> 1/5 - feature
> 2/5 - bug fix
> 3,4,5/5 - yeah what is it .. neither a pure bug fix nor a feature let's call 
> it "performance fix"
>
> We tested most of those performance fixes at least 1.5 Months now, having them 
> applied while developing new things on top and I feel very good with 3&4.
> It would be nice if at least the performance fixes 3&4 could go in now under 
> the bug fix label too, but it's up to you.
>   

Please send patches as soon as you feel confident about them; I can 
easily fold fixes (or drop patches) later.  Sending larger changes post 
merge window is sure to attract flames.

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

Re: [PATCH 0 of 5] PowerPC patches for 2.6.27

[Avi Kivity]

Christian Ehrhardt wrote:
>> Applied all; thanks.  I prefer to only merge bug fixes at this time for
>> 2.6.27.  As far as I can tell, patch 2 is independent of the rest so
>> I'll queue that.  Let me know if that works.
>>     
>
> Yes these patches are independent - for the type question you can consider
> 1/5 - feature
> 2/5 - bug fix
> 3,4,5/5 - yeah what is it .. neither a pure bug fix nor a feature let's call 
> it "performance fix"
>
> We tested most of those performance fixes at least 1.5 Months now, having them 
> applied while developing new things on top and I feel very good with 3&4.
> It would be nice if at least the performance fixes 3&4 could go in now under 
> the bug fix label too, but it's up to you.
>   

Please send patches as soon as you feel confident about them; I can 
easily fold fixes (or drop patches) later.  Sending larger changes post 
merge window is sure to attract flames.

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