* [PATCH 1/5] KVM: PPC: Book3S: PR: Handle EMUL_ASSIST
2012-05-16 13:05 [PULL 0/5] ppc patch queue 2012-05-16 Alexander Graf
@ 2012-05-16 13:05 ` Alexander Graf
2012-05-16 13:05 ` [PATCH 2/5] KVM: PPC: Fix PR KVM on POWER7 bare metal Alexander Graf
` (4 subsequent siblings)
5 siblings, 0 replies; 9+ messages in thread
From: Alexander Graf @ 2012-05-16 13:05 UTC (permalink / raw)
To: kvm@vger.kernel.org list; +Cc: Avi Kivity, kvm-ppc, mtosatti
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
^ permalink raw reply related [flat|nested] 9+ messages in thread* [PATCH 2/5] KVM: PPC: Fix PR KVM on POWER7 bare metal
2012-05-16 13:05 [PULL 0/5] ppc patch queue 2012-05-16 Alexander Graf
2012-05-16 13:05 ` [PATCH 1/5] KVM: PPC: Book3S: PR: Handle EMUL_ASSIST Alexander Graf
@ 2012-05-16 13:05 ` Alexander Graf
2012-05-16 13:05 ` [PATCH 3/5] KVM: PPC: Book3S: PR: Fix hsrr code Alexander Graf
` (3 subsequent siblings)
5 siblings, 0 replies; 9+ messages in thread
From: Alexander Graf @ 2012-05-16 13:05 UTC (permalink / raw)
To: kvm@vger.kernel.org list; +Cc: Avi Kivity, kvm-ppc, mtosatti
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
^ permalink raw reply related [flat|nested] 9+ messages in thread* [PATCH 3/5] KVM: PPC: Book3S: PR: Fix hsrr code
2012-05-16 13:05 [PULL 0/5] ppc patch queue 2012-05-16 Alexander Graf
2012-05-16 13:05 ` [PATCH 1/5] KVM: PPC: Book3S: PR: Handle EMUL_ASSIST Alexander Graf
2012-05-16 13:05 ` [PATCH 2/5] KVM: PPC: Fix PR KVM on POWER7 bare metal Alexander Graf
@ 2012-05-16 13:05 ` Alexander Graf
2012-05-16 13:05 ` [PATCH 4/5] powerpc/kvm: Fix VSID usage in 64-bit "PR" KVM Alexander Graf
` (2 subsequent siblings)
5 siblings, 0 replies; 9+ messages in thread
From: Alexander Graf @ 2012-05-16 13:05 UTC (permalink / raw)
To: kvm@vger.kernel.org list; +Cc: Avi Kivity, kvm-ppc, mtosatti
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
^ permalink raw reply related [flat|nested] 9+ messages in thread* [PATCH 4/5] powerpc/kvm: Fix VSID usage in 64-bit "PR" KVM
2012-05-16 13:05 [PULL 0/5] ppc patch queue 2012-05-16 Alexander Graf
` (2 preceding siblings ...)
2012-05-16 13:05 ` [PATCH 3/5] KVM: PPC: Book3S: PR: Fix hsrr code Alexander Graf
@ 2012-05-16 13:05 ` Alexander Graf
2012-05-16 13:05 ` [PATCH 5/5] KVM: PPC: Book3S HV: Fix bug leading to deadlock in guest HPT updates Alexander Graf
2012-05-16 13:23 ` [PULL 0/5] ppc patch queue 2012-05-16 Avi Kivity
5 siblings, 0 replies; 9+ messages in thread
From: Alexander Graf @ 2012-05-16 13:05 UTC (permalink / raw)
To: kvm@vger.kernel.org list
Cc: Avi Kivity, kvm-ppc, mtosatti, Benjamin Herrenschmidt
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
^ permalink raw reply related [flat|nested] 9+ messages in thread* [PATCH 5/5] KVM: PPC: Book3S HV: Fix bug leading to deadlock in guest HPT updates
2012-05-16 13:05 [PULL 0/5] ppc patch queue 2012-05-16 Alexander Graf
` (3 preceding siblings ...)
2012-05-16 13:05 ` [PATCH 4/5] powerpc/kvm: Fix VSID usage in 64-bit "PR" KVM Alexander Graf
@ 2012-05-16 13:05 ` Alexander Graf
2012-05-16 13:23 ` [PULL 0/5] ppc patch queue 2012-05-16 Avi Kivity
5 siblings, 0 replies; 9+ messages in thread
From: Alexander Graf @ 2012-05-16 13:05 UTC (permalink / raw)
To: kvm@vger.kernel.org list; +Cc: Avi Kivity, kvm-ppc, mtosatti, Paul Mackerras
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
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [PULL 0/5] ppc patch queue 2012-05-16
2012-05-16 13:05 [PULL 0/5] ppc patch queue 2012-05-16 Alexander Graf
` (4 preceding siblings ...)
2012-05-16 13:05 ` [PATCH 5/5] KVM: PPC: Book3S HV: Fix bug leading to deadlock in guest HPT updates Alexander Graf
@ 2012-05-16 13:23 ` Avi Kivity
2012-05-16 13:28 ` Alexander Graf
5 siblings, 1 reply; 9+ messages in thread
From: Avi Kivity @ 2012-05-16 13:23 UTC (permalink / raw)
To: Alexander Graf; +Cc: kvm@vger.kernel.org list, kvm-ppc, mtosatti
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
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PULL 0/5] ppc patch queue 2012-05-16
2012-05-16 13:23 ` [PULL 0/5] ppc patch queue 2012-05-16 Avi Kivity
@ 2012-05-16 13:28 ` Alexander Graf
2012-05-16 13:34 ` Avi Kivity
0 siblings, 1 reply; 9+ messages in thread
From: Alexander Graf @ 2012-05-16 13:28 UTC (permalink / raw)
To: Avi Kivity; +Cc: kvm@vger.kernel.org list, kvm-ppc, mtosatti
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PULL 0/5] ppc patch queue 2012-05-16
2012-05-16 13:28 ` Alexander Graf
@ 2012-05-16 13:34 ` Avi Kivity
0 siblings, 0 replies; 9+ messages in thread
From: Avi Kivity @ 2012-05-16 13:34 UTC (permalink / raw)
To: Alexander Graf; +Cc: kvm@vger.kernel.org list, kvm-ppc, mtosatti
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
^ permalink raw reply [flat|nested] 9+ messages in thread