[PULL 0/7] ppc patch queue 2013-03-22

[PULL 0/7] ppc patch queue 2013-03-22

[Alexander Graf]

Hi Marcelo / Gleb,

This is my current patch queue for ppc.  Please pull.

Changes include:

  - race-free in-kernel watchdog handling api
  - e500 mmu fixes

Alex


The following changes since commit 2ae33b389601b86a3d0cfe2d09f5e3189d5322fd:
  Marcelo Tosatti (1):
        Merge remote-tracking branch 'upstream/master' into queue

are available in the git repository at:

  git://github.com/agraf/linux-2.6.git kvm-ppc-next

Bharat Bhushan (3):
      KVM: PPC: move tsr update in a separate function
      KVM: PPC: Added one_reg interface for timer registers
      KVM: PPC: booke: Added debug handler

Paul Mackerras (1):
      KVM: PPC: Remove unused argument to kvmppc_core_dequeue_external

Scott Wood (3):
      kvm/ppc/e500: h2g_tlb1_rmap: esel 0 is valid
      kvm/ppc/e500: g2h_tlb1_map: clear old bit before setting new bit
      kvm/ppc/e500: eliminate tlb_refs

 Documentation/virtual/kvm/api.txt   |    4 ++
 arch/powerpc/include/asm/kvm_host.h |    1 +
 arch/powerpc/include/asm/kvm_ppc.h  |    3 +-
 arch/powerpc/include/uapi/asm/kvm.h |    5 ++
 arch/powerpc/kernel/asm-offsets.c   |    1 +
 arch/powerpc/kvm/book3s.c           |    3 +-
 arch/powerpc/kvm/booke.c            |   57 +++++++++++++++++++-----
 arch/powerpc/kvm/booke_interrupts.S |   42 ++++++++++++++++-
 arch/powerpc/kvm/e500.h             |   24 +++-------
 arch/powerpc/kvm/e500_mmu_host.c    |   84 +++++++++++-----------------------
 arch/powerpc/kvm/powerpc.c          |    2 +-
 11 files changed, 133 insertions(+), 93 deletions(-)

[PATCH 1/7] KVM: PPC: move tsr update in a separate function

[Alexander Graf]

From: Bharat Bhushan <r65777@freescale.com>

This is done so that same function can be called from SREGS and
ONE_REG interface (follow up patch).

Signed-off-by: Bharat Bhushan <bharat.bhushan@freescale.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
---
 arch/powerpc/kvm/booke.c |   24 ++++++++++++++----------
 1 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index eb88fa6..f2fd47d 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -1148,6 +1148,18 @@ int kvmppc_handle_exit(struct kvm_run *run, struct kvm_vcpu *vcpu,
 	return r;
 }
 
+static void kvmppc_set_tsr(struct kvm_vcpu *vcpu, u32 new_tsr)
+{
+	u32 old_tsr = vcpu->arch.tsr;
+
+	vcpu->arch.tsr = new_tsr;
+
+	if ((old_tsr ^ vcpu->arch.tsr) & (TSR_ENW | TSR_WIS))
+		arm_next_watchdog(vcpu);
+
+	update_timer_ints(vcpu);
+}
+
 /* Initial guest state: 16MB mapping 0 -> 0, PC = 0, MSR = 0, R1 = 16MB */
 int kvm_arch_vcpu_setup(struct kvm_vcpu *vcpu)
 {
@@ -1287,16 +1299,8 @@ static int set_sregs_base(struct kvm_vcpu *vcpu,
 		kvmppc_emulate_dec(vcpu);
 	}
 
-	if (sregs->u.e.update_special & KVM_SREGS_E_UPDATE_TSR) {
-		u32 old_tsr = vcpu->arch.tsr;
-
-		vcpu->arch.tsr = sregs->u.e.tsr;
-
-		if ((old_tsr ^ vcpu->arch.tsr) & (TSR_ENW | TSR_WIS))
-			arm_next_watchdog(vcpu);
-
-		update_timer_ints(vcpu);
-	}
+	if (sregs->u.e.update_special & KVM_SREGS_E_UPDATE_TSR)
+		kvmppc_set_tsr(vcpu, sregs->u.e.tsr);
 
 	return 0;
 }
-- 
1.6.0.2

[PATCH 2/7] KVM: PPC: Added one_reg interface for timer registers

[Alexander Graf]

From: Bharat Bhushan <r65777@freescale.com>

If userspace wants to change some specific bits of TSR
(timer status register) then it uses GET/SET_SREGS ioctl interface.
So the steps will be:
      i)   user-space will make get ioctl,
      ii)  change TSR in userspace
      iii) then make set ioctl.
It can happen that TSR gets changed by kernel after step i) and
before step iii).

To avoid this we have added below one_reg ioctls for oring and clearing
specific bits in TSR. This patch adds one registerface for:
     1) setting specific bit in TSR (timer status register)
     2) clearing specific bit in TSR (timer status register)
     3) setting/getting the TCR register. There are cases where we want to only
        change TCR and not TSR. Although we can uses SREGS without
        KVM_SREGS_E_UPDATE_TSR flag but I think one reg is better. I am open
        if someone feels we should use SREGS only here.
     4) getting/setting TSR register

Signed-off-by: Bharat Bhushan <bharat.bhushan@freescale.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
---
 Documentation/virtual/kvm/api.txt   |    4 ++++
 arch/powerpc/include/uapi/asm/kvm.h |    5 +++++
 arch/powerpc/kvm/booke.c            |   30 ++++++++++++++++++++++++++++++
 3 files changed, 39 insertions(+), 0 deletions(-)

diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index c16b442..976eb65 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -1788,6 +1788,10 @@ registers, find a list below:
   PPC   | KVM_REG_PPC_VPA_DTL   | 128
   PPC   | KVM_REG_PPC_EPCR	| 32
   PPC   | KVM_REG_PPC_EPR	| 32
+  PPC   | KVM_REG_PPC_TCR	| 32
+  PPC   | KVM_REG_PPC_TSR	| 32
+  PPC   | KVM_REG_PPC_OR_TSR	| 32
+  PPC   | KVM_REG_PPC_CLEAR_TSR	| 32
 
 ARM registers are mapped using the lower 32 bits.  The upper 16 of that
 is the register group type, or coprocessor number:
diff --git a/arch/powerpc/include/uapi/asm/kvm.h b/arch/powerpc/include/uapi/asm/kvm.h
index 16064d0..ef072b1 100644
--- a/arch/powerpc/include/uapi/asm/kvm.h
+++ b/arch/powerpc/include/uapi/asm/kvm.h
@@ -417,4 +417,9 @@ struct kvm_get_htab_header {
 #define KVM_REG_PPC_EPCR	(KVM_REG_PPC | KVM_REG_SIZE_U32 | 0x85)
 #define KVM_REG_PPC_EPR		(KVM_REG_PPC | KVM_REG_SIZE_U32 | 0x86)
 
+/* Timer Status Register OR/CLEAR interface */
+#define KVM_REG_PPC_OR_TSR	(KVM_REG_PPC | KVM_REG_SIZE_U32 | 0x87)
+#define KVM_REG_PPC_CLEAR_TSR	(KVM_REG_PPC | KVM_REG_SIZE_U32 | 0x88)
+#define KVM_REG_PPC_TCR		(KVM_REG_PPC | KVM_REG_SIZE_U32 | 0x89)
+#define KVM_REG_PPC_TSR		(KVM_REG_PPC | KVM_REG_SIZE_U32 | 0x8a)
 #endif /* __LINUX_KVM_POWERPC_H */
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index f2fd47d..1182553 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -1442,6 +1442,12 @@ int kvm_vcpu_ioctl_get_one_reg(struct kvm_vcpu *vcpu, struct kvm_one_reg *reg)
 		r = put_user(vcpu->arch.epcr, (u32 __user *)(long)reg->addr);
 		break;
 #endif
+	case KVM_REG_PPC_TCR:
+		r = put_user(vcpu->arch.tcr, (u32 __user *)(long)reg->addr);
+		break;
+	case KVM_REG_PPC_TSR:
+		r = put_user(vcpu->arch.tsr, (u32 __user *)(long)reg->addr);
+		break;
 	default:
 		break;
 	}
@@ -1485,6 +1491,30 @@ int kvm_vcpu_ioctl_set_one_reg(struct kvm_vcpu *vcpu, struct kvm_one_reg *reg)
 		break;
 	}
 #endif
+	case KVM_REG_PPC_OR_TSR: {
+		u32 tsr_bits;
+		r = get_user(tsr_bits, (u32 __user *)(long)reg->addr);
+		kvmppc_set_tsr_bits(vcpu, tsr_bits);
+		break;
+	}
+	case KVM_REG_PPC_CLEAR_TSR: {
+		u32 tsr_bits;
+		r = get_user(tsr_bits, (u32 __user *)(long)reg->addr);
+		kvmppc_clr_tsr_bits(vcpu, tsr_bits);
+		break;
+	}
+	case KVM_REG_PPC_TSR: {
+		u32 tsr;
+		r = get_user(tsr, (u32 __user *)(long)reg->addr);
+		kvmppc_set_tsr(vcpu, tsr);
+		break;
+	}
+	case KVM_REG_PPC_TCR: {
+		u32 tcr;
+		r = get_user(tcr, (u32 __user *)(long)reg->addr);
+		kvmppc_set_tcr(vcpu, tcr);
+		break;
+	}
 	default:
 		break;
 	}
-- 
1.6.0.2

[PATCH 3/7] KVM: PPC: booke: Added debug handler

[Alexander Graf]

From: Bharat Bhushan <r65777@freescale.com>

Installed debug handler will be used for guest debug support
and debug facility emulation features (patches for these
features will follow this patch).

Signed-off-by: Liu Yu <yu.liu@freescale.com>
[bharat.bhushan@freescale.com: Substantial changes]
Signed-off-by: Bharat Bhushan <bharat.bhushan@freescale.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
---
 arch/powerpc/include/asm/kvm_host.h |    1 +
 arch/powerpc/kernel/asm-offsets.c   |    1 +
 arch/powerpc/kvm/booke_interrupts.S |   42 ++++++++++++++++++++++++++++++++--
 3 files changed, 41 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
index d1bb860..e34f8fe 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -504,6 +504,7 @@ struct kvm_vcpu_arch {
 	u32 tlbcfg[4];
 	u32 mmucfg;
 	u32 epr;
+	u32 crit_save;
 	struct kvmppc_booke_debug_reg dbg_reg;
 #endif
 	gpa_t paddr_accessed;
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index b6c17ec..d87c908 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -596,6 +596,7 @@ int main(void)
 	DEFINE(VCPU_LAST_INST, offsetof(struct kvm_vcpu, arch.last_inst));
 	DEFINE(VCPU_FAULT_DEAR, offsetof(struct kvm_vcpu, arch.fault_dear));
 	DEFINE(VCPU_FAULT_ESR, offsetof(struct kvm_vcpu, arch.fault_esr));
+	DEFINE(VCPU_CRIT_SAVE, offsetof(struct kvm_vcpu, arch.crit_save));
 #endif /* CONFIG_PPC_BOOK3S */
 #endif /* CONFIG_KVM */
 
diff --git a/arch/powerpc/kvm/booke_interrupts.S b/arch/powerpc/kvm/booke_interrupts.S
index f4bb55c..2c6deb5 100644
--- a/arch/powerpc/kvm/booke_interrupts.S
+++ b/arch/powerpc/kvm/booke_interrupts.S
@@ -54,8 +54,7 @@
                        (1<<BOOKE_INTERRUPT_DTLB_MISS) | \
                        (1<<BOOKE_INTERRUPT_ALIGNMENT))
 
-.macro KVM_HANDLER ivor_nr scratch srr0
-_GLOBAL(kvmppc_handler_\ivor_nr)
+.macro __KVM_HANDLER ivor_nr scratch srr0
 	/* Get pointer to vcpu and record exit number. */
 	mtspr	\scratch , r4
 	mfspr   r4, SPRN_SPRG_THREAD
@@ -76,6 +75,43 @@ _GLOBAL(kvmppc_handler_\ivor_nr)
 	bctr
 .endm
 
+.macro KVM_HANDLER ivor_nr scratch srr0
+_GLOBAL(kvmppc_handler_\ivor_nr)
+	__KVM_HANDLER \ivor_nr \scratch \srr0
+.endm
+
+.macro KVM_DBG_HANDLER ivor_nr scratch srr0
+_GLOBAL(kvmppc_handler_\ivor_nr)
+	mtspr   \scratch, r4
+	mfspr	r4, SPRN_SPRG_THREAD
+	lwz	r4, THREAD_KVM_VCPU(r4)
+	stw	r3, VCPU_CRIT_SAVE(r4)
+	mfcr	r3
+	mfspr	r4, SPRN_CSRR1
+	andi.	r4, r4, MSR_PR
+	bne	1f
+	/* debug interrupt happened in enter/exit path */
+	mfspr   r4, SPRN_CSRR1
+	rlwinm  r4, r4, 0, ~MSR_DE
+	mtspr   SPRN_CSRR1, r4
+	lis	r4, 0xffff
+	ori	r4, r4, 0xffff
+	mtspr	SPRN_DBSR, r4
+	mfspr	r4, SPRN_SPRG_THREAD
+	lwz	r4, THREAD_KVM_VCPU(r4)
+	mtcr	r3
+	lwz     r3, VCPU_CRIT_SAVE(r4)
+	mfspr   r4, \scratch
+	rfci
+1:	/* debug interrupt happened in guest */
+	mtcr	r3
+	mfspr	r4, SPRN_SPRG_THREAD
+	lwz	r4, THREAD_KVM_VCPU(r4)
+	lwz     r3, VCPU_CRIT_SAVE(r4)
+	mfspr   r4, \scratch
+	__KVM_HANDLER \ivor_nr \scratch \srr0
+.endm
+
 .macro KVM_HANDLER_ADDR ivor_nr
 	.long	kvmppc_handler_\ivor_nr
 .endm
@@ -100,7 +136,7 @@ KVM_HANDLER BOOKE_INTERRUPT_FIT SPRN_SPRG_RSCRATCH0 SPRN_SRR0
 KVM_HANDLER BOOKE_INTERRUPT_WATCHDOG SPRN_SPRG_RSCRATCH_CRIT SPRN_CSRR0
 KVM_HANDLER BOOKE_INTERRUPT_DTLB_MISS SPRN_SPRG_RSCRATCH0 SPRN_SRR0
 KVM_HANDLER BOOKE_INTERRUPT_ITLB_MISS SPRN_SPRG_RSCRATCH0 SPRN_SRR0
-KVM_HANDLER BOOKE_INTERRUPT_DEBUG SPRN_SPRG_RSCRATCH_CRIT SPRN_CSRR0
+KVM_DBG_HANDLER BOOKE_INTERRUPT_DEBUG SPRN_SPRG_RSCRATCH_CRIT SPRN_CSRR0
 KVM_HANDLER BOOKE_INTERRUPT_SPE_UNAVAIL SPRN_SPRG_RSCRATCH0 SPRN_SRR0
 KVM_HANDLER BOOKE_INTERRUPT_SPE_FP_DATA SPRN_SPRG_RSCRATCH0 SPRN_SRR0
 KVM_HANDLER BOOKE_INTERRUPT_SPE_FP_ROUND SPRN_SPRG_RSCRATCH0 SPRN_SRR0
-- 
1.6.0.2

[PATCH 4/7] kvm/ppc/e500: h2g_tlb1_rmap: esel 0 is valid

[Alexander Graf]

From: Scott Wood <scottwood@freescale.com>

Add one to esel values in h2g_tlb1_rmap, so that "no mapping" can be
distinguished from "esel 0".  Note that we're not saved by the fact
that host esel 0 is reserved for non-KVM use, because KVM host esel
numbering is not the raw host numbering (see to_htlb1_esel).

Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
---
 arch/powerpc/kvm/e500_mmu_host.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kvm/e500_mmu_host.c b/arch/powerpc/kvm/e500_mmu_host.c
index a222edf..35fb80e 100644
--- a/arch/powerpc/kvm/e500_mmu_host.c
+++ b/arch/powerpc/kvm/e500_mmu_host.c
@@ -511,10 +511,10 @@ static int kvmppc_e500_tlb1_map_tlb1(struct kvmppc_vcpu_e500 *vcpu_e500,
 	vcpu_e500->g2h_tlb1_map[esel] |= (u64)1 << sesel;
 	vcpu_e500->gtlb_priv[1][esel].ref.flags |= E500_TLB_BITMAP;
 	if (vcpu_e500->h2g_tlb1_rmap[sesel]) {
-		unsigned int idx = vcpu_e500->h2g_tlb1_rmap[sesel];
+		unsigned int idx = vcpu_e500->h2g_tlb1_rmap[sesel] - 1;
 		vcpu_e500->g2h_tlb1_map[idx] &= ~(1ULL << sesel);
 	}
-	vcpu_e500->h2g_tlb1_rmap[sesel] = esel;
+	vcpu_e500->h2g_tlb1_rmap[sesel] = esel + 1;
 
 	return sesel;
 }
-- 
1.6.0.2

[PATCH 5/7] kvm/ppc/e500: g2h_tlb1_map: clear old bit before setting new bit

[Alexander Graf]

From: Scott Wood <scottwood@freescale.com>

It's possible that we're using the same host TLB1 slot to map (a
presumably different portion of) the same guest TLB1 entry.  Clear
the bit in the map before setting it, so that if the esels are the same
the bit will remain set.

Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
---
 arch/powerpc/kvm/e500_mmu_host.c |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kvm/e500_mmu_host.c b/arch/powerpc/kvm/e500_mmu_host.c
index 35fb80e..8e72b21 100644
--- a/arch/powerpc/kvm/e500_mmu_host.c
+++ b/arch/powerpc/kvm/e500_mmu_host.c
@@ -507,13 +507,14 @@ static int kvmppc_e500_tlb1_map_tlb1(struct kvmppc_vcpu_e500 *vcpu_e500,
 	if (unlikely(vcpu_e500->host_tlb1_nv >= tlb1_max_shadow_size()))
 		vcpu_e500->host_tlb1_nv = 0;
 
-	vcpu_e500->tlb_refs[1][sesel] = *ref;
-	vcpu_e500->g2h_tlb1_map[esel] |= (u64)1 << sesel;
-	vcpu_e500->gtlb_priv[1][esel].ref.flags |= E500_TLB_BITMAP;
 	if (vcpu_e500->h2g_tlb1_rmap[sesel]) {
 		unsigned int idx = vcpu_e500->h2g_tlb1_rmap[sesel] - 1;
 		vcpu_e500->g2h_tlb1_map[idx] &= ~(1ULL << sesel);
 	}
+
+	vcpu_e500->tlb_refs[1][sesel] = *ref;
+	vcpu_e500->gtlb_priv[1][esel].ref.flags |= E500_TLB_BITMAP;
+	vcpu_e500->g2h_tlb1_map[esel] |= (u64)1 << sesel;
 	vcpu_e500->h2g_tlb1_rmap[sesel] = esel + 1;
 
 	return sesel;
-- 
1.6.0.2

[PATCH 6/7] kvm/ppc/e500: eliminate tlb_refs

[Alexander Graf]

From: Scott Wood <scottwood@freescale.com>

Commit 523f0e5421c12610527c620b983b443f329e3a32 ("KVM: PPC: E500:
Explicitly mark shadow maps invalid") began using E500_TLB_VALID
for guest TLB1 entries, and skipping invalidations if it's not set.

However, when E500_TLB_VALID was set for such entries, it was on a
fake local ref, and so the invalidations never happen.  gtlb_privs
is documented as being only for guest TLB0, though we already violate
that with E500_TLB_BITMAP.

Now that we have MMU notifiers, and thus don't need to actually
retain a reference to the mapped pages, get rid of tlb_refs, and
use gtlb_privs for E500_TLB_VALID in TLB1.

Since we can have more than one host TLB entry for a given tlbe_ref,
be careful not to clear existing flags that are relevant to other
host TLB entries when preparing a new host TLB entry.

Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
---
 arch/powerpc/kvm/e500.h          |   24 ++++--------
 arch/powerpc/kvm/e500_mmu_host.c |   75 +++++++++++---------------------------
 2 files changed, 30 insertions(+), 69 deletions(-)

diff --git a/arch/powerpc/kvm/e500.h b/arch/powerpc/kvm/e500.h
index 41cefd4..33db48a 100644
--- a/arch/powerpc/kvm/e500.h
+++ b/arch/powerpc/kvm/e500.h
@@ -26,17 +26,20 @@
 #define E500_PID_NUM   3
 #define E500_TLB_NUM   2
 
-#define E500_TLB_VALID 1
-#define E500_TLB_BITMAP 2
+/* entry is mapped somewhere in host TLB */
+#define E500_TLB_VALID		(1 << 0)
+/* TLB1 entry is mapped by host TLB1, tracked by bitmaps */
+#define E500_TLB_BITMAP		(1 << 1)
+/* TLB1 entry is mapped by host TLB0 */
 #define E500_TLB_TLB0		(1 << 2)
 
 struct tlbe_ref {
-	pfn_t pfn;
-	unsigned int flags; /* E500_TLB_* */
+	pfn_t pfn;		/* valid only for TLB0, except briefly */
+	unsigned int flags;	/* E500_TLB_* */
 };
 
 struct tlbe_priv {
-	struct tlbe_ref ref; /* TLB0 only -- TLB1 uses tlb_refs */
+	struct tlbe_ref ref;
 };
 
 #ifdef CONFIG_KVM_E500V2
@@ -63,17 +66,6 @@ struct kvmppc_vcpu_e500 {
 
 	unsigned int gtlb_nv[E500_TLB_NUM];
 
-	/*
-	 * information associated with each host TLB entry --
-	 * TLB1 only for now.  If/when guest TLB1 entries can be
-	 * mapped with host TLB0, this will be used for that too.
-	 *
-	 * We don't want to use this for guest TLB0 because then we'd
-	 * have the overhead of doing the translation again even if
-	 * the entry is still in the guest TLB (e.g. we swapped out
-	 * and back, and our host TLB entries got evicted).
-	 */
-	struct tlbe_ref *tlb_refs[E500_TLB_NUM];
 	unsigned int host_tlb1_nv;
 
 	u32 svr;
diff --git a/arch/powerpc/kvm/e500_mmu_host.c b/arch/powerpc/kvm/e500_mmu_host.c
index 8e72b21..1c6a9d7 100644
--- a/arch/powerpc/kvm/e500_mmu_host.c
+++ b/arch/powerpc/kvm/e500_mmu_host.c
@@ -193,8 +193,11 @@ void inval_gtlbe_on_host(struct kvmppc_vcpu_e500 *vcpu_e500, int tlbsel,
 	struct tlbe_ref *ref = &vcpu_e500->gtlb_priv[tlbsel][esel].ref;
 
 	/* Don't bother with unmapped entries */
-	if (!(ref->flags & E500_TLB_VALID))
-		return;
+	if (!(ref->flags & E500_TLB_VALID)) {
+		WARN(ref->flags & (E500_TLB_BITMAP | E500_TLB_TLB0),
+		     "%s: flags %x\n", __func__, ref->flags);
+		WARN_ON(tlbsel == 1 && vcpu_e500->g2h_tlb1_map[esel]);
+	}
 
 	if (tlbsel == 1 && ref->flags & E500_TLB_BITMAP) {
 		u64 tmp = vcpu_e500->g2h_tlb1_map[esel];
@@ -248,7 +251,7 @@ static inline void kvmppc_e500_ref_setup(struct tlbe_ref *ref,
 					 pfn_t pfn)
 {
 	ref->pfn = pfn;
-	ref->flags = E500_TLB_VALID;
+	ref->flags |= E500_TLB_VALID;
 
 	if (tlbe_is_writable(gtlbe))
 		kvm_set_pfn_dirty(pfn);
@@ -257,6 +260,7 @@ static inline void kvmppc_e500_ref_setup(struct tlbe_ref *ref,
 static inline void kvmppc_e500_ref_release(struct tlbe_ref *ref)
 {
 	if (ref->flags & E500_TLB_VALID) {
+		/* FIXME: don't log bogus pfn for TLB1 */
 		trace_kvm_booke206_ref_release(ref->pfn, ref->flags);
 		ref->flags = 0;
 	}
@@ -274,36 +278,23 @@ static void clear_tlb1_bitmap(struct kvmppc_vcpu_e500 *vcpu_e500)
 
 static void clear_tlb_privs(struct kvmppc_vcpu_e500 *vcpu_e500)
 {
-	int tlbsel = 0;
-	int i;
-
-	for (i = 0; i < vcpu_e500->gtlb_params[tlbsel].entries; i++) {
-		struct tlbe_ref *ref =
-			&vcpu_e500->gtlb_priv[tlbsel][i].ref;
-		kvmppc_e500_ref_release(ref);
-	}
-}
-
-static void clear_tlb_refs(struct kvmppc_vcpu_e500 *vcpu_e500)
-{
-	int stlbsel = 1;
+	int tlbsel;
 	int i;
 
-	kvmppc_e500_tlbil_all(vcpu_e500);
-
-	for (i = 0; i < host_tlb_params[stlbsel].entries; i++) {
-		struct tlbe_ref *ref =
-			&vcpu_e500->tlb_refs[stlbsel][i];
-		kvmppc_e500_ref_release(ref);
+	for (tlbsel = 0; tlbsel <= 1; tlbsel++) {
+		for (i = 0; i < vcpu_e500->gtlb_params[tlbsel].entries; i++) {
+			struct tlbe_ref *ref =
+				&vcpu_e500->gtlb_priv[tlbsel][i].ref;
+			kvmppc_e500_ref_release(ref);
+		}
 	}
-
-	clear_tlb_privs(vcpu_e500);
 }
 
 void kvmppc_core_flush_tlb(struct kvm_vcpu *vcpu)
 {
 	struct kvmppc_vcpu_e500 *vcpu_e500 = to_e500(vcpu);
-	clear_tlb_refs(vcpu_e500);
+	kvmppc_e500_tlbil_all(vcpu_e500);
+	clear_tlb_privs(vcpu_e500);
 	clear_tlb1_bitmap(vcpu_e500);
 }
 
@@ -458,8 +449,6 @@ static inline int kvmppc_e500_shadow_map(struct kvmppc_vcpu_e500 *vcpu_e500,
 		gvaddr &= ~((tsize_pages << PAGE_SHIFT) - 1);
 	}
 
-	/* Drop old ref and setup new one. */
-	kvmppc_e500_ref_release(ref);
 	kvmppc_e500_ref_setup(ref, gtlbe, pfn);
 
 	kvmppc_e500_setup_stlbe(&vcpu_e500->vcpu, gtlbe, tsize,
@@ -512,10 +501,10 @@ static int kvmppc_e500_tlb1_map_tlb1(struct kvmppc_vcpu_e500 *vcpu_e500,
 		vcpu_e500->g2h_tlb1_map[idx] &= ~(1ULL << sesel);
 	}
 
-	vcpu_e500->tlb_refs[1][sesel] = *ref;
 	vcpu_e500->gtlb_priv[1][esel].ref.flags |= E500_TLB_BITMAP;
 	vcpu_e500->g2h_tlb1_map[esel] |= (u64)1 << sesel;
 	vcpu_e500->h2g_tlb1_rmap[sesel] = esel + 1;
+	WARN_ON(!(ref->flags & E500_TLB_VALID));
 
 	return sesel;
 }
@@ -527,13 +516,12 @@ static int kvmppc_e500_tlb1_map(struct kvmppc_vcpu_e500 *vcpu_e500,
 		u64 gvaddr, gfn_t gfn, struct kvm_book3e_206_tlb_entry *gtlbe,
 		struct kvm_book3e_206_tlb_entry *stlbe, int esel)
 {
-	struct tlbe_ref ref;
+	struct tlbe_ref *ref = &vcpu_e500->gtlb_priv[1][esel].ref;
 	int sesel;
 	int r;
 
-	ref.flags = 0;
 	r = kvmppc_e500_shadow_map(vcpu_e500, gvaddr, gfn, gtlbe, 1, stlbe,
-				   &ref);
+				   ref);
 	if (r)
 		return r;
 
@@ -545,7 +533,7 @@ static int kvmppc_e500_tlb1_map(struct kvmppc_vcpu_e500 *vcpu_e500,
 	}
 
 	/* Otherwise map into TLB1 */
-	sesel = kvmppc_e500_tlb1_map_tlb1(vcpu_e500, &ref, esel);
+	sesel = kvmppc_e500_tlb1_map_tlb1(vcpu_e500, ref, esel);
 	write_stlbe(vcpu_e500, gtlbe, stlbe, 1, sesel);
 
 	return 0;
@@ -566,7 +554,7 @@ void kvmppc_mmu_map(struct kvm_vcpu *vcpu, u64 eaddr, gpa_t gpaddr,
 	case 0:
 		priv = &vcpu_e500->gtlb_priv[tlbsel][esel];
 
-		/* Triggers after clear_tlb_refs or on initial mapping */
+		/* Triggers after clear_tlb_privs or on initial mapping */
 		if (!(priv->ref.flags & E500_TLB_VALID)) {
 			kvmppc_e500_tlb0_map(vcpu_e500, esel, &stlbe);
 		} else {
@@ -666,35 +654,16 @@ int e500_mmu_host_init(struct kvmppc_vcpu_e500 *vcpu_e500)
 		host_tlb_params[0].entries / host_tlb_params[0].ways;
 	host_tlb_params[1].sets = 1;
 
-	vcpu_e500->tlb_refs[0] =
-		kzalloc(sizeof(struct tlbe_ref) * host_tlb_params[0].entries,
-			GFP_KERNEL);
-	if (!vcpu_e500->tlb_refs[0])
-		goto err;
-
-	vcpu_e500->tlb_refs[1] =
-		kzalloc(sizeof(struct tlbe_ref) * host_tlb_params[1].entries,
-			GFP_KERNEL);
-	if (!vcpu_e500->tlb_refs[1])
-		goto err;
-
 	vcpu_e500->h2g_tlb1_rmap = kzalloc(sizeof(unsigned int) *
 					   host_tlb_params[1].entries,
 					   GFP_KERNEL);
 	if (!vcpu_e500->h2g_tlb1_rmap)
-		goto err;
+		return -EINVAL;
 
 	return 0;
-
-err:
-	kfree(vcpu_e500->tlb_refs[0]);
-	kfree(vcpu_e500->tlb_refs[1]);
-	return -EINVAL;
 }
 
 void e500_mmu_host_uninit(struct kvmppc_vcpu_e500 *vcpu_e500)
 {
 	kfree(vcpu_e500->h2g_tlb1_rmap);
-	kfree(vcpu_e500->tlb_refs[0]);
-	kfree(vcpu_e500->tlb_refs[1]);
 }
-- 
1.6.0.2

[PATCH 7/7] KVM: PPC: Remove unused argument to kvmppc_core_dequeue_external

[Alexander Graf]

From: Paul Mackerras <paulus@samba.org>

Currently kvmppc_core_dequeue_external() takes a struct kvm_interrupt *
argument and does nothing with it, in any of its implementations.
This removes it in order to make things easier for forthcoming
in-kernel interrupt controller emulation code.

Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
---
 arch/powerpc/include/asm/kvm_ppc.h |    3 +--
 arch/powerpc/kvm/book3s.c          |    3 +--
 arch/powerpc/kvm/booke.c           |    3 +--
 arch/powerpc/kvm/powerpc.c         |    2 +-
 4 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/include/asm/kvm_ppc.h b/arch/powerpc/include/asm/kvm_ppc.h
index 44fa9ad..f589307 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -104,8 +104,7 @@ 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 void kvmppc_core_dequeue_external(struct kvm_vcpu *vcpu);
 extern void kvmppc_core_flush_tlb(struct kvm_vcpu *vcpu);
 
 extern int kvmppc_core_emulate_op(struct kvm_run *run, struct kvm_vcpu *vcpu,
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index a4b6452..6548445 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -160,8 +160,7 @@ void kvmppc_core_queue_external(struct kvm_vcpu *vcpu,
 	kvmppc_book3s_queue_irqprio(vcpu, vec);
 }
 
-void kvmppc_core_dequeue_external(struct kvm_vcpu *vcpu,
-                                  struct kvm_interrupt *irq)
+void kvmppc_core_dequeue_external(struct kvm_vcpu *vcpu)
 {
 	kvmppc_book3s_dequeue_irqprio(vcpu, BOOK3S_INTERRUPT_EXTERNAL);
 	kvmppc_book3s_dequeue_irqprio(vcpu, BOOK3S_INTERRUPT_EXTERNAL_LEVEL);
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 1182553..58057d6 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -222,8 +222,7 @@ void kvmppc_core_queue_external(struct kvm_vcpu *vcpu,
 	kvmppc_booke_queue_irqprio(vcpu, prio);
 }
 
-void kvmppc_core_dequeue_external(struct kvm_vcpu *vcpu,
-                                  struct kvm_interrupt *irq)
+void kvmppc_core_dequeue_external(struct kvm_vcpu *vcpu)
 {
 	clear_bit(BOOKE_IRQPRIO_EXTERNAL, &vcpu->arch.pending_exceptions);
 	clear_bit(BOOKE_IRQPRIO_EXTERNAL_LEVEL, &vcpu->arch.pending_exceptions);
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 7b5d4d2..16b4595 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -739,7 +739,7 @@ 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)
 {
 	if (irq->irq == KVM_INTERRUPT_UNSET) {
-		kvmppc_core_dequeue_external(vcpu, irq);
+		kvmppc_core_dequeue_external(vcpu);
 		return 0;
 	}
 
-- 
1.6.0.2

Re: [PULL 0/7] ppc patch queue 2013-03-22

[Gleb Natapov]

On Fri, Mar 22, 2013 at 03:25:56PM +0100, Alexander Graf wrote:
> Hi Marcelo / Gleb,
> 
> This is my current patch queue for ppc.  Please pull.
> 
> Changes include:
> 
>   - race-free in-kernel watchdog handling api
>   - e500 mmu fixes
> 
> Alex
> 
Pulled, thanks.

> 
> The following changes since commit 2ae33b389601b86a3d0cfe2d09f5e3189d5322fd:
>   Marcelo Tosatti (1):
>         Merge remote-tracking branch 'upstream/master' into queue
> 
> are available in the git repository at:
> 
>   git://github.com/agraf/linux-2.6.git kvm-ppc-next
> 
> Bharat Bhushan (3):
>       KVM: PPC: move tsr update in a separate function
>       KVM: PPC: Added one_reg interface for timer registers
>       KVM: PPC: booke: Added debug handler
> 
> Paul Mackerras (1):
>       KVM: PPC: Remove unused argument to kvmppc_core_dequeue_external
> 
> Scott Wood (3):
>       kvm/ppc/e500: h2g_tlb1_rmap: esel 0 is valid
>       kvm/ppc/e500: g2h_tlb1_map: clear old bit before setting new bit
>       kvm/ppc/e500: eliminate tlb_refs
> 
>  Documentation/virtual/kvm/api.txt   |    4 ++
>  arch/powerpc/include/asm/kvm_host.h |    1 +
>  arch/powerpc/include/asm/kvm_ppc.h  |    3 +-
>  arch/powerpc/include/uapi/asm/kvm.h |    5 ++
>  arch/powerpc/kernel/asm-offsets.c   |    1 +
>  arch/powerpc/kvm/book3s.c           |    3 +-
>  arch/powerpc/kvm/booke.c            |   57 +++++++++++++++++++-----
>  arch/powerpc/kvm/booke_interrupts.S |   42 ++++++++++++++++-
>  arch/powerpc/kvm/e500.h             |   24 +++-------
>  arch/powerpc/kvm/e500_mmu_host.c    |   84 +++++++++++-----------------------
>  arch/powerpc/kvm/powerpc.c          |    2 +-
>  11 files changed, 133 insertions(+), 93 deletions(-)

--
			Gleb.

Re: [PULL 0/7] ppc patch queue 2013-03-22

[Scott Wood]

On 03/22/2013 09:25:56 AM, Alexander Graf wrote:
> Hi Marcelo / Gleb,
> 
> This is my current patch queue for ppc.  Please pull.
> 
> Changes include:
> 
>   - race-free in-kernel watchdog handling api
>   - e500 mmu fixes
> 
> Alex
> 
> 
> The following changes since commit  
> 2ae33b389601b86a3d0cfe2d09f5e3189d5322fd:
>   Marcelo Tosatti (1):
>         Merge remote-tracking branch 'upstream/master' into queue
> 
> are available in the git repository at:
> 
>   git://github.com/agraf/linux-2.6.git kvm-ppc-next
> 
[snip]
> Scott Wood (3):
>       kvm/ppc/e500: h2g_tlb1_rmap: esel 0 is valid
>       kvm/ppc/e500: g2h_tlb1_map: clear old bit before setting new bit
>       kvm/ppc/e500: eliminate tlb_refs

-next?  These are bugfixes, at least partially for regressions from 3.8  
(that I pointed out before the bugs were merged!), that should go into  
master.

Also, what about:
http://patchwork.ozlabs.org/patch/226227/

You've got all four patches in kvm-ppc-3.9 as of a few weeks ago --  
will you be requesting a pull for that soon?

-Scott

Re: [PULL 0/7] ppc patch queue 2013-03-22

[Alexander Graf]

On 25.03.2013, at 23:21, Scott Wood wrote:

> On 03/22/2013 09:25:56 AM, Alexander Graf wrote:
>> Hi Marcelo / Gleb,
>> This is my current patch queue for ppc.  Please pull.
>> Changes include:
>>  - race-free in-kernel watchdog handling api
>>  - e500 mmu fixes
>> Alex
>> The following changes since commit 2ae33b389601b86a3d0cfe2d09f5e3189d5322fd:
>>  Marcelo Tosatti (1):
>>        Merge remote-tracking branch 'upstream/master' into queue
>> are available in the git repository at:
>>  git://github.com/agraf/linux-2.6.git kvm-ppc-next
> [snip]
>> Scott Wood (3):
>>      kvm/ppc/e500: h2g_tlb1_rmap: esel 0 is valid
>>      kvm/ppc/e500: g2h_tlb1_map: clear old bit before setting new bit
>>      kvm/ppc/e500: eliminate tlb_refs
> 
> -next?  These are bugfixes, at least partially for regressions from 3.8 (that I pointed out before the bugs were merged!), that should go into master.
> 
> Also, what about:
> http://patchwork.ozlabs.org/patch/226227/
> 
> You've got all four patches in kvm-ppc-3.9 as of a few weeks ago -- will you be requesting a pull for that soon?

Sigh. I guess I've screwed up the whole "let's make -next an unusable tree and fix regressions in a separate one" workflow again. Sorry for that.

Since the patches already trickled into kvm's next branch, all we can do now is to wait for them to come back through stable, right? Marcelo, Gleb?


Alex

Re: [PULL 0/7] ppc patch queue 2013-03-22

[Scott Wood]

On 03/25/2013 05:32:11 PM, Alexander Graf wrote:
> 
> On 25.03.2013, at 23:21, Scott Wood wrote:
> 
> > -next?  These are bugfixes, at least partially for regressions from  
> 3.8 (that I pointed out before the bugs were merged!), that should go  
> into master.
> >
> > Also, what about:
> > http://patchwork.ozlabs.org/patch/226227/
> >
> > You've got all four patches in kvm-ppc-3.9 as of a few weeks ago --  
> will you be requesting a pull for that soon?
> 
> Sigh. I guess I've screwed up the whole "let's make -next an unusable  
> tree and fix regressions in a separate one" workflow again. Sorry for  
> that.
> 
> Since the patches already trickled into kvm's next branch, all we can  
> do now is to wait for them to come back through stable, right?  
> Marcelo, Gleb?

Well, you can still submit that kvm-ppc-3.9 pull request. :-)

-Scott

Re: [PULL 0/7] ppc patch queue 2013-03-22

[Alexander Graf]

On 25.03.2013, at 23:54, Scott Wood wrote:

> On 03/25/2013 05:32:11 PM, Alexander Graf wrote:
>> On 25.03.2013, at 23:21, Scott Wood wrote:
>> > -next?  These are bugfixes, at least partially for regressions from 3.8 (that I pointed out before the bugs were merged!), that should go into master.
>> >
>> > Also, what about:
>> > http://patchwork.ozlabs.org/patch/226227/
>> >
>> > You've got all four patches in kvm-ppc-3.9 as of a few weeks ago -- will you be requesting a pull for that soon?
>> Sigh. I guess I've screwed up the whole "let's make -next an unusable tree and fix regressions in a separate one" workflow again. Sorry for that.
>> Since the patches already trickled into kvm's next branch, all we can do now is to wait for them to come back through stable, right? Marcelo, Gleb?
> 
> Well, you can still submit that kvm-ppc-3.9 pull request. :-)

I can, but nobody would pull it, as it'd create ugly merge commits when 3.10 opens and kvm/next and linus/master get merged. IIUC that's exactly what Linus complained about with Avi's old workflow.


Alex

Re: [PULL 0/7] ppc patch queue 2013-03-22

[Scott Wood]

On 03/25/2013 05:59:39 PM, Alexander Graf wrote:
> 
> On 25.03.2013, at 23:54, Scott Wood wrote:
> 
> > On 03/25/2013 05:32:11 PM, Alexander Graf wrote:
> >> On 25.03.2013, at 23:21, Scott Wood wrote:
> >> > -next?  These are bugfixes, at least partially for regressions  
> from 3.8 (that I pointed out before the bugs were merged!), that  
> should go into master.
> >> >
> >> > Also, what about:
> >> > http://patchwork.ozlabs.org/patch/226227/
> >> >
> >> > You've got all four patches in kvm-ppc-3.9 as of a few weeks ago  
> -- will you be requesting a pull for that soon?
> >> Sigh. I guess I've screwed up the whole "let's make -next an  
> unusable tree and fix regressions in a separate one" workflow again.  
> Sorry for that.
> >> Since the patches already trickled into kvm's next branch, all we  
> can do now is to wait for them to come back through stable, right?  
> Marcelo, Gleb?
> >
> > Well, you can still submit that kvm-ppc-3.9 pull request. :-)
> 
> I can, but nobody would pull it, as it'd create ugly merge commits  
> when 3.10 opens

That's a lousy excuse for leaving bugs unfixed.

-Scott

Re: [PULL 0/7] ppc patch queue 2013-03-22

[Alexander Graf]

On 26.03.2013, at 00:16, Scott Wood wrote:

> On 03/25/2013 05:59:39 PM, Alexander Graf wrote:
>> On 25.03.2013, at 23:54, Scott Wood wrote:
>> > On 03/25/2013 05:32:11 PM, Alexander Graf wrote:
>> >> On 25.03.2013, at 23:21, Scott Wood wrote:
>> >> > -next?  These are bugfixes, at least partially for regressions from 3.8 (that I pointed out before the bugs were merged!), that should go into master.
>> >> >
>> >> > Also, what about:
>> >> > http://patchwork.ozlabs.org/patch/226227/
>> >> >
>> >> > You've got all four patches in kvm-ppc-3.9 as of a few weeks ago -- will you be requesting a pull for that soon?
>> >> Sigh. I guess I've screwed up the whole "let's make -next an unusable tree and fix regressions in a separate one" workflow again. Sorry for that.
>> >> Since the patches already trickled into kvm's next branch, all we can do now is to wait for them to come back through stable, right? Marcelo, Gleb?
>> >
>> > Well, you can still submit that kvm-ppc-3.9 pull request. :-)
>> I can, but nobody would pull it, as it'd create ugly merge commits when 3.10 opens
> 
> That's a lousy excuse for leaving bugs unfixed.

I agree. So if it doesn't hurt to have the same commits in kvm/next and kvm/master, I'd be more than happy to send another pull request with the important fixes against kvm/master as well.


Alex

Re: [PULL 0/7] ppc patch queue 2013-03-22

[Gleb Natapov]

On Tue, Mar 26, 2013 at 12:35:09AM +0100, Alexander Graf wrote:
> 
> On 26.03.2013, at 00:16, Scott Wood wrote:
> 
> > On 03/25/2013 05:59:39 PM, Alexander Graf wrote:
> >> On 25.03.2013, at 23:54, Scott Wood wrote:
> >> > On 03/25/2013 05:32:11 PM, Alexander Graf wrote:
> >> >> On 25.03.2013, at 23:21, Scott Wood wrote:
> >> >> > -next?  These are bugfixes, at least partially for regressions from 3.8 (that I pointed out before the bugs were merged!), that should go into master.
> >> >> >
> >> >> > Also, what about:
> >> >> > http://patchwork.ozlabs.org/patch/226227/
> >> >> >
> >> >> > You've got all four patches in kvm-ppc-3.9 as of a few weeks ago -- will you be requesting a pull for that soon?
> >> >> Sigh. I guess I've screwed up the whole "let's make -next an unusable tree and fix regressions in a separate one" workflow again. Sorry for that.
> >> >> Since the patches already trickled into kvm's next branch, all we can do now is to wait for them to come back through stable, right? Marcelo, Gleb?
> >> >
> >> > Well, you can still submit that kvm-ppc-3.9 pull request. :-)
> >> I can, but nobody would pull it, as it'd create ugly merge commits when 3.10 opens
> > 
> > That's a lousy excuse for leaving bugs unfixed.
> 
> I agree. So if it doesn't hurt to have the same commits in kvm/next and kvm/master, I'd be more than happy to send another pull request with the important fixes against kvm/master as well.
> 
If it will result in the same commit showing twice in the Linus tree in 3.10 we cannot do that.

--
			Gleb.

Re: [PULL 0/7] ppc patch queue 2013-03-22

[Paul Mackerras]

On Tue, Mar 26, 2013 at 03:33:12AM +0200, Gleb Natapov wrote:
> On Tue, Mar 26, 2013 at 12:35:09AM +0100, Alexander Graf wrote:
> > I agree. So if it doesn't hurt to have the same commits in kvm/next and kvm/master, I'd be more than happy to send another pull request with the important fixes against kvm/master as well.
> > 
> If it will result in the same commit showing twice in the Linus tree in 3.10 we cannot do that.

Why not?  In the circumstances it seems perfectly reasonable to me.
Git should merge the branches without any problem, and even if it
doesn't, Linus is good at fixing merge conflicts.

Paul.

Re: [PULL 0/7] ppc patch queue 2013-03-22

[Marcelo Tosatti]

On Tue, Mar 26, 2013 at 12:59:04PM +1100, Paul Mackerras wrote:
> On Tue, Mar 26, 2013 at 03:33:12AM +0200, Gleb Natapov wrote:
> > On Tue, Mar 26, 2013 at 12:35:09AM +0100, Alexander Graf wrote:
> > > I agree. So if it doesn't hurt to have the same commits in kvm/next and kvm/master, I'd be more than happy to send another pull request with the important fixes against kvm/master as well.
> > > 
> > If it will result in the same commit showing twice in the Linus tree in 3.10 we cannot do that.
> 
> Why not?  In the circumstances it seems perfectly reasonable to me.
> Git should merge the branches without any problem, and even if it
> doesn't, Linus is good at fixing merge conflicts.
> 
> Paul.

Yes, should avoid duplicate commits but its not fatal for them to exist.

Re: [PULL 0/7] ppc patch queue 2013-03-22

[Alexander Graf]

On 11.04.2013, at 15:45, Marcelo Tosatti wrote:

> On Tue, Mar 26, 2013 at 12:59:04PM +1100, Paul Mackerras wrote:
>> On Tue, Mar 26, 2013 at 03:33:12AM +0200, Gleb Natapov wrote:
>>> On Tue, Mar 26, 2013 at 12:35:09AM +0100, Alexander Graf wrote:
>>>> I agree. So if it doesn't hurt to have the same commits in kvm/next and kvm/master, I'd be more than happy to send another pull request with the important fixes against kvm/master as well.
>>>> 
>>> If it will result in the same commit showing twice in the Linus tree in 3.10 we cannot do that.
>> 
>> Why not?  In the circumstances it seems perfectly reasonable to me.
>> Git should merge the branches without any problem, and even if it
>> doesn't, Linus is good at fixing merge conflicts.
>> 
>> Paul.
> 
> Yes, should avoid duplicate commits but its not fatal for them to exist.

So I may send a pull request against 3.9 with the 3 commits that already are in kvm/next?


Alex

Re: [PULL 0/7] ppc patch queue 2013-03-22

[Marcelo Tosatti]

On Thu, Apr 11, 2013 at 03:50:13PM +0200, Alexander Graf wrote:
> 
> On 11.04.2013, at 15:45, Marcelo Tosatti wrote:
> 
> > On Tue, Mar 26, 2013 at 12:59:04PM +1100, Paul Mackerras wrote:
> >> On Tue, Mar 26, 2013 at 03:33:12AM +0200, Gleb Natapov wrote:
> >>> On Tue, Mar 26, 2013 at 12:35:09AM +0100, Alexander Graf wrote:
> >>>> I agree. So if it doesn't hurt to have the same commits in kvm/next and kvm/master, I'd be more than happy to send another pull request with the important fixes against kvm/master as well.
> >>>> 
> >>> If it will result in the same commit showing twice in the Linus tree in 3.10 we cannot do that.
> >> 
> >> Why not?  In the circumstances it seems perfectly reasonable to me.
> >> Git should merge the branches without any problem, and even if it
> >> doesn't, Linus is good at fixing merge conflicts.
> >> 
> >> Paul.
> > 
> > Yes, should avoid duplicate commits but its not fatal for them to exist.
> 
> So I may send a pull request against 3.9 with the 3 commits that already are in kvm/next?

If you decide that the fixes are important enough to justify the
existance of duplicate commits, i don't see a problem.

http://yarchive.net/comp/linux/git_rebase.html

"In fact, we have always had duplicated commits even when they are
passed around as email - just because perhaps two different trees simply
needed the same fix, and rather than wait for it, they both integrated
it (and then when they get merged, the same patch exists twice in the
history, just with different committer info etc)."

Re: [PULL 0/7] ppc patch queue 2013-03-22

[Alexander Graf]

On 12.04.2013, at 22:54, Marcelo Tosatti wrote:

> On Thu, Apr 11, 2013 at 03:50:13PM +0200, Alexander Graf wrote:
>> 
>> On 11.04.2013, at 15:45, Marcelo Tosatti wrote:
>> 
>>> On Tue, Mar 26, 2013 at 12:59:04PM +1100, Paul Mackerras wrote:
>>>> On Tue, Mar 26, 2013 at 03:33:12AM +0200, Gleb Natapov wrote:
>>>>> On Tue, Mar 26, 2013 at 12:35:09AM +0100, Alexander Graf wrote:
>>>>>> I agree. So if it doesn't hurt to have the same commits in kvm/next and kvm/master, I'd be more than happy to send another pull request with the important fixes against kvm/master as well.
>>>>>> 
>>>>> If it will result in the same commit showing twice in the Linus tree in 3.10 we cannot do that.
>>>> 
>>>> Why not?  In the circumstances it seems perfectly reasonable to me.
>>>> Git should merge the branches without any problem, and even if it
>>>> doesn't, Linus is good at fixing merge conflicts.
>>>> 
>>>> Paul.
>>> 
>>> Yes, should avoid duplicate commits but its not fatal for them to exist.
>> 
>> So I may send a pull request against 3.9 with the 3 commits that already are in kvm/next?
> 
> If you decide that the fixes are important enough to justify the
> existance of duplicate commits, i don't see a problem.

Great :). I already sent the pull request out with all patches that fix regressions.


Alex

Re: [PULL 0/7] ppc patch queue 2013-03-22

[Alexander Graf]

On 12.04.2013, at 22:56, Alexander Graf wrote:

> 
> On 12.04.2013, at 22:54, Marcelo Tosatti wrote:
> 
>> On Thu, Apr 11, 2013 at 03:50:13PM +0200, Alexander Graf wrote:
>>> 
>>> On 11.04.2013, at 15:45, Marcelo Tosatti wrote:
>>> 
>>>> On Tue, Mar 26, 2013 at 12:59:04PM +1100, Paul Mackerras wrote:
>>>>> On Tue, Mar 26, 2013 at 03:33:12AM +0200, Gleb Natapov wrote:
>>>>>> On Tue, Mar 26, 2013 at 12:35:09AM +0100, Alexander Graf wrote:
>>>>>>> I agree. So if it doesn't hurt to have the same commits in kvm/next and kvm/master, I'd be more than happy to send another pull request with the important fixes against kvm/master as well.
>>>>>>> 
>>>>>> If it will result in the same commit showing twice in the Linus tree in 3.10 we cannot do that.
>>>>> 
>>>>> Why not?  In the circumstances it seems perfectly reasonable to me.
>>>>> Git should merge the branches without any problem, and even if it
>>>>> doesn't, Linus is good at fixing merge conflicts.
>>>>> 
>>>>> Paul.
>>>> 
>>>> Yes, should avoid duplicate commits but its not fatal for them to exist.
>>> 
>>> So I may send a pull request against 3.9 with the 3 commits that already are in kvm/next?
>> 
>> If you decide that the fixes are important enough to justify the
>> existance of duplicate commits, i don't see a problem.
> 
> Great :). I already sent the pull request out with all patches that fix regressions.

Ping? Did these go to Linus?


Alex

Re: [PULL 0/7] ppc patch queue 2013-03-22

[Marcelo Tosatti]

On Tue, Apr 16, 2013 at 07:26:35PM +0200, Alexander Graf wrote:
> >>> So I may send a pull request against 3.9 with the 3 commits that already are in kvm/next?
> >> 
> >> If you decide that the fixes are important enough to justify the
> >> existance of duplicate commits, i don't see a problem.
> > 
> > Great :). I already sent the pull request out with all patches that fix regressions.
> 
> Ping? Did these go to Linus?

Waiting on Christoffer Dall to generate ARM fixes against kvm.git master
branch.

Re: [PULL 0/7] ppc patch queue 2013-03-22

[Scott Wood]

On 03/25/2013 08:33:12 PM, Gleb Natapov wrote:
> On Tue, Mar 26, 2013 at 12:35:09AM +0100, Alexander Graf wrote:
> >
> > On 26.03.2013, at 00:16, Scott Wood wrote:
> >
> > > On 03/25/2013 05:59:39 PM, Alexander Graf wrote:
> > >> On 25.03.2013, at 23:54, Scott Wood wrote:
> > >> > On 03/25/2013 05:32:11 PM, Alexander Graf wrote:
> > >> >> On 25.03.2013, at 23:21, Scott Wood wrote:
> > >> >> > -next?  These are bugfixes, at least partially for  
> regressions from 3.8 (that I pointed out before the bugs were  
> merged!), that should go into master.
> > >> >> >
> > >> >> > Also, what about:
> > >> >> > http://patchwork.ozlabs.org/patch/226227/
> > >> >> >
> > >> >> > You've got all four patches in kvm-ppc-3.9 as of a few  
> weeks ago -- will you be requesting a pull for that soon?
> > >> >> Sigh. I guess I've screwed up the whole "let's make -next an  
> unusable tree and fix regressions in a separate one" workflow again.  
> Sorry for that.
> > >> >> Since the patches already trickled into kvm's next branch,  
> all we can do now is to wait for them to come back through stable,  
> right? Marcelo, Gleb?
> > >> >
> > >> > Well, you can still submit that kvm-ppc-3.9 pull request. :-)
> > >> I can, but nobody would pull it, as it'd create ugly merge  
> commits when 3.10 opens
> > >
> > > That's a lousy excuse for leaving bugs unfixed.
> >
> > I agree. So if it doesn't hurt to have the same commits in kvm/next  
> and kvm/master, I'd be more than happy to send another pull request  
> with the important fixes against kvm/master as well.
> >
> If it will result in the same commit showing twice in the Linus tree  
> in 3.10 we cannot do that.

Why?

-Scott

Re: [PULL 0/7] ppc patch queue 2013-03-22

[Gleb Natapov]

On Tue, Mar 26, 2013 at 11:37:42AM -0500, Scott Wood wrote:
> On 03/25/2013 08:33:12 PM, Gleb Natapov wrote:
> >On Tue, Mar 26, 2013 at 12:35:09AM +0100, Alexander Graf wrote:
> >>
> >> On 26.03.2013, at 00:16, Scott Wood wrote:
> >>
> >> > On 03/25/2013 05:59:39 PM, Alexander Graf wrote:
> >> >> On 25.03.2013, at 23:54, Scott Wood wrote:
> >> >> > On 03/25/2013 05:32:11 PM, Alexander Graf wrote:
> >> >> >> On 25.03.2013, at 23:21, Scott Wood wrote:
> >> >> >> > -next?  These are bugfixes, at least partially for
> >regressions from 3.8 (that I pointed out before the bugs were
> >merged!), that should go into master.
> >> >> >> >
> >> >> >> > Also, what about:
> >> >> >> > http://patchwork.ozlabs.org/patch/226227/
> >> >> >> >
> >> >> >> > You've got all four patches in kvm-ppc-3.9 as of a few
> >weeks ago -- will you be requesting a pull for that soon?
> >> >> >> Sigh. I guess I've screwed up the whole "let's make -next
> >an unusable tree and fix regressions in a separate one" workflow
> >again. Sorry for that.
> >> >> >> Since the patches already trickled into kvm's next branch,
> >all we can do now is to wait for them to come back through stable,
> >right? Marcelo, Gleb?
> >> >> >
> >> >> > Well, you can still submit that kvm-ppc-3.9 pull request. :-)
> >> >> I can, but nobody would pull it, as it'd create ugly merge
> >commits when 3.10 opens
> >> >
> >> > That's a lousy excuse for leaving bugs unfixed.
> >>
> >> I agree. So if it doesn't hurt to have the same commits in
> >kvm/next and kvm/master, I'd be more than happy to send another
> >pull request with the important fixes against kvm/master as well.
> >>
> >If it will result in the same commit showing twice in the Linus
> >tree in 3.10 we cannot do that.
> 
> Why?
> 
Because Linus distastes it and mat refuse to pull. There is a way to avoid
such double commits: push fix to Linus tree and merge it back to next.

--
			Gleb.

Re: [PULL 0/7] ppc patch queue 2013-03-22

[Alexander Graf]

On 31.03.2013, at 12:49, Gleb Natapov wrote:

> On Tue, Mar 26, 2013 at 11:37:42AM -0500, Scott Wood wrote:
>> On 03/25/2013 08:33:12 PM, Gleb Natapov wrote:
>>> On Tue, Mar 26, 2013 at 12:35:09AM +0100, Alexander Graf wrote:
>>>> 
>>>> On 26.03.2013, at 00:16, Scott Wood wrote:
>>>> 
>>>>> On 03/25/2013 05:59:39 PM, Alexander Graf wrote:
>>>>>> On 25.03.2013, at 23:54, Scott Wood wrote:
>>>>>>> On 03/25/2013 05:32:11 PM, Alexander Graf wrote:
>>>>>>>> On 25.03.2013, at 23:21, Scott Wood wrote:
>>>>>>>>> -next?  These are bugfixes, at least partially for
>>> regressions from 3.8 (that I pointed out before the bugs were
>>> merged!), that should go into master.
>>>>>>>>> 
>>>>>>>>> Also, what about:
>>>>>>>>> http://patchwork.ozlabs.org/patch/226227/
>>>>>>>>> 
>>>>>>>>> You've got all four patches in kvm-ppc-3.9 as of a few
>>> weeks ago -- will you be requesting a pull for that soon?
>>>>>>>> Sigh. I guess I've screwed up the whole "let's make -next
>>> an unusable tree and fix regressions in a separate one" workflow
>>> again. Sorry for that.
>>>>>>>> Since the patches already trickled into kvm's next branch,
>>> all we can do now is to wait for them to come back through stable,
>>> right? Marcelo, Gleb?
>>>>>>> 
>>>>>>> Well, you can still submit that kvm-ppc-3.9 pull request. :-)
>>>>>> I can, but nobody would pull it, as it'd create ugly merge
>>> commits when 3.10 opens
>>>>> 
>>>>> That's a lousy excuse for leaving bugs unfixed.
>>>> 
>>>> I agree. So if it doesn't hurt to have the same commits in
>>> kvm/next and kvm/master, I'd be more than happy to send another
>>> pull request with the important fixes against kvm/master as well.
>>>> 
>>> If it will result in the same commit showing twice in the Linus
>>> tree in 3.10 we cannot do that.
>> 
>> Why?
>> 
> Because Linus distastes it and mat refuse to pull. There is a way to avoid
> such double commits: push fix to Linus tree and merge it back to next.

Yes, that's the normal workflow. But what if we screw up (like I did)? Does having a working 3.9 kernel win over double commits in the tree? I'd say yes, but it might be best to just ask Linus directly.

Linus, I accidentally sent a pull request including fixes that were meant for master for kvm/next which got accepted. Now we have those commits in there. However, I would prefer if we could have them in master, so that we have a known good 3.9 kernel for kvm on powerpc.

I could send another pull request against master, but that would mean that after merging things back on the next merge window, there would be a few duplicate commits in the history.

Do you think that's a big no-go, or would you be ok with duplicate commits in case of an occasional screwup?


Thanks,

Alex

Re: [PULL 0/7] ppc patch queue 2013-03-22

[Scott Wood]

On 03/31/2013 06:05:40 AM, Alexander Graf wrote:
> 
> On 31.03.2013, at 12:49, Gleb Natapov wrote:
> 
> > On Tue, Mar 26, 2013 at 11:37:42AM -0500, Scott Wood wrote:
> >> On 03/25/2013 08:33:12 PM, Gleb Natapov wrote:
> >>> On Tue, Mar 26, 2013 at 12:35:09AM +0100, Alexander Graf wrote:
> >>>>
> >>>> On 26.03.2013, at 00:16, Scott Wood wrote:
> >>>>
> >>>>> On 03/25/2013 05:59:39 PM, Alexander Graf wrote:
> >>>>>> On 25.03.2013, at 23:54, Scott Wood wrote:
> >>>>>>> On 03/25/2013 05:32:11 PM, Alexander Graf wrote:
> >>>>>>>> On 25.03.2013, at 23:21, Scott Wood wrote:
> >>>>>>>>> -next?  These are bugfixes, at least partially for
> >>> regressions from 3.8 (that I pointed out before the bugs were
> >>> merged!), that should go into master.
> >>>>>>>>>
> >>>>>>>>> Also, what about:
> >>>>>>>>> http://patchwork.ozlabs.org/patch/226227/
> >>>>>>>>>
> >>>>>>>>> You've got all four patches in kvm-ppc-3.9 as of a few
> >>> weeks ago -- will you be requesting a pull for that soon?
> >>>>>>>> Sigh. I guess I've screwed up the whole "let's make -next
> >>> an unusable tree and fix regressions in a separate one" workflow
> >>> again. Sorry for that.
> >>>>>>>> Since the patches already trickled into kvm's next branch,
> >>> all we can do now is to wait for them to come back through stable,
> >>> right? Marcelo, Gleb?
> >>>>>>>
> >>>>>>> Well, you can still submit that kvm-ppc-3.9 pull request. :-)
> >>>>>> I can, but nobody would pull it, as it'd create ugly merge
> >>> commits when 3.10 opens
> >>>>>
> >>>>> That's a lousy excuse for leaving bugs unfixed.
> >>>>
> >>>> I agree. So if it doesn't hurt to have the same commits in
> >>> kvm/next and kvm/master, I'd be more than happy to send another
> >>> pull request with the important fixes against kvm/master as well.
> >>>>
> >>> If it will result in the same commit showing twice in the Linus
> >>> tree in 3.10 we cannot do that.
> >>
> >> Why?
> >>
> > Because Linus distastes it and mat refuse to pull. There is a way  
> to avoid
> > such double commits: push fix to Linus tree and merge it back to  
> next.
> 
> Yes, that's the normal workflow. But what if we screw up (like I  
> did)? Does having a working 3.9 kernel win over double commits in the  
> tree? I'd say yes, but it might be best to just ask Linus directly.
> 
> Linus, I accidentally sent a pull request including fixes that were  
> meant for master for kvm/next which got accepted. Now we have those  
> commits in there. However, I would prefer if we could have them in  
> master, so that we have a known good 3.9 kernel for kvm on powerpc.
> 
> I could send another pull request against master, but that would mean  
> that after merging things back on the next merge window, there would  
> be a few duplicate commits in the history.
> 
> Do you think that's a big no-go, or would you be ok with duplicate  
> commits in case of an occasional screwup?

It doesn't look like there's much time left before 3.9 is released (rc6  
was released yesterday, and Linus said he expects rc7 to be the last),  
so could we come to a conclusion on this soon?  While I think it's  
ridiculous that "the same commit showing twice" would be a reason to  
let regressions go unfixed[1], at the very least please request a pull  
for the fourth bugfix patch, which should also go into 3.8 stable, and  
which did not go into the "next" branch (so no "duplicate commit" issue  
there).  If that doesn't make it into 3.9, it will likely never make it  
into 3.8 stable because there will be no more 3.8 stable releases at  
that point.

-Scott

[1] It doesn't help that the bugfix patches were posted almost two  
months ago, before the patches that introduced the bug were merged...