[+Sudeep]

On Tue, Jun 08, 2021 at 04:29:14PM +0100, Marc Zyngier wrote:

[+Mark, since we discussed about this on IRC]

Hi Valentin,

On Tue, 01 Jun 2021 11:25:01 +0100,
Valentin Schneider [off-list ref] wrote:

quoted

On 27/05/21 12:17, Marc Zyngier wrote:

quoted

On Tue, 25 May 2021 18:32:45 +0100,
Valentin Schneider [off-list ref] wrote:

quoted

I've tested this on my Ampere eMAG, which uncovered "fun" interactions with
the MSI domains. Did the same trick as the Juno with the pl011.

pNMIs cause said eMAG to freeze, but that's true even without my patches. I
did try them out under QEMU+KVM and that looked fine, although that means I
only got to test EOImode=0. I'll try to dig into this when I get some more
cycles.

That's interesting/worrying. As far as I remember, this machine uses
GIC500, which is a well known quantity. If pNMIs are causing issues,
that'd probably be a CPU interface problem. Can you elaborate on how
you tried to test that part? Just using the below benchmark?

Not even that, it would hang somewhere at boot. Julien suggested offline
that it might be a problem with the secondaries' PMR initial value, but I
really never got to do dig into it.

I just hit a similar problem on an Altra box, which seems to be
related to using PSCI for idle. PSCI has no idea about priority
masking, and enters CPU suspend with interrupt masked at the PMR
level. Good luck waking up from that.

Gah. If we can manage to understand which path in
psci_cpu_suspend_enter() is causing this problem that'd
be great too (it can be both, for different reasons):

if (!psci_power_state_loses_context(state))
(1)	ret = psci_ops.cpu_suspend(state, 0);
else
(2)	ret = cpu_suspend(state, psci_suspend_finisher);

I'd like to understand if the problem is on idle entry or
exit (or both depending on the state we are entering).

On (1) we would return from the call with the CPU state
retained on (2) with CPU context restored (but it rebooted
from reset - so the PMR value is gone).

I am asking about (2) because I am trying to understand what
the power controller does wrt PMR and wake-up IRQs (ie and
whether the PMR plays a role in that). Reworded: trying to
understand how the PMR behaviour is playing with the power
controller wake-up capabilities.

Thoughts appreciated.

I am sorry that you had to debug this, thank you for that.

Lorenzo

I've pushed a test branch at [1]. It'd be really good if you could
have a quick look and let me know if that helps in your case (it
certainly does on the box I have access to).

Thanks,

	M.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=arm64/nmi-idle

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel