[Cbe-oss-dev] Context switch question
Luke Browning
lukebr at linux.vnet.ibm.com
Wed Sep 12 00:52:42 EST 2007
See questions below after //
Thx,
Luke
int spu_process_callback(struct spu_context *ctx)
{
struct spu_syscall_block s;
u32 ls_pointer, npc;
void __iomem *ls;
long spu_ret;
int ret;
/* get syscall block from local store */
npc = ctx->ops->npc_read(ctx) & ~3;
ls = (void __iomem *)ctx->ops->get_ls(ctx);
ls_pointer = in_be32(ls + npc);
if (ls_pointer > (LS_SIZE - sizeof(s)))
return -EFAULT;
memcpy_fromio(&s, ls + ls_pointer, sizeof(s));
// is this a potential deadlock during context switch since
// problem state mappings are removed and context lock is
// held by caller? We would fault holding the lock and
// the lock needs to be taken to resolve the fault.
/* do actual syscall without pinning the spu */
ret = 0;
spu_ret = -ENOSYS;
npc += 4;
if (s.nr_ret < __NR_syscalls) {
spu_release(ctx);
/* do actual system call from here */
spu_ret = spu_sys_callback(&s);
if (spu_ret <= -ERESTARTSYS) {
ret = spu_handle_restartsys(ctx, &spu_ret, &npc);
}
spu_acquire(ctx);
if (ret == -ERESTARTSYS)
return ret;
}
/* write result, jump over indirect pointer */
memcpy_toio(ls + ls_pointer, &spu_ret, sizeof(spu_ret));
// same here?
ctx->ops->npc_write(ctx, npc);
ctx->ops->runcntl_write(ctx, SPU_RUNCNTL_RUNNABLE);
// I think the npc_write and runcntl_write are OK, because the lock is held
// meaning we are not in spu_save() or spu_restore(). However, we may be
// modifying the saved state of a context.
return ret;
}
More information about the cbe-oss-dev
mailing list