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

[Noguchi, Masato]

> -----Original Message-----
> From: Uzi Shvadron
> 
> Cédric Augonnet wrote on 23/05/2007 00:48:18:
> 
> > 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.
> >
> > 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.
> >
> 
> 
> In the past there has been several discussions about passing environment
> variables to the SPE at run time. One of the recent discussion was named "
> [PATCH] libspe: elfspe: set argv[argc] = NULL" where Arnd suggested:
> 
> > How about simply passing an effective address pointer as the
> > third argument to main?
> >
> > If we pass the arguments as
> >
> > int main(int argc, char *argv[], uint64_t env_ea);
> >
> > then those applications that really want to access the environment
> > can do that through DMA.
> >
> >            Arnd <><
> 
> 
> My opinion that in both cases might be found as inefficient. I would like
> to suggest another option. The idea is to identify a set of environment
> variables that will be passed to the application LS at load time. This can
> be done in the form:
> 
> int main(int argc, char *argv[], uint64_p envp)
> 
> where envp points to this predefined structure. This structure should be
> rather small (say, 128 or 256 bytes). Now data is available at run-time to
> the SPE application without the need to do system calls or DMA. This
> structure can be updated at any time if needed (like at context switch).
> In particular this structure can contain the local store ea in main memory,
> it can include the SPE physical ID that is needed by performance tools,
> etc. and it can include a pointer to larger data sets in main memory that
> may not fit into the limited LS.

Well, let me fix current status.
There are three formats to define startup function of spe.

First:
  int main(int speid, uint64_t argp, uint64_t envp);

  Standard format. speid is a identifier defined by libspe. argp
  and envp are pointers specified by application programmer at 4th and
  5th arguments of spe_context_run().

Second:
  int main(uint128_t arg1, uint128_t arg2 uint128_t arg3);

  Extended format. an application programmer can use this format by
  adding SPE_RUN_USER_REGS flag at spe_context_run(). All arguments
  are freed for application use.

Third:
  int main(int argc, char *argv[]);

  Elfspe format. To use this format, a spe program must be compiled with
  -mstdmain option, and must be executed by elfspe.

An envp format recently we discussed is about only third format.
I think it is a reasonable to add an envp to pass environment variables
considering the purpose of elfspe.

Shvadron suggested plan seems similar to the "original" plan of first
format above.  However, everyone already use an envp as own
purpose. For now, it is difficult to change vehavior, I think.

Well, putting that aside,
I have no objection to use stop-and-signal, but, I think 
it's no good to add function to kernel for getting LS address.
Because an effective address of LS mapped is a matter of libspe.  On
the spufs interface, an application does not have to mmap LS and PS,
and can mmap/munmap anytime anywhere.  Thus, if you add a spe function
to get ea of LS, its implementation should be in libspe, not in
kernel.  I.e. I suggest you to design a function as if SPE calls
spe_ls_area_get() of libspe.

Regards,
M.Noguchi