On Wed, Nov 26, 2025 at 10:40:51AM -0600, Bjorn Andersson wrote: > On Mon, Nov 24, 2025 at 05:33:18PM +0530, Mukesh Ojha wrote: > > On Mon, Nov 24, 2025 at 12:31:47PM +0100, Konrad Dybcio wrote: > > > On 11/21/25 12:01 PM, Mukesh Ojha wrote: > > > > Most Qualcomm platforms feature Gunyah hypervisor, which typically > > > > handles IOMMU configuration. This includes mapping memory regions and > > > > device memory resources for remote processors by intercepting > > > > qcom_scm_pas_auth_and_reset() calls. These mappings are later removed > > > > during teardown. Additionally, SHM bridge setup is required to enable > > > > memory protection for both remoteproc metadata and its memory regions. > > > > When the aforementioned hypervisor is absent, the operating system must > > > > perform these configurations instead. > > > > > > > > When Linux runs as the hypervisor (@ EL2) on a SoC, it will have its > > > > own device tree overlay file that specifies the firmware stream ID now > > > > managed by Linux for a particular remote processor. If the iommus > > > > property is specified in the remoteproc device tree node, it indicates > > > > that IOMMU configuration must be handled by Linux. In this case, the > > > > has_iommu flag is set for the remote processor, which ensures that the > > > > resource table, carveouts, and SHM bridge are properly configured before > > > > memory is passed to TrustZone for authentication. Otherwise, the > > > > has_iommu flag remains unset, which indicates default behavior. > > > > > > > > Enables Secure PAS support for remote processors when IOMMU > > > > configuration > > > > is managed by Linux. > > > > > > > > Signed-off-by: Mukesh Ojha <[email protected]> > > > > --- > > > > > > [...] > > > > > > > + pas->pas_ctx->has_iommu = rproc->has_iommu; > > > > + pas->dtb_pas_ctx->has_iommu = rproc->has_iommu; > > > > > > Sorry if we've been there before, but I see that IOMMU-mapping happens > > > before ctx initialization.. can we drop this parameter and just use > > > device_iommu_mapped(ctx->dev) in qcom_scm_pas_prepare_and_auth_reset()? > > > > You are right and I am not against it, rproc already has variable > > `has_iommu` > > which we use in framework and vendor driver too, but what I thought, > > since this thing we have to do even for Iris or other drivers who are > > effected, they already have device which are behind IOMMU and if wrong > > device is passed in device_iommu_mapped() instead of firmware device which > > could have returned true even when Gunyah is present. > > > > If you feel, has_iommu is not correct name, I could rename it to fw_iommu ? > > > > While this does relate to "has_iommu" and/or "fw_iommu" when it comes to > the current PAS context, the "feature flag" is "should we use tzmem or > not". > > Further, in the case of the modem, we don't have an IOMMU, but we still > need to set this flag on the ctx in order to get the metadata into TZ. > > So, I think this should be detached from the "iommu". How about naming > the "has_iommu" in the context to "use_tzmem"?
Sure, this way it gets attached to tzmem alloc/create API to be used or not for PIL SMC calls. > > Regards, > Bjorn > > > -- > > -Mukesh Ojha -- -Mukesh Ojha
