Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 23 Nov 2020 17:22:30 +0000
Message-ID: <87ft5056p5.wl-maz@kernel.org>
From:   Marc Zyngier <maz@kernel.org>
To:     David Brazdil <dbrazdil@google.com>
Cc:     kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org,
        linux-kernel@vger.kernel.org, James Morse <james.morse@arm.com>,
        Julien Thierry <julien.thierry.kdev@gmail.com>,
        Suzuki K Poulose <suzuki.poulose@arm.com>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Will Deacon <will@kernel.org>, Dennis Zhou <dennis@kernel.org>,
        Tejun Heo <tj@kernel.org>, Christoph Lameter <cl@linux.com>,
        Mark Rutland <mark.rutland@arm.com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
        Quentin Perret <qperret@google.com>,
        Andrew Scull <ascull@google.com>,
        Andrew Walbran <qwandor@google.com>, kernel-team@android.com,
        Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
        Sudeep Holla <sudeep.holla@arm.com>
Subject: Re: [PATCH v2 20/24] kvm: arm64: Intercept host's CPU_SUSPEND PSCI SMCs
In-Reply-To: <20201116204318.63987-21-dbrazdil@google.com>
References: <20201116204318.63987-1-dbrazdil@google.com>
        <20201116204318.63987-21-dbrazdil@google.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue)
 FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 Emacs/27.1
 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk

Adding Lorenzo and Sudeep to this one in particular, as there is a bit
of a corner case below.

On Mon, 16 Nov 2020 20:43:14 +0000,
David Brazdil <dbrazdil@google.com> wrote:
> 
> Add a handler of CPU_SUSPEND host PSCI SMCs. The SMC can either enter
> a sleep state indistinguishable from a WFI or a deeper sleep state that
> behaves like a CPU_OFF+CPU_ON.
> 
> The handler saves r0,pc of the host and makes the same call to EL3 with
> the hyp CPU entry point. It either returns back to the handler and then
> back to the host, or wakes up into the entry point and initializes EL2
> state before dropping back to EL1.
> 
> There is a simple atomic lock around the reset state struct to protect
> from races with CPU_ON. A well-behaved host should never run CPU_ON
> against an already online core, and the kernel indeed does not allow
> that, so if the core sees its reset state struct locked, it will return
> a non-spec error code PENDING_ON. This protects the hypervisor state and

"non-spec" as in "outside of the PSCI specification"? Err...

> avoids the need for more complicated locking and/or tracking power state
> of individual cores.
> 
> Signed-off-by: David Brazdil <dbrazdil@google.com>
> ---
>  arch/arm64/kvm/hyp/nvhe/psci-relay.c | 39 +++++++++++++++++++++++++++-
>  1 file changed, 38 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kvm/hyp/nvhe/psci-relay.c b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> index 2daf52b59846..313ef42f0eab 100644
> --- a/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> +++ b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> @@ -121,6 +121,39 @@ static void release_reset_state(struct kvm_host_psci_state *cpu_state)
>  	atomic_set_release(&cpu_state->pending_on, 0);
>  }
>  
> +static int psci_cpu_suspend(u64 func_id, struct kvm_cpu_context *host_ctxt)
> +{
> +	u64 power_state = host_ctxt->regs.regs[1];
> +	unsigned long pc = host_ctxt->regs.regs[2];
> +	unsigned long r0 = host_ctxt->regs.regs[3];
> +	struct kvm_host_psci_state *cpu_state;
> +	struct kvm_nvhe_init_params *cpu_params;
> +	int ret;
> +
> +	cpu_state = this_cpu_ptr(&kvm_host_psci_state);
> +	cpu_params = this_cpu_ptr(&kvm_init_params);
> +
> +	/*
> +	 * Lock the reset state struct. This fails if the host has concurrently
> +	 * called CPU_ON with this CPU as target. The kernel keeps track of
> +	 * online CPUs, so that should never happen. If it does anyway, return
> +	 * a non-spec error. This avoids the need for spinlocks.
> +	 */
> +	if (!try_acquire_reset_state(cpu_state, pc, r0))
> +		return PSCI_RET_ALREADY_ON;

So that's the core of the problem. I'm definitely not keen on EL2
returning unspecified error codes. But there is something I don't get:

If the CPU is currently booting (reset state is locked), it means that
CPU hasn't reached the EL1 kernel yet. So how can this same CPU issue
a CPU_SUSPEND from EL1? CPU_SUSPEND can't be called for a third party,
only by a CPU for itself.

It looks like this case cannot happen by construction. And if it
happens, it looks like the only course of action should be to panic,
as we have lost track of the running CPUs. Am I missing something
obvious?

> +
> +	/*
> +	 * Will either return if shallow sleep state, or wake up into the entry
> +	 * point if it is a deep sleep state.
> +	 */
> +	ret = psci_call(func_id, power_state,
> +			__hyp_pa(hyp_symbol_addr(__kvm_hyp_cpu_entry)),
> +			__hyp_pa(cpu_params));
> +
> +	release_reset_state(cpu_state);
> +	return ret;
> +}
> +
>  static int psci_cpu_on(u64 func_id, struct kvm_cpu_context *host_ctxt)
>  {
>  	u64 mpidr = host_ctxt->regs.regs[1];
> @@ -178,7 +211,9 @@ asmlinkage void __noreturn __kvm_hyp_psci_cpu_entry(void)
>  
>  static unsigned long psci_0_1_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
>  {
> -	if (func_id == kvm_host_psci_function_id[PSCI_FN_CPU_OFF])
> +	if (func_id == kvm_host_psci_function_id[PSCI_FN_CPU_SUSPEND])
> +		return psci_cpu_suspend(func_id, host_ctxt);
> +	else if (func_id == kvm_host_psci_function_id[PSCI_FN_CPU_OFF])
>  		return psci_forward(host_ctxt);
>  	else if (func_id == kvm_host_psci_function_id[PSCI_FN_CPU_ON])
>  		return psci_cpu_on(func_id, host_ctxt);
> @@ -202,6 +237,8 @@ static unsigned long psci_0_2_handler(u64 func_id, struct kvm_cpu_context *host_
>  	case PSCI_0_2_FN_SYSTEM_RESET:
>  		psci_forward_noreturn(host_ctxt);
>  		unreachable();
> +	case PSCI_0_2_FN64_CPU_SUSPEND:
> +		return psci_cpu_suspend(func_id, host_ctxt);
>  	case PSCI_0_2_FN64_CPU_ON:
>  		return psci_cpu_on(func_id, host_ctxt);
>  	default:
> -- 
> 2.29.2.299.gdc1121823c-goog
> 
> 

Thanks,

	M.

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