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

From: Sudeep Holla <sudeep.holla@arm.com>
To: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm64: smp: disable hotplug on trusted OS resident CPU
Date: Mon, 12 Aug 2019 18:11:03 +0100	[thread overview]
Message-ID: <20190812171103.GA9765@e107155-lin> (raw)
In-Reply-To: <ae9944d8-0c0a-5f0f-707d-4d9e70a4f163@arm.com>

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:
> > Hi Sudeep.
> >
> > On Wed, Jun 12, 2019 at 01:51:37PM +0100, Sudeep Holla wrote:
> >> 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 <will.deacon@arm.com>
> >> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> >> ---
> >>  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