[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: V240 Status?
>>> Takeshi Nakayama <tn%catvmics.ne.jp@localhost> wrote
> >>> Martin Husemann <martin%duskware.de@localhost> wrote
> > On Mon, Jan 21, 2013 at 10:21:44PM +0100, J. Hannken-Illjes wrote:
> > > So its not V240 specific. As high priority calls are rare (only
> > > subr_pcu.c,
> > > and NPF through subr_pserialize.c used it so far) it is quite possible
> > > they
> > > were never tested.
> > I'm pretty sure I tested back then, but I am not 100% sure right now.
> > I'll have a look.
> I think sparc64_ipi_ccall in mp_subr.S is suspicious.
> If it is called directly from interrupt_vector in locore.s, it
> requires something like TRAP_SETUP() or INTR_SETUP() to prepare
> stack and others.
Other idea is just schedule a softint in IPI-handler:
Introduce ci_xcall_ih in per-CPU struct cpu_info, then initialize
it with sparc_softintr_establish(PIL_HIGH, NULL, NULL).
In IPI-handler, just use setup_sparcintr as similar as ci_tick_ih
in sparc_interrupt as below:
sethi %hi(CPUINFO_VA+CI_XCALL_IH), %g6
LDPTR [%g6 + %lo(CPUINFO_VA+CI_XCALL_IH)], %g5
STPTR %g2, [%g5 + IH_FUN]
ba,pt %icc, setup_sparcintr
STPTR %g3, [%g5 + IH_ARG]
If we make it as xc_ipi_handler specific, storings of ih_fun and
ih_arg can be omitted.
-- Takeshi Nakayama
Main Index |
Thread Index |