[PULL 0/5] ppc patch queue 2012-05-16

[PULL 0/5] ppc patch queue 2012-05-16

[Alexander Graf]

Hi Avi,

There are a few bugs in 3.4 that really should be fixed before people can
be all happy and fuzzy about KVM on PowerPC. These fixes are:

  * fix POWER7 bare metal with PR=y
  * fix deadlock on HV=y book3s_64 mode in low memory cases
  * fix invalid MMU scope of PR=y mode on book3s_64, possibly
    leading to memory corruption

This request and the patches are based on top of Linus's master branch. Please
either send these to Linus to get them into 3.4.0 or to linux-stable if it's too
late already.

Alex

The following changes since commit 568b44559d7ca269d367e694c74eb4436e7e3ccf:
  Srivatsa S. Bhat (1):
        mn10300/CPU hotplug: Add missing call to notify_cpu_starting()

are available in the git repository at:

  git://github.com/agraf/linux-2.6.git for-upstream-3.4

Alexander Graf (3):
      KVM: PPC: Book3S: PR: Handle EMUL_ASSIST
      KVM: PPC: Fix PR KVM on POWER7 bare metal
      KVM: PPC: Book3S: PR: Fix hsrr code

Benjamin Herrenschmidt (1):
      powerpc/kvm: Fix VSID usage in 64-bit "PR" KVM

Paul Mackerras (1):
      KVM: PPC: Book3S HV: Fix bug leading to deadlock in guest HPT updates

 arch/powerpc/include/asm/kvm_book3s.h |    7 +++--
 arch/powerpc/kvm/book3s_64_mmu_host.c |   13 +++++----
 arch/powerpc/kvm/book3s_hv_rm_mmu.c   |    1 +
 arch/powerpc/kvm/book3s_segment.S     |   42 ++++++++++++++++++++++-----------
 4 files changed, 40 insertions(+), 23 deletions(-)

[PATCH 1/5] KVM: PPC: Book3S: PR: Handle EMUL_ASSIST

[Alexander Graf]

In addition to normal "priviledged instruction" traps, we can also receive
"emulation assist" traps on newer hardware that has the HV bit set.

Handle that one the same way as a privileged instruction, including the
instruction fetching. That way we don't execute old instructions that we
happen to still leave in that field when an emul assist trap comes.

This fixes -M mac99 / -M g3beige on p7 bare metal for me.

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

diff --git a/arch/powerpc/kvm/book3s_segment.S b/arch/powerpc/kvm/book3s_segment.S
index 0676ae2..012fc92 100644
--- a/arch/powerpc/kvm/book3s_segment.S
+++ b/arch/powerpc/kvm/book3s_segment.S
@@ -250,6 +250,12 @@ END_FTR_SECTION_IFSET(CPU_FTR_HVMODE)
 	beq	ld_last_prev_inst
 	cmpwi	r12, BOOK3S_INTERRUPT_ALIGNMENT
 	beq-	ld_last_inst
+#ifdef CONFIG_PPC64
+BEGIN_FTR_SECTION
+	cmpwi	r12, BOOK3S_INTERRUPT_H_EMUL_ASSIST
+	beq-	ld_last_inst
+END_FTR_SECTION_IFSET(CPU_FTR_HVMODE)
+#endif
 
 	b	no_ld_last_inst
 
-- 
1.6.0.2

[PATCH 2/5] KVM: PPC: Fix PR KVM on POWER7 bare metal

[Alexander Graf]

When running on a system that is HV capable, some interrupts use HSRR
SPRs instead of the normal SRR SPRs. These are also used in the Linux
handlers to jump back to code after an interrupt got processed.

Unfortunately, in our "jump back to the real host handler after we've
done the context switch" code, we were only setting the SRR SPRs,
rendering Linux to jump back to some invalid IP after it's processed
the interrupt.

This fixes random crashes on p7 opal mode with PR KVM for me.

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

diff --git a/arch/powerpc/kvm/book3s_segment.S b/arch/powerpc/kvm/book3s_segment.S
index 012fc92..87cfc1d 100644
--- a/arch/powerpc/kvm/book3s_segment.S
+++ b/arch/powerpc/kvm/book3s_segment.S
@@ -197,6 +197,7 @@ kvmppc_interrupt:
 	/* Save guest PC and MSR */
 #ifdef CONFIG_PPC64
 BEGIN_FTR_SECTION
+	mr	r10, r12
 	andi.	r0,r12,0x2
 	beq	1f
 	mfspr	r3,SPRN_HSRR0
@@ -322,23 +323,17 @@ no_dcbz32_off:
 	 * Having set up SRR0/1 with the address where we want
 	 * to continue with relocation on (potentially in module
 	 * space), we either just go straight there with rfi[d],
-	 * or we jump to an interrupt handler with bctr if there
-	 * is an interrupt to be handled first.  In the latter
-	 * case, the rfi[d] at the end of the interrupt handler
-	 * will get us back to where we want to continue.
+	 * or we jump to an interrupt handler if there is an
+	 * interrupt to be handled first.  In the latter case,
+	 * the rfi[d] at the end of the interrupt handler will
+	 * get us back to where we want to continue.
 	 */
 
-	cmpwi	r12, BOOK3S_INTERRUPT_EXTERNAL
-	beq	1f
-	cmpwi	r12, BOOK3S_INTERRUPT_DECREMENTER
-	beq	1f
-	cmpwi	r12, BOOK3S_INTERRUPT_PERFMON
-1:	mtctr	r12
-
 	/* Register usage at this point:
 	 *
 	 * R1       = host R1
 	 * R2       = host R2
+	 * R10      = raw exit handler id
 	 * R12      = exit handler id
 	 * R13      = shadow vcpu (32-bit) or PACA (64-bit)
 	 * SVCPU.*  = guest *
@@ -348,12 +343,26 @@ no_dcbz32_off:
 	PPC_LL	r6, HSTATE_HOST_MSR(r13)
 	PPC_LL	r8, HSTATE_VMHANDLER(r13)
 
-	/* Restore host msr -> SRR1 */
+#ifdef CONFIG_PPC64
+BEGIN_FTR_SECTION
+	andi.	r0,r10,0x2
+	beq	1f
+	mtspr	SPRN_HSRR1, r6
+	mtspr	SPRN_HSRR0, r8
+END_FTR_SECTION_IFSET(CPU_FTR_HVMODE)
+#endif
+1:	/* Restore host msr -> SRR1 */
 	mtsrr1	r6
 	/* Load highmem handler address */
 	mtsrr0	r8
 
 	/* RFI into the highmem handler, or jump to interrupt handler */
-	beqctr
+	cmpwi	r12, BOOK3S_INTERRUPT_EXTERNAL
+	beqa	BOOK3S_INTERRUPT_EXTERNAL
+	cmpwi	r12, BOOK3S_INTERRUPT_DECREMENTER
+	beqa	BOOK3S_INTERRUPT_DECREMENTER
+	cmpwi	r12, BOOK3S_INTERRUPT_PERFMON
+	beqa	BOOK3S_INTERRUPT_PERFMON
+
 	RFI
 kvmppc_handler_trampoline_exit_end:
-- 
1.6.0.2

[PATCH 3/5] KVM: PPC: Book3S: PR: Fix hsrr code

[Alexander Graf]

When jumping back into the kernel to code that knows that it would be
using HSRR registers instead of SRR registers, we need to make sure we
pass it all information on where to jump to in HSRR registers.

Unfortunately, we used r10 to store the information to distinguish between
the HSRR and SRR case. That register got clobbered in between though,
rendering the later comparison invalid.

Instead, let's use cr1 to store this information. That way we don't
need yet another register and everyone's happy.

This fixes PR KVM on POWER7 bare metal for me.

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

diff --git a/arch/powerpc/kvm/book3s_segment.S b/arch/powerpc/kvm/book3s_segment.S
index 87cfc1d..6e6e9ce 100644
--- a/arch/powerpc/kvm/book3s_segment.S
+++ b/arch/powerpc/kvm/book3s_segment.S
@@ -197,8 +197,8 @@ kvmppc_interrupt:
 	/* Save guest PC and MSR */
 #ifdef CONFIG_PPC64
 BEGIN_FTR_SECTION
-	mr	r10, r12
-	andi.	r0,r12,0x2
+	andi.	r0, r12, 0x2
+	cmpwi	cr1, r0, 0
 	beq	1f
 	mfspr	r3,SPRN_HSRR0
 	mfspr	r4,SPRN_HSRR1
@@ -345,8 +345,7 @@ no_dcbz32_off:
 
 #ifdef CONFIG_PPC64
 BEGIN_FTR_SECTION
-	andi.	r0,r10,0x2
-	beq	1f
+	beq	cr1, 1f
 	mtspr	SPRN_HSRR1, r6
 	mtspr	SPRN_HSRR0, r8
 END_FTR_SECTION_IFSET(CPU_FTR_HVMODE)
-- 
1.6.0.2

[PATCH 4/5] powerpc/kvm: Fix VSID usage in 64-bit "PR" KVM

[Alexander Graf]

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>

The code forgot to scramble the VSIDs the way we normally do
and was basically using the "proto VSID" directly with the MMU.

This means that in practice, KVM used random VSIDs that could
collide with segments used by other user space programs.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[agraf: simplify ppc32 case]
Signed-off-by: Alexander Graf <agraf@suse.de>
---
 arch/powerpc/include/asm/kvm_book3s.h |    7 ++++---
 arch/powerpc/kvm/book3s_64_mmu_host.c |   13 +++++++------
 2 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/arch/powerpc/include/asm/kvm_book3s.h b/arch/powerpc/include/asm/kvm_book3s.h
index aa795cc..fd07f43 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -81,12 +81,13 @@ struct kvmppc_vcpu_book3s {
 	u64 sdr1;
 	u64 hior;
 	u64 msr_mask;
-	u64 vsid_next;
 #ifdef CONFIG_PPC_BOOK3S_32
 	u32 vsid_pool[VSID_POOL_SIZE];
+	u32 vsid_next;
 #else
-	u64 vsid_first;
-	u64 vsid_max;
+	u64 proto_vsid_first;
+	u64 proto_vsid_max;
+	u64 proto_vsid_next;
 #endif
 	int context_id[SID_CONTEXTS];
 
diff --git a/arch/powerpc/kvm/book3s_64_mmu_host.c b/arch/powerpc/kvm/book3s_64_mmu_host.c
index 6f87f39..10fc8ec 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_host.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_host.c
@@ -194,14 +194,14 @@ static struct kvmppc_sid_map *create_sid_map(struct kvm_vcpu *vcpu, u64 gvsid)
 	backwards_map = !backwards_map;
 
 	/* Uh-oh ... out of mappings. Let's flush! */
-	if (vcpu_book3s->vsid_next = vcpu_book3s->vsid_max) {
-		vcpu_book3s->vsid_next = vcpu_book3s->vsid_first;
+	if (vcpu_book3s->proto_vsid_next = vcpu_book3s->proto_vsid_max) {
+		vcpu_book3s->proto_vsid_next = vcpu_book3s->proto_vsid_first;
 		memset(vcpu_book3s->sid_map, 0,
 		       sizeof(struct kvmppc_sid_map) * SID_MAP_NUM);
 		kvmppc_mmu_pte_flush(vcpu, 0, 0);
 		kvmppc_mmu_flush_segments(vcpu);
 	}
-	map->host_vsid = vcpu_book3s->vsid_next++;
+	map->host_vsid = vsid_scramble(vcpu_book3s->proto_vsid_next++, 256M);
 
 	map->guest_vsid = gvsid;
 	map->valid = true;
@@ -319,9 +319,10 @@ int kvmppc_mmu_init(struct kvm_vcpu *vcpu)
 		return -1;
 	vcpu3s->context_id[0] = err;
 
-	vcpu3s->vsid_max = ((vcpu3s->context_id[0] + 1) << USER_ESID_BITS) - 1;
-	vcpu3s->vsid_first = vcpu3s->context_id[0] << USER_ESID_BITS;
-	vcpu3s->vsid_next = vcpu3s->vsid_first;
+	vcpu3s->proto_vsid_max = ((vcpu3s->context_id[0] + 1)
+				  << USER_ESID_BITS) - 1;
+	vcpu3s->proto_vsid_first = vcpu3s->context_id[0] << USER_ESID_BITS;
+	vcpu3s->proto_vsid_next = vcpu3s->proto_vsid_first;
 
 	kvmppc_mmu_hpte_init(vcpu);
 
-- 
1.6.0.2

[PATCH 5/5] KVM: PPC: Book3S HV: Fix bug leading to deadlock in guest HPT updates

[Alexander Graf]

From: Paul Mackerras <paulus@samba.org>

When handling the H_BULK_REMOVE hypercall, we were forgetting to
invalidate and unlock the hashed page table entry (HPTE) in the case
where the page had been paged out.  This fixes it by clearing the
first doubleword of the HPTE in that case.

This fixes a regression introduced in commit a92bce95f0 ("KVM: PPC:
Book3S HV: Keep HPTE locked when invalidating").  The effect of the
regression is that the host kernel will sometimes hang when under
memory pressure.

Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
---
 arch/powerpc/kvm/book3s_hv_rm_mmu.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/kvm/book3s_hv_rm_mmu.c b/arch/powerpc/kvm/book3s_hv_rm_mmu.c
index def880a..cec4dad 100644
--- a/arch/powerpc/kvm/book3s_hv_rm_mmu.c
+++ b/arch/powerpc/kvm/book3s_hv_rm_mmu.c
@@ -463,6 +463,7 @@ long kvmppc_h_bulk_remove(struct kvm_vcpu *vcpu)
 				/* insert R and C bits from PTE */
 				rcbits = rev->guest_rpte & (HPTE_R_R|HPTE_R_C);
 				args[j] |= rcbits << (56 - 5);
+				hp[0] = 0;
 				continue;
 			}
 
-- 
1.6.0.2

Re: [PULL 0/5] ppc patch queue 2012-05-16

[Avi Kivity]

On 05/16/2012 04:05 PM, Alexander Graf wrote:
> Hi Avi,
>
> There are a few bugs in 3.4 that really should be fixed before people can
> be all happy and fuzzy about KVM on PowerPC. These fixes are:
>
>   * fix POWER7 bare metal with PR=y
>   * fix deadlock on HV=y book3s_64 mode in low memory cases
>   * fix invalid MMU scope of PR=y mode on book3s_64, possibly
>     leading to memory corruption
>
> This request and the patches are based on top of Linus's master branch. Please
> either send these to Linus to get them into 3.4.0 or to linux-stable if it's too
> late already.
>
> Alex
>
> The following changes since commit 568b44559d7ca269d367e694c74eb4436e7e3ccf:
>   Srivatsa S. Bhat (1):
>         mn10300/CPU hotplug: Add missing call to notify_cpu_starting()
>
> are available in the git repository at:
>
>   git://github.com/agraf/linux-2.6.git for-upstream-3.4
>
> Alexander Graf (3):
>       KVM: PPC: Book3S: PR: Handle EMUL_ASSIST
>       KVM: PPC: Fix PR KVM on POWER7 bare metal
>

This one is already in 'next', which means it's queued for 3.5.  While
it won't bring about the end of the universe, please try to avoid this
in the future by selecting the right branch to push into in advance
(that's one of the consequences of the new workflow).

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

Re: [PULL 0/5] ppc patch queue 2012-05-16

[Alexander Graf]

On 05/16/2012 03:23 PM, Avi Kivity wrote:
> On 05/16/2012 04:05 PM, Alexander Graf wrote:
>> Hi Avi,
>>
>> There are a few bugs in 3.4 that really should be fixed before people can
>> be all happy and fuzzy about KVM on PowerPC. These fixes are:
>>
>>    * fix POWER7 bare metal with PR=y
>>    * fix deadlock on HV=y book3s_64 mode in low memory cases
>>    * fix invalid MMU scope of PR=y mode on book3s_64, possibly
>>      leading to memory corruption
>>
>> This request and the patches are based on top of Linus's master branch. Please
>> either send these to Linus to get them into 3.4.0 or to linux-stable if it's too
>> late already.
>>
>> Alex
>>
>> The following changes since commit 568b44559d7ca269d367e694c74eb4436e7e3ccf:
>>    Srivatsa S. Bhat (1):
>>          mn10300/CPU hotplug: Add missing call to notify_cpu_starting()
>>
>> are available in the git repository at:
>>
>>    git://github.com/agraf/linux-2.6.git for-upstream-3.4
>>
>> Alexander Graf (3):
>>        KVM: PPC: Book3S: PR: Handle EMUL_ASSIST
>>        KVM: PPC: Fix PR KVM on POWER7 bare metal
>>
> This one is already in 'next', which means it's queued for 3.5.  While
> it won't bring about the end of the universe, please try to avoid this
> in the future by selecting the right branch to push into in advance
> (that's one of the consequences of the new workflow).

Hm. I figured that there's a pretty high chance that the patches won't 
make it for 3.4.0, so they'd have to go into 3.4-stable, which then 
again means it's a lot easier to see which ones are still outstanding 
there. I still maintain a -next queue in parallel where patches destined 
for 3.5 go into.

Which workflow would you prefer if not the one above?


Alex

Re: [PULL 0/5] ppc patch queue 2012-05-16

[Avi Kivity]

On 05/16/2012 04:28 PM, Alexander Graf wrote:
> On 05/16/2012 03:23 PM, Avi Kivity wrote:
>> On 05/16/2012 04:05 PM, Alexander Graf wrote:
>>> Hi Avi,
>>>
>>> There are a few bugs in 3.4 that really should be fixed before
>>> people can
>>> be all happy and fuzzy about KVM on PowerPC. These fixes are:
>>>
>>>    * fix POWER7 bare metal with PR=y
>>>    * fix deadlock on HV=y book3s_64 mode in low memory cases
>>>    * fix invalid MMU scope of PR=y mode on book3s_64, possibly
>>>      leading to memory corruption
>>>
>>> This request and the patches are based on top of Linus's master
>>> branch. Please
>>> either send these to Linus to get them into 3.4.0 or to linux-stable
>>> if it's too
>>> late already.
>>>
>>> Alex
>>>
>>> The following changes since commit
>>> 568b44559d7ca269d367e694c74eb4436e7e3ccf:
>>>    Srivatsa S. Bhat (1):
>>>          mn10300/CPU hotplug: Add missing call to notify_cpu_starting()
>>>
>>> are available in the git repository at:
>>>
>>>    git://github.com/agraf/linux-2.6.git for-upstream-3.4
>>>
>>> Alexander Graf (3):
>>>        KVM: PPC: Book3S: PR: Handle EMUL_ASSIST
>>>        KVM: PPC: Fix PR KVM on POWER7 bare metal
>>>
>> This one is already in 'next', which means it's queued for 3.5.  While
>> it won't bring about the end of the universe, please try to avoid this
>> in the future by selecting the right branch to push into in advance
>> (that's one of the consequences of the new workflow).
>
> Hm. I figured that there's a pretty high chance that the patches won't
> make it for 3.4.0, so they'd have to go into 3.4-stable, which then
> again means it's a lot easier to see which ones are still outstanding
> there. I still maintain a -next queue in parallel where patches
> destined for 3.5 go into.
>
> Which workflow would you prefer if not the one above?
>

For -rc/-stable patches, avoid queueing.  If you have a patch, post it
to the maintainers ASAP.  It then becomes our problem (and a smaller
problem too, since the less delays there are, the bigger the chances of
making the intended release).  A few days are fine of course.

For mainstream patches, queuing is fine, but don't overdo it please.  I
enjoy pulling from you and am quite willing to pull several times per cycle.

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