Re: [PATCH 0/6] Peripheral Image Loader support for Qualcomm SoCs

[Shiraz Hashim]

On Sun, Oct 06, 2024 at 10:34:19PM +0300, Dmitry Baryshkov wrote:
> On Sat, Oct 05, 2024 at 02:53:53AM GMT, Mukesh Ojha wrote:
> > Qualcomm is looking to enable remote processors on the SA8775p SoC
> > running KVM Linux host and is currently trying to figure out an
> > upstream-compatible solution for the IOMMU translation scheme problem it
> > is facing when SoCs running with KVM. This issue arises due to
> > differences in how IOMMU translation is currently handled on SoCs
> > running Qualcomm EL2 hypervisor(QHEE) where IOMMU translation for any
> > device is completely owned by it and the other issue is that remote
> > processors firmware does not contain resource table where these IOMMU
> > configuration setting will be present.
> > 
> > Qualcomm SoCs running with the QHEE(EL2) have been utilizing the
> > Peripheral Authentication Service (PAS) from its TrustZone (TZ) firmware
> > to securely authenticate and reset via a single SMC call
> > _auth_and_reset_.  This call first gets trapped to QHEE, which then
> > makes a call to TZ for authentication. Once it is done, the call returns
> > to QHEE, which sets up the IOMMU translation scheme for these remote
> > processors and later brings them out of reset. The design of the
> > Qualcomm EL2 hypervisor dictates that the Linux host OS running at EL1
> > is not allowed to set up IOMMU translation for remote processors,
> > and only a single stage is being configured for them.
> > 
> > To make the remote processors’ bring-up (PAS) sequence
> > hypervisor-independent, the auth_and_reset SMC call is now entirely
> > handled by TZ. However, the problem of IOMMU handling still remains with
> > the KVM host, which has no knowledge of the remote processors’ IOMMU
> > configuration.
> > 
> > We have looked up one approach where SoC remoteproc device tree could
> > contain resources like iommus for remoteproc carveout and qcom,devmem
> > specific binding for device memory needed for remoteproc and these
> > properties are optional and will only be overlaid by the firmware if it
> > is running with non-QHEE based hypervisor like KVM.
> 
> Can you follow the approach that has been implemented for existing
> systems (ChromeOS) not using QHEE? See drivers/remoteproc/qcom_q6v5_adsp.c
> If this approach can not be used, please describe why.
> 

The intent is to reuse same PAS based remoteproc implementation
assisted by TZ with or without QHEE while qcom_q6v5_adsp.c caters to
independent control at Linux.
So it better suites to support it from qcom_q6v5_pas.c .

regards
Shiraz