[Cbe-oss-dev] [PATCH 5/6] spufs: fix dma restart

[Arnd Bergmann]

On Friday 15 February 2008, Luke Browning wrote:
> 
> Yes, it could have been done that way, but then you would have had to
> invoke the restart_dma() on every spufs_run_spu() whether it was needed
> or not.  We would in effect be carrying over an action from the previous
> system call making system call handling less self contained and atomic.
> This way the restart_dma() is performed only when you have an exception
> from the exception handling code and it is completed within the scope of
> the system call that caused the exception. From a problem determination
> perspective it is also better as the exception is directly related to
> the npc that specified by the user.  If we tied it to the next system
> call, the user could change the npc to something completely unrelated,
> perhaps even another program altogether.
> 

I think I'm still interpreting the source in a different way from how you
are reading it.

In my understanding, we still carry over the restart_dma to the next
spu_run system call. What I see happening is:

1. The mfc accesses an unmapped page
2. An interrupt is signalled to the ppu
3. The SPU thread breaks out of spufs_wait, while the spu keeps running
4. The page fault handler makes the signal pending and restarts the DMA
6a. The SPU attempts the access a second time, causing another interrupt
6b. The PPU returns to user space
7. The user fixes up the page mapping
8. We enter spufs_run again and immediately break out of spufs_wait
9. Another signal is made pending
10. The DMA gets restarted and this time is successful.
11. We return to user space again, with nothing to do
12. The next iteration of spufs_run continues as intended.

Since you have looked into it deeper, do you see something else
happening? The scenario that I have in mind sounds a lot more
complicated than your description above.

	Arnd <><