Hi Sudeep,
On Mon, Dec 9, 2019 at 3:53 PM Sudeep Holla sudeep.holla@arm.com wrote:
On Mon, Dec 09, 2019 at 02:50:43PM +0530, Sandeep Tripathy wrote:
Hi Sudeep,
[...]
*what's those data that OS maintains in RAM/caches that it's responsible for * Any software be it an application/driver sharing the coherent memory with another masters can assume that it need not do explicit cache-ops ever and coherency is guaranteed by platform (firmware/hardware/os)?
OK, you are missing something obvious in such design. If there are other slaves and masters depending on this slave(OSPM), then the master initiating the shutdown of this slave(OSPM) but be aware of it and can broadcast the same across.
Of Course it will. The issue is not about notification mechanism. If master can't, then firmware dealing with
this slave shutdown must. You simply can't assume things you currently are. Sounds like a design gap in such a multi master-slave system to me.
The data updated to the coherent memory region may be in L1/L2 D$ and we want a graceful/abrupt shutdown/reboot of this *slave system* where other master(s) not managed by *slave system*
Yes of-course slaves don't manage master. Not sure how the master and slave communicate in such a setup. Looks like some communication gap between them :)
'linux/tf-a' are still functional and can snoop the data. In this case such application(s) have to do explicit cache flush on reboot/shutdown event on a coherent memory.
Absence of Shutdown/Reboot notification in such a system seems to be the root of all such problems to me.
I did not say notification does not exist or applications can't do cache ops along with many other stuff or communication protocol it might have to do on a shutdown/reboot (not relevant). Trust me various approaches we discussed here so far and other CENH works :).
The generic discussion is: Is it the responsibility of an application to do cache maintenance on a *coherent memory* in shutdown/reboot path where it never have to do so in its normal course. Is it not valid to expect such mechanism from the underlying platform firmware or hardware. It is the core which is going down and expected to do so in a graceful manner if possible. If the limitation is time, understandable but not exciting for smaller systems.
-- Regards, Sudeep
Thanks Sandeep