linux-kernel - Re: [GICv3 ITS]S2IDLE framework does not invoke syscore

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250403-rare-wasp-of-management-9bce59@sudeepholla>
Date: Thu, 3 Apr 2025 10:18:54 +0100
From: Sudeep Holla <sudeep.holla@....com>
To: Youngmin Nam <youngmin.nam@...sung.com>
Cc: Marc Zyngier <maz@...nel.org>, Thomas Gleixner <tglx@...utronix.de>,
	Sudeep Holla <sudeep.holla@....com>,
	Saravana Kannan <saravanak@...gle.com>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	kernel-team@...roid.com, hajun.sung@...sung.com,
	d7271.choe@...sung.com, joonki.min@...sung.com, ne.yoo@...sung.com
Subject: Re: [GICv3 ITS]S2IDLE framework does not invoke syscore_ops in GICv3
 ITS driver

On Thu, Apr 03, 2025 at 10:30:42AM +0900, Youngmin Nam wrote:
> On Wed, Apr 02, 2025 at 12:56:53PM +0100, Sudeep Holla wrote:
> > (Failed to find the original email, so reply on this instead)
> > 
> > On Thu, Mar 27, 2025 at 12:22:19PM +0900, Youngmin Nam wrote:
> > > 
> > > The problem is that syscore_ops is not invoked during the S2IDLE scenario,
> > > so we cannot rely on it in that context.
> > > We would like to use these suspend/resume functions during S2IDLE as well.
> > 
> > I have one orthogonal question. The s2idle will just use the deepest
> > cpuidle state registered. So if s2idle needs this save/restore of GICv3
> > ITS, how does that work when all the CPUs enter that idle state.
> > 
> > With respect to the PSCI CPU_SUSPEND call, it doesn't change. So I am
> > bit confused as how it can work fine in normal cpuidle paths but no in
> > s2idle path. What am I missing ? I do psci_enter_domain_idle_state handles
> > s2idle little different but nothing to change this GICv3 ITS save/restore
> > requirement between cpuidle and s2idle.
> > 
> Hi Sudeep,
> 
> Thanks for asking.
> As a SoC vendor, we are using the Android kernel, which includes a vendor
> hook like the one below.
> 
> In this function, a vendor-specific handler attached to
> trace_android_vh_cpuidle_psci_enter is called.
> 
> 54 static __cpuidle int __psci_enter_domain_idle_state(struct cpuidle_device *dev,
> 55                                                     struct cpuidle_driver *drv, int idx,
> 56                                                     bool s2idle)
> 57 {
> 58         struct psci_cpuidle_data *data = this_cpu_ptr(&psci_cpuidle_data);
> 59         u32 *states = data->psci_states;
> 60         struct device *pd_dev = data->dev;
> 61         u32 state;
> 62         int ret;
> 63
> 64         ret = cpu_pm_enter();
> 65         if (ret)
> 66                 return -1;
> 67
> 68         /* Do runtime PM to manage a hierarchical CPU toplogy. */
> 69         trace_android_vh_cpuidle_psci_enter(dev, s2idle);
> 
> Within the vendor-specific handler, if the current mode is S2IDLE and the
> CPU logical number is 0, the GIC ITS suspend function is executed.
> 

/me more confused.

Are you saying you have some cpuidle platform specific logic inside
trace_android_vh_cpuidle_psci_enter(). I would assume it was just to
trace the entry into the state and nothing more.

In fact, it was recently added upstream as well.
Commit 7b7644831e72 ("cpuidle: psci: Add trace for PSCI domain idle")

Further you didn't explicitly answer my question. IIUC are you calling
GIC ITS suspend function unconditionally if its boot cpu ? Or is it
done only for s2idle ? If done only for s2idle, how does it work for
normal cpuidle entry to deepest idle state that matches the one entered
during s2idle.

-- 
Regards,
Sudeep