Re: V240 Status?

[Takeshi Nakayama <tn%catvmics.ne.jp@localhost>]

>>> 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:

ENTRY(sparc64_ipi_ccall)
        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