Re: [RFC PATCH 42/45] KVM: arm64: pkvm: Support SCMI power domain

[Jean-Philippe Brucker <jean-philippe@linaro.org>]

On Tue, Feb 07, 2023 at 01:27:17PM +0000, Mostafa Saleh wrote:
> Hi Jean,
> 
> > +bool kvm_host_scmi_handler(struct kvm_cpu_context *host_ctxt)
> > +{
> > +	DECLARE_REG(u64, func_id, host_ctxt, 0);
> > +
> > +	if (!scmi_channel.shmem || func_id != scmi_channel.smc_id)
> > +		return false; /* Unhandled */
> > +
> > +	/*
> > +	 * Prevent the host from modifying the request while it is in flight.
> > +	 * One page is enough, SCMI messages are smaller than that.
> > +	 *
> > +	 * FIXME: the host is allowed to poll the shmem while the request is in
> > +	 * flight, or read shmem when receiving the SCMI interrupt. Although
> > +	 * it's unlikely with the SMC-based transport, this too requires some
> > +	 * tightening in the spec.
> > +	 */
> > +	if (WARN_ON(__pkvm_host_add_remove_page(scmi_channel.shmem_pfn, true)))
> > +		return true;
> > +
> > +	__kvm_host_scmi_handler(host_ctxt);
> > +
> > +	WARN_ON(__pkvm_host_add_remove_page(scmi_channel.shmem_pfn, false));
> > +	return true; /* Handled */
> > +}
> 
> I am not sure what a typical SCMI channel shmem_size would be.

shmem_size is large but a SCMI message isn't bigger than 128 bytes at the
moment, so copying would certainly be more performant.

> But would map/unmap be more performant than
> memcpy(hyp_local_copy,scmi_channel.pfn,scmi_channel.shmem_size ); ?

The problem is that we're forwarding this to the SCMI server, which
expects to find the command in the shmem.

I took the easy route here, but a more efficient way to support SCMI would
be for the hypervisor to own the channel permanently, and the host<->hyp
communication would use a separate shared page. The hypervisor could then
copy from one channel to the other. It requires more support in the host
driver so I'd like to see if there is any interest in supporting SCMI
before working on this.

Thanks,
Jean