On Thu, Oct 24, 2013 at 9:15 AM, Daniel Hellstrom <dan...@gaisler.com> wrote: > Hello, > > From code analysis and testing SMP on LEON I can see that when installing a > trap handler the cache is not invalidated correctly on other CPUs then the > CPU installing the new trap handler. In the single-core case this is > correct, but for SMP we must flush all CPUs caches. I think this is a > platform independent problem for all self-modifying code. On the LEON SMP we > normally don't see this since since the bad traps that are installed are > never taken. > > My suggestion is that we use a IPI to signal to other CPUs to invalidate > their instruction cache, and CPU requesting such a remote CPU(s) flush > should wait until all remote CPUs signal that their cache has been > invalidated. The cache library could be extended to support SMP. Perhaps is > should not be a platform independednt IPI solution, but rather a libcpu/BSP > specific implementation for implementing cache flush on another CPU? > Why wait for a response? Rather, is there a need for both synchronous and asynchronous versions of the remote cache operations?
I think the cache manager should certainly be extended with SMP capabilities. We should identify which operations make sense to invoke on a remote core, and which operations make sense to invoke on all cores. This can simplify the interface by making some operations implicitly work on SMP, for example cache_invalidate_entire_data() could be made to invalidate the data cache on every core if that semantic makes sense. -Gedare > What do think about this issue? > > Regards, > Daniel Hellstrom > _______________________________________________ > rtems-devel mailing list > rtems-devel@rtems.org > http://www.rtems.org/mailman/listinfo/rtems-devel _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
