From: Alistair Popple <alistair@popple.id.au>
To: Jordan Niethe <jniethe5@gmail.com>
Cc: aik@ozlabs.ru, patch-notifications@ellerman.id.au,
linuxppc-dev@lists.ozlabs.org, kvm-ppc@vger.kernel.org
Subject: Re: [PATCH] powerpc/kvm: Fix kvmppc_vcore->in_guest value in kvmhv_switch_to_host
Date: Mon, 07 Oct 2019 23:25:30 +0000 [thread overview]
Message-ID: <3982154.yavEZ9r0OR@townsend> (raw)
In-Reply-To: <20191004025317.19340-1-jniethe5@gmail.com>
On Friday, 4 October 2019 12:53:17 PM AEDT Jordan Niethe wrote:
> kvmhv_switch_to_host() in arch/powerpc/kvm/book3s_hv_rmhandlers.S needs
> to set kvmppc_vcore->in_guest to 0 to signal secondary CPUs to continue.
> This happens after resetting the PCR. Before commit 13c7bb3c57dc
> ("powerpc/64s: Set reserved PCR bits"), r0 would always be 0 before it
> was stored to kvmppc_vcore->in_guest. However because of this change in
> the commit:
>
> /* Reset PCR */
> ld r0, VCORE_PCR(r5)
> - cmpdi r0, 0
> + LOAD_REG_IMMEDIATE(r6, PCR_MASK)
> + cmpld r0, r6
> beq 18f
> - li r0, 0
> - mtspr SPRN_PCR, r0
> + mtspr SPRN_PCR, r6
> 18:
> /* Signal secondary CPUs to continue */
> stb r0,VCORE_IN_GUEST(r5)
Easy to understand how that was missed :-)
Reviewed-by: Alistair Popple <alistair@popple.id.au>
> We are no longer comparing r0 against 0 and loading it with 0 if it
> contains something else. Hence when we store r0 to
> kvmppc_vcore->in_guest, it might not be 0. This means that secondary
> CPUs will not be signalled to continue. Those CPUs get stuck and errors
> like the following are logged:
>
> KVM: CPU 1 seems to be stuck
> KVM: CPU 2 seems to be stuck
> KVM: CPU 3 seems to be stuck
> KVM: CPU 4 seems to be stuck
> KVM: CPU 5 seems to be stuck
> KVM: CPU 6 seems to be stuck
> KVM: CPU 7 seems to be stuck
>
> This can be reproduced with:
> $ for i in `seq 1 7` ; do chcpu -d $i ; done ;
> $ taskset -c 0 qemu-system-ppc64 -smp 8,threads=8 \
> -M pseries,accel=kvm,kvm-type=HV -m 1G -nographic -vga none \
> -kernel vmlinux -initrd initrd.cpio.xz
>
> Fix by making sure r0 is 0 before storing it to kvmppc_vcore->in_guest.
>
> Fixes: 13c7bb3c57dc ("powerpc/64s: Set reserved PCR bits")
> Reported-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
> ---
> arch/powerpc/kvm/book3s_hv_rmhandlers.S | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> index 74a9cfe84aee..faebcbb8c4db 100644
> --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> @@ -1921,6 +1921,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
> mtspr SPRN_PCR, r6
> 18:
> /* Signal secondary CPUs to continue */
> + li r0, 0
> stb r0,VCORE_IN_GUEST(r5)
> 19: lis r8,0x7fff /* MAX_INT@h */
> mtspr SPRN_HDEC,r8
>
WARNING: multiple messages have this Message-ID (diff)
From: Alistair Popple <alistair@popple.id.au>
To: Jordan Niethe <jniethe5@gmail.com>
Cc: aik@ozlabs.ru, patch-notifications@ellerman.id.au,
linuxppc-dev@lists.ozlabs.org, kvm-ppc@vger.kernel.org
Subject: Re: [PATCH] powerpc/kvm: Fix kvmppc_vcore->in_guest value in kvmhv_switch_to_host
Date: Tue, 08 Oct 2019 10:25:30 +1100 [thread overview]
Message-ID: <3982154.yavEZ9r0OR@townsend> (raw)
In-Reply-To: <20191004025317.19340-1-jniethe5@gmail.com>
On Friday, 4 October 2019 12:53:17 PM AEDT Jordan Niethe wrote:
> kvmhv_switch_to_host() in arch/powerpc/kvm/book3s_hv_rmhandlers.S needs
> to set kvmppc_vcore->in_guest to 0 to signal secondary CPUs to continue.
> This happens after resetting the PCR. Before commit 13c7bb3c57dc
> ("powerpc/64s: Set reserved PCR bits"), r0 would always be 0 before it
> was stored to kvmppc_vcore->in_guest. However because of this change in
> the commit:
>
> /* Reset PCR */
> ld r0, VCORE_PCR(r5)
> - cmpdi r0, 0
> + LOAD_REG_IMMEDIATE(r6, PCR_MASK)
> + cmpld r0, r6
> beq 18f
> - li r0, 0
> - mtspr SPRN_PCR, r0
> + mtspr SPRN_PCR, r6
> 18:
> /* Signal secondary CPUs to continue */
> stb r0,VCORE_IN_GUEST(r5)
Easy to understand how that was missed :-)
Reviewed-by: Alistair Popple <alistair@popple.id.au>
> We are no longer comparing r0 against 0 and loading it with 0 if it
> contains something else. Hence when we store r0 to
> kvmppc_vcore->in_guest, it might not be 0. This means that secondary
> CPUs will not be signalled to continue. Those CPUs get stuck and errors
> like the following are logged:
>
> KVM: CPU 1 seems to be stuck
> KVM: CPU 2 seems to be stuck
> KVM: CPU 3 seems to be stuck
> KVM: CPU 4 seems to be stuck
> KVM: CPU 5 seems to be stuck
> KVM: CPU 6 seems to be stuck
> KVM: CPU 7 seems to be stuck
>
> This can be reproduced with:
> $ for i in `seq 1 7` ; do chcpu -d $i ; done ;
> $ taskset -c 0 qemu-system-ppc64 -smp 8,threads=8 \
> -M pseries,accel=kvm,kvm-type=HV -m 1G -nographic -vga none \
> -kernel vmlinux -initrd initrd.cpio.xz
>
> Fix by making sure r0 is 0 before storing it to kvmppc_vcore->in_guest.
>
> Fixes: 13c7bb3c57dc ("powerpc/64s: Set reserved PCR bits")
> Reported-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
> ---
> arch/powerpc/kvm/book3s_hv_rmhandlers.S | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> index 74a9cfe84aee..faebcbb8c4db 100644
> --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> @@ -1921,6 +1921,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
> mtspr SPRN_PCR, r6
> 18:
> /* Signal secondary CPUs to continue */
> + li r0, 0
> stb r0,VCORE_IN_GUEST(r5)
> 19: lis r8,0x7fff /* MAX_INT@h */
> mtspr SPRN_HDEC,r8
>
next prev parent reply other threads:[~2019-10-07 23:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-04 2:53 [PATCH] powerpc/kvm: Fix kvmppc_vcore->in_guest value in kvmhv_switch_to_host Jordan Niethe
2019-10-04 2:53 ` Jordan Niethe
2019-10-04 2:58 ` Alistair Popple
2019-10-04 2:58 ` Alistair Popple
2019-10-05 2:26 ` Alexey Kardashevskiy
2019-10-05 2:26 ` Alexey Kardashevskiy
2019-10-07 23:25 ` Alistair Popple [this message]
2019-10-07 23:25 ` Alistair Popple
2019-10-11 8:22 ` Michael Ellerman
2019-10-11 8:22 ` Michael Ellerman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3982154.yavEZ9r0OR@townsend \
--to=alistair@popple.id.au \
--cc=aik@ozlabs.ru \
--cc=jniethe5@gmail.com \
--cc=kvm-ppc@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=patch-notifications@ellerman.id.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.