linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: "Cédric Le Goater" <clg@kaod.org>
Cc: linuxppc-dev@lists.ozlabs.org,
	Michael Ellerman <mpe@ellerman.id.au>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	nikunj@linux.vnet.ibm.com
Subject: Re: [PATCH 0/2] powerpc/xive: fix CPU hot unplug
Date: Tue, 3 Oct 2017 17:58:58 +1100	[thread overview]
Message-ID: <20171003065858.GL3260@umbus.fritz.box> (raw)
In-Reply-To: <7f2081f1-415a-85ca-29ed-3ab1467220a7@kaod.org>

[-- Attachment #1: Type: text/plain, Size: 3994 bytes --]

On Tue, Oct 03, 2017 at 08:24:07AM +0200, Cédric Le Goater wrote:
> On 10/03/2017 05:36 AM, David Gibson wrote:
> > On Mon, Oct 02, 2017 at 06:27:20PM +0200, Cédric Le Goater wrote:
> >> On 09/23/2017 10:26 AM, Cédric Le Goater wrote:
> >>> Hi,
> >>>
> >>> Here are a couple of small fixes to support CPU hot unplug. There are
> >>> still some issues to be investigated as, in some occasions, after a
> >>> couple of plug and unplug, the cpu which was removed receives a 'lost'
> >>> interrupt. This showed to be the decrementer under QEMU.
> >>
> >> So this seems to be a QEMU issue only which can be solved by 
> >> removing the DEE bit from the LPCR on P9 processor when the CPU 
> >> is stopped in rtas. PECE3 bit on P8 processors. 
> >>
> >> I think these patches are valuable fixes for 4.14. The first 
> >> is trivial and the second touches the common xive part but it
> >> is only called on the pseries platform.  
> >>
> >> Could you please take a look ?
> > 
> > Sorry, I think I've missed something here.
> > 
> > Is there a qemu bug involved in this?  Has there been a patch sent
> > that I didn't spot?
> 
> 
> No, not yet, but I will today probably. something like below to stop
> the decrementer when a CPU is stopped:
> 
> 	--- qemu.git.orig/hw/ppc/spapr_rtas.c
> 	+++ qemu.git/hw/ppc/spapr_rtas.c
> 	@@ -174,6 +174,15 @@ static void rtas_start_cpu(PowerPCCPU *c
> 	         kvm_cpu_synchronize_state(cs);
> 	 
> 	         env->msr = (1ULL << MSR_SF) | (1ULL << MSR_ME);
> 	+
> 	+        /* Enable DECR interrupt */
> 	+        if (env->mmu_model == POWERPC_MMU_3_00) {
> 	+            env->spr[SPR_LPCR] |= LPCR_DEE;
> 	+        } else {
> 	+            /* P7 and P8 both have same bit for DECR */
> 	+            env->spr[SPR_LPCR] |= LPCR_P8_PECE3;
> 	+        }
> 	+
> 	         env->nip = start;
> 	         env->gpr[3] = r3;
> 	         cs->halted = 0;
> 	@@ -210,6 +219,13 @@ static void rtas_stop_self(PowerPCCPU *c
> 	      * no need to bother with specific bits, we just clear it.
> 	      */
> 	     env->msr = 0;
> 	+
> 	+    if (env->mmu_model == POWERPC_MMU_3_00) {
> 	+        env->spr[SPR_LPCR] &= ~LPCR_DEE;
> 	+    } else {
> 	+        /* P7 and P8 both have same bit for DECR */
> 	+        env->spr[SPR_LPCR] &= ~LPCR_P8_PECE3;
> 	+    }
> 	 }
> 	 
> 	 static inline int sysparm_st(target_ulong addr, target_ulong len,
> 	
> I haven't yet because I fail to understand why the decrementer is not 
> interrupting the dying CPU under xics as it is the case under XIVE.

Oh.. ok.  This sounds very similar to the problem Nikunj hit under TCG
with decrementer interrupts waking up a supposedly dead CPU.  He had a
couple of proposed fixes, but we got bogged down trying to work out
why  (with TCG at least) it only seemed to bite after a system_reset,
and not on initial boot up.

> Also I am not sure this hack is of any use :
> 
>     /*
>      * While stopping a CPU, the guest calls H_CPPR which
>      * effectively disables interrupts on XICS level.
>      * However decrementer interrupts in TCG can still
>      * wake the CPU up so here we disable interrupts in MSR
>      * as well.
>      * As rtas_start_cpu() resets the whole MSR anyway, there is
>      * no need to bother with specific bits, we just clear it.
>      */
>     env->msr = 0;

Ok.. why do you think this isn't of use?  I'm pretty sure this is
necessary for the TCG case, since MSR is checked in cpu_has_work(),
which could otherwise wake up the "dead" cpu.

> and the different CPU states are confusing. Nikunj already to a look
> at this when trying to fix the TCG reboot. Anyway, the QEMU patch 
> should (re)start a thread. This is not the place to discuss.
> 
> Thanks,
> 
> C.  
> 
> 

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2017-10-03  6:59 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-23  8:26 [PATCH 0/2] powerpc/xive: fix CPU hot unplug Cédric Le Goater
2017-09-23  8:26 ` [PATCH 1/2] powerpc/xive: fix IPI reset Cédric Le Goater
2017-09-23  8:26 ` [PATCH 2/2] powerpc/xive: fix cpu removal Cédric Le Goater
2017-10-02 16:27 ` [PATCH 0/2] powerpc/xive: fix CPU hot unplug Cédric Le Goater
2017-10-02 16:52   ` Benjamin Herrenschmidt
2017-10-02 17:53     ` Cédric Le Goater
2017-10-03  3:36   ` David Gibson
2017-10-03  6:24     ` Cédric Le Goater
2017-10-03  6:58       ` David Gibson [this message]
2017-10-03  8:22         ` Benjamin Herrenschmidt
2017-10-04 14:48         ` Cédric Le Goater
2017-10-05  3:29         ` Nikunj A Dadhania
2017-10-05  8:18           ` Cédric Le Goater
2017-10-03 11:23   ` Michael Ellerman
2017-10-03 12:58     ` Cédric Le Goater

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=20171003065858.GL3260@umbus.fritz.box \
    --to=david@gibson.dropbear.id.au \
    --cc=benh@kernel.crashing.org \
    --cc=clg@kaod.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=nikunj@linux.vnet.ibm.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).