From: Suzuki.Poulose@arm.com (Suzuki K. Poulose)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 2/6] arm64: Move kill_cpu_early to smp.c
Date: Tue, 1 Dec 2015 17:38:54 +0000 [thread overview]
Message-ID: <565DDB2E.2010308@arm.com> (raw)
In-Reply-To: <20151201163138.GA29045@leverpostej>
On 01/12/15 16:31, Mark Rutland wrote:
> For PSCI 0.2+ we can query AFFINITY_INFO to discover whether a CPU is
> whether or not it is in the firmware (i.e. whether or not it is
> potentially in the kernel), so we can certainly query this in some
> cases.
>
> We already do this in the usual hotplug-off case; see cpu_kill.
OK, good to know.
>> Correct, I didn't think about kexec. May be we could indicate the result
>> back (that we are looping in kernel) in secondary_data and that could solve
>> the synchronisation part ?
>
> I think we need to have two flags, a cpu-must-die flag in secondary
> data, and a global stuck-in-the-kernel flag.
>
> The CPU wanting to die could set its cpu-must-die flag, signal the
> completion, then cpu_die(). The CPU awaiting the completion would then
> check cpu-must-die, and if so, cpu_kill() that CPU. If not set, we had a
> successful onlining.
Correct.
>
> We need stuck-in-the-kernel flag to account for CPUs which didn't manage
> to turn the MMU on (which are either in the spin-table, or failed when
> they were individually onlined).
Did you mean to say "turn the MMU off" ?
Cheers
Suzuki
WARNING: multiple messages have this Message-ID (diff)
From: "Suzuki K. Poulose" <Suzuki.Poulose@arm.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, marc.zyngier@arm.com,
linux-kernel@vger.kernel.org, will.deacon@arm.com,
catalin.marinas@arm.com
Subject: Re: [PATCH v2 2/6] arm64: Move kill_cpu_early to smp.c
Date: Tue, 1 Dec 2015 17:38:54 +0000 [thread overview]
Message-ID: <565DDB2E.2010308@arm.com> (raw)
In-Reply-To: <20151201163138.GA29045@leverpostej>
On 01/12/15 16:31, Mark Rutland wrote:
> For PSCI 0.2+ we can query AFFINITY_INFO to discover whether a CPU is
> whether or not it is in the firmware (i.e. whether or not it is
> potentially in the kernel), so we can certainly query this in some
> cases.
>
> We already do this in the usual hotplug-off case; see cpu_kill.
OK, good to know.
>> Correct, I didn't think about kexec. May be we could indicate the result
>> back (that we are looping in kernel) in secondary_data and that could solve
>> the synchronisation part ?
>
> I think we need to have two flags, a cpu-must-die flag in secondary
> data, and a global stuck-in-the-kernel flag.
>
> The CPU wanting to die could set its cpu-must-die flag, signal the
> completion, then cpu_die(). The CPU awaiting the completion would then
> check cpu-must-die, and if so, cpu_kill() that CPU. If not set, we had a
> successful onlining.
Correct.
>
> We need stuck-in-the-kernel flag to account for CPUs which didn't manage
> to turn the MMU on (which are either in the spin-table, or failed when
> they were individually onlined).
Did you mean to say "turn the MMU off" ?
Cheers
Suzuki
next prev parent reply other threads:[~2015-12-01 17:38 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-01 15:12 [PATCH v2 0/6] arm64: cpufeature: Add sanity check for ASIDBits Suzuki K. Poulose
2015-12-01 15:12 ` Suzuki K. Poulose
2015-12-01 15:12 ` [PATCH v2 1/6] arm64: Introduce kill_cpu_early Suzuki K. Poulose
2015-12-01 15:12 ` Suzuki K. Poulose
2015-12-01 15:12 ` [PATCH v2 2/6] arm64: Move kill_cpu_early to smp.c Suzuki K. Poulose
2015-12-01 15:12 ` Suzuki K. Poulose
2015-12-01 15:28 ` Mark Rutland
2015-12-01 15:28 ` Mark Rutland
2015-12-01 16:07 ` Suzuki K. Poulose
2015-12-01 16:07 ` Suzuki K. Poulose
2015-12-01 16:31 ` Mark Rutland
2015-12-01 16:31 ` Mark Rutland
2015-12-01 17:38 ` Suzuki K. Poulose [this message]
2015-12-01 17:38 ` Suzuki K. Poulose
2015-12-01 17:52 ` Mark Rutland
2015-12-01 17:52 ` Mark Rutland
2015-12-01 18:10 ` Suzuki K. Poulose
2015-12-01 18:10 ` Suzuki K. Poulose
2015-12-01 18:50 ` Mark Rutland
2015-12-01 18:50 ` Mark Rutland
2015-12-03 16:36 ` Suzuki K. Poulose
2015-12-03 16:36 ` Suzuki K. Poulose
2015-12-03 17:08 ` Mark Rutland
2015-12-03 17:08 ` Mark Rutland
2015-12-01 15:12 ` [PATCH v2 3/6] arm64: Enable CPU capability verification for !CONFIG_HOTPLUG_CPU Suzuki K. Poulose
2015-12-01 15:12 ` Suzuki K. Poulose
2015-12-01 15:12 ` [PATCH v2 4/6] arm64: Add hook for checking early CPU features Suzuki K. Poulose
2015-12-01 15:12 ` Suzuki K. Poulose
2015-12-01 15:12 ` [PATCH v2 5/6] arm64: Add helper for extracting ASIDBits Suzuki K. Poulose
2015-12-01 15:12 ` Suzuki K. Poulose
2015-12-01 15:12 ` [PATCH v2 6/6] arm64: Ensure the secondary CPUs have safe ASIDBits size Suzuki K. Poulose
2015-12-01 15:12 ` Suzuki K. Poulose
2015-12-01 15:15 ` [PATCH v2 0/6] arm64: cpufeature: Add sanity check for ASIDBits Suzuki K. Poulose
2015-12-01 15:15 ` Suzuki K. Poulose
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=565DDB2E.2010308@arm.com \
--to=suzuki.poulose@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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.