On Wed, Mar 11, 2026 at 02:19:18PM +0530, Mukesh Ojha wrote:
> On Wed, Mar 11, 2026 at 04:34:53AM +0200, Dmitry Baryshkov wrote:
> > On Tue, Mar 10, 2026 at 07:22:05PM +0530, Mukesh Ojha wrote:
> > > Qualcomm remoteproc drivers such as qcom_q6v5_mss, which do not use the
> > > Peripheral Authentication Service (PAS), always map the MBA region before
> > > use and unmap it once the usage is complete. This behavior was introduced
> > > to avoid issues seen in the past where speculative accesses from the
> > > application processor to the MBA region after it was assigned to the
> > > remote
> > > Q6 led to an XPU violation. The issue was mitigated by unmapping the
> > > region
> > > before handing control to the remote Q6.
> > >
> > > Currently, most Qualcomm SoCs using the PAS driver run either with a
> > > standalone QHEE or the Gunyah hypervisor. In these environments, the
> > > hypervisor unmaps the Q6 memory from HLOS Stage-2 and remaps it into the
> > > Q6 Stage-2 page table. As a result, speculative accesses from HLOS cannot
> > > reach the region even if it remains mapped in HLOS Stage-1; therefore, XPU
> > > violations cannot occur.
> > >
> > > However, when the same SoC runs Linux at EL2, Linux itself must perform
> > > the
> > > unmapping to avoid such issues. It is still correct to apply this mapping/
> > > unmapping sequence even for SoCs that run under Gunyah, so this behavior
> > > should not be conditional.
> > >
> > > Signed-off-by: Mukesh Ojha <[email protected]>
> > > ---
> > > drivers/remoteproc/qcom_q6v5_pas.c | 48 +++++++++++++++++++++++-------
> > > 1 file changed, 38 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/remoteproc/qcom_q6v5_pas.c
> > > b/drivers/remoteproc/qcom_q6v5_pas.c
> > > index 3bde37ac510c..033d618ccba9 100644
> > > --- a/drivers/remoteproc/qcom_q6v5_pas.c
> > > +++ b/drivers/remoteproc/qcom_q6v5_pas.c
> > > @@ -138,6 +138,13 @@ static void qcom_pas_segment_dump(struct rproc
> > > *rproc,
> > > return;
> > > }
> > >
> > > + pas->mem_region = ioremap_wc(pas->mem_phys, pas->mem_size);
> >
> > Which will be called once per segment. Move this to qcom_pas_minidump()
> > and call iounmap() afterwards.
>
> Good eyes!, Ah!! my bad.
>
> And moving it to qcom_pas_minidump() will cover minidump cases and
> fallback cases to full dumps if minidump_id is mentioned for a
> subsystem. However, we may miss mapping for pure rproc_coredump() case
> when the framework assigned .coredump = rproc_coredump when vendor
> coredump callback is not provided when subsystem does not have minidump_id
> mentioned. Do you think writing qcom_pas_coredump() wrapper over
> rproc_coredump() will be fine ?
>
> --- a/drivers/remoteproc/qcom_q6v5_pas.c
> +++ b/drivers/remoteproc/qcom_q6v5_pas.c
> @@ -141,6 +141,11 @@ static void qcom_pas_segment_dump(struct rproc *rproc,
> memcpy_fromio(dest, pas->mem_region + total_offset, size);
> }
>
> +static void qcom_pas_coredump(struct rproc *rproc)
> +{
> + rproc_coredump(rproc);
It won't be that simple, most likely. You'd need to call ioremap_wc()
before and iounmap() afterwards. Then it would make sense.
And alternative option would be to use
rproc_coredump_add_custom_segment() and add a custom function which
would perform ioremap() / memcpy() / iounmap().
> +}
> +
> static void qcom_pas_minidump(struct rproc *rproc)
> {
> struct qcom_pas *pas = rproc->priv;
--
With best wishes
Dmitry
