Thread (1 message) 1 message, 1 author, 2019-08-12

Re: [PATCH] arm64: smp: disable hotplug on trusted OS resident CPU

From: Sudeep Holla <hidden>
Date: 2019-08-12 17:11:13

Hi Will,

(sorry for responding so late, I seem to have lost your reply and
when I saw the patch today in my git, searched and saw this reply)

On Mon, Aug 12, 2019 at 06:00:52PM +0100, Sudeep Holla wrote:
On 13/06/2019 10:14, Will Deacon wrote:
quoted
Hi Sudeep.

On Wed, Jun 12, 2019 at 01:51:37PM +0100, Sudeep Holla wrote:
quoted
The trusted OS may reject CPU_OFF calls to its resident CPU, so we must
avoid issuing those. We never migrate a Trusted OS and we already take
care to prevent CPU_OFF PSCI call. However, this is not reflected
explicitly to the userspace. Any user can attempt to hotplug trusted OS
resident CPU. The entire motion of going through the various state
transitions in the CPU hotplug state machine gets executed and the
PSCI layer finally refuses to make CPU_OFF call.

This results is unnecessary unwinding of CPU hotplug state machine in
the kernel. Instead we can mark the trusted OS resident CPU as not
available for hotplug, so that the user attempt or request to do the
same will get immediately rejected.

Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <redacted>
Signed-off-by: Sudeep Holla <redacted>
---
 arch/arm64/include/asm/cpu_ops.h |  3 +++
 arch/arm64/kernel/psci.c         |  6 ++++++
 arch/arm64/kernel/setup.c        | 11 ++++++++++-
 3 files changed, 19 insertions(+), 1 deletion(-)
I'm just trying to understand the motivation behind this. It's not a fix as
far as I can tell, but more of an optimisation for a failing CPU hotplug
case. Why is that important? I feel like I'm missing something.
Yes it's just optimisation and not a fix. The main reasons I came up
with this was to avoid unnecessary CPU hotplug state machine unwinding
as it's generally heavy weight operation. There's no other hidden
reasons :) that you are missing.

IIRC I wrote this when I was debugging some issue with suspend-to-ram
which was broken for a different reason.

--
Regards,
Sudeep


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help