On 10/24/2013 03:33 PM, Gedare Bloom wrote:
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?
If the trap is installed and don't wait on other CPUs, then something is
enabled that causes traps to happen then secondary CPU have not the correct
trap handler.
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.
make sens to extend the cache manager. I agree.
Daniel
-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
