[Cbe-oss-dev] [RFC] Reading Local Store base address from SPU using stop-and-signal with kernel support

[Arnd Bergmann]

On Tuesday 22 May 2007, Cédric Augonnet wrote:
> Hi all,
> 
> Sometimes, the SPU needs to know where its Local Store is mapped on
> main memory. The issue is that the user would have to somehow
> explicitly supply that information to the SPU as far as i know.
> Therefore a library needing that base address would hardly get that
> information.

Most users that want this supply it from the PPU side of the
application, e.g. over the mailbox or in a parameter area
that is passed in via DMA.

Of course, that will not work for standalone SPU applications,
which is a serious restriction.

> I would have liked to have your opinion about using a stop-and-signal
> receiving some implicit support from the kernel in order to get it.
> 
> This is doable using the same approach as for system calls used from
> the SPUs : the argument supplied during the stop-and-signal call would
> be specific to that functionality (as it is already the case 0x2104
> for syscalls). The kernel would recognize such a specific case and
> handle it in consequence.
> 
> Here is a draft of the patch that would normally make it possible :
> http://perso.ens-lyon.fr/cedric.augonnet/Kernel/spu_get_ls.patch

It won't work this way. What you provide to the SPU here is the
address of the mapping in the kernel address space, which is
different from the effective address space that the SPU sees
in DMA operations.

If you make it a stop-and-signal call, it needs to be handled by
libspe2, or by the application.

> To make it clearer, I also wrote a sample of a SPU code intended to
> show how this functionnality could be used so that the SPU could get
> the LS base address transparently.
> http://perso.ens-lyon.fr/cedric.augonnet/Kernel/sample.c
> 
> So my questions are :
> 1/ Can such a stop-and-signal argument be reserved for so specific a
> purpose, as it was done with syscalls ?

It's a fairly complicated procedure to allocate a new major
number for this. It's probably easier to get a new subcode in
one of the existing calls (0x2100 to 0x2104) that are handled by
libspe2.
 
> 2/ Should we rather be able to retrieve the spu identifier using that
> same technique, and then make use of a couple of DMA transfer to
> explicitly fetch the base address from the PPU, provided the speid ?

That would basically mean to have a version of libspe2 that gets
compiled for the SPU itself. There have been suggestions like this
before, and I think it's a reasonable idea. Note that each SPU
program gets passed the spe identifier to its main function, but
there is currently no use for this _at_all_.
 
As a callback to libspe2, I think you should be able to get the
local store pointer for any speid though, not just the one you
are executing in.

> I'm aware that providing such functionnalities through macros on the
> SPU might really hide the possibly huge cost of such a stop-and-signal
> call, but if the programmer is aware of such a cost, can't it make spu
> library simpler to write?

Whichever way you do it requires changes to the application, or to libspe2.
If you change the application, the easiest way is to use the 'argp' or
'envp' pointers to just pass down the local store address -- no need for
any special magic here.

If you change libspe2 instead, it may be easier to have a generic mechanism
that allows you to pass in the local store pointer as something that
is always available. libspe2 sets up the initial registers for the SPE
anyway, so it can just as well initialize on of the registers to the local
store pointer, and then have the _init function on the SPE save this
to a global variable. However, such an approach is an extension to the SPE
ABI, which in turn means that it needs to get through the same committee
as an extension of the documented stop code interface.

	Arnd <><