remoteproc: imx_rproc race

[Peng Fan]

> Subject: Re: remoteproc: imx_rproc race
> 
> Hello Peng,
> 
> Am 08.04.2022 um 09:30 schrieb Peng Fan:
> >> Subject: remoteproc: imx_rproc race
> >>
> >> Hi all,
> >>
> >> to support remote processors started before Linux booted on i.MX8MP
> >> SoCs, the rsc-table device tree property was introduced.
> >> This entry specifies a location in a shared memory area where the
> >> remote processor will place the resource table.
> >> In the MCUXpresso SDK samples for i.MX8MP, this is achieved by
> >> copying the resource table to this location during startup.
> >> While this use case works fine, I don't see how this is supposed to
> >> work when booting the same remote processor firmware from user space.
> >>
> >> Note that I expected "[PATCH V2] remoteproc: imx_rproc: use imx
> >> specific hook for find_loaded_rsc_table" [1] to be applied at some point.
> >> Without this patch there seem to be some other issues as well.
> >>
> >> After starting the remote processor here:
> >> remoteproc_core.c: rproc_start(): 'ret = rproc->ops->start(rproc);'
> >> both cores are running in parallel and both cores are trying to write
> >> to the resource table.
> >> While Linux starts setting status flags like VIRTIO_CONFIG_S_DRIVER,
> >> the remote processor copies the entire resource table to the same
> >> place during its startup sequence.
> >> If the copy runs after Linux has set the status flags, those flags
> >> will be reset and the remote processor will wait for them forever.
> >> Since this is racy, this will most likely fail.
> >
> > Technically your concern is valid, but NXP ATF has locked down TCM
> > area, that means linux has no chance to write TCM area for elf resource
> table update.
> >
> > So I moved to use rsc_table.
> 
> This is understandable for me and not a problem per se.
> 
> >
> > NXP MCU SDK not check resource table per my understanding. It just
> > copy the resource table to the place rsc_table points to.
> 
> 
> That's the point. While one core is copying the table to the specified area, the
> other core is modifying the same area. That does not work.
> 
> For this to work, there has to be some sort of synchronization between the
> cores. Either Linux has to wait for the remote processor to finish its table copy,
> or the remote processor checks if the table has already been prepared by
> Linux and then skip the copy or something like that...
> 
> So, I was wondering how it was intended to address this problem?

Since this is i.MX8* specific, I think we could add logic in the
find_loaded_rsc_table hook to wait table ready.

Regards,
Peng.

> 
> Thanks
>   ~Matthias
> 
> >
> > Regards,
> > Peng.
> >
> >>
> >> Can anyone tell me how it is intended to cover both cases (other than
> >> using different firmware images for the remote processor)?
> >>
> >> Thanks
> >>    ~Matthias
> >>
> >> [1]
> >> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist
> >>
> s.infr%2F&data=04%7C01%7Cpeng.fan%40nxp.com%7C127dca1dcb7f45
> 3cc75
> >>
> c08da19386ef2%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C63
> 78500274
> >>
> 13071138%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
> V2luMzIi
> >>
> LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=WXWFgeqNpRfPX
> xrhJALB5
> >> zoZUadnjDbecbDH%2FVJJRUQ%3D&reserved=0
> >>
> adead.org%2Fpipermail%2Flinux-arm-kernel%2F2022-January%2F709047.ht
> >>
> ml&data=04%7C01%7Cpeng.fan%40nxp.com%7C423c5e47c2f04920720
> >>
> 408da192d4048%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63
> >>
> 7849979390172717%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> >>
> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata
> >>
> =TqF7b3AyxlRAho3RiwQHe7mtMveaHZ0Cl3jKQ8noz6E%3D&reserved=0
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists
> > .infradead.org%2Fmailman%2Flistinfo%2Flinux-arm-kernel&data=04%
> 7C0
> >
> 1%7Cpeng.fan%40nxp.com%7C127dca1dcb7f453cc75c08da19386ef2%7C686
> ea1d3bc
> >
> 2b4c6fa92cd99c5c301635%7C0%7C1%7C637850027413071138%7CUnknow
> n%7CTWFpbG
> >
> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> Mn0%
> >
> 3D%7C2000&sdata=GKt%2BftN2zd4y5K1tumHH%2BUSjRjhmg%2FiA3ob
> PgtQCoLs%
> > 3D&reserved=0