Re: Question about IPI interrupt handler

Hi,

On Tue Aug 05, 2014 at 15:00:02 -0800, Yuxin Ren wrote:
> I cannot understand the logic of the IPI interrupt handler very well.
> I hope someone can help me.
> Thanks a lot.
> I am using intel IA32 multi core cpu.
> My scenario is one client and one server thread on different core. Client
> sends simple data-only IPC to the server.
> 
> 1. The function Thread::handle_remote_requests_irq is the IPI interrupt
> handler, right?

Yes, it is.

>     So it is running within the interrupt context?

There's no such explicit thing, however, yes in the sense that this
function is run due to an IPI/IRQ.

> If so,
> 2. In this function, the variable "c" is set to the current Context. On the
> server core, when the server is blocked(waiting for IPC), what is
> current Context? The server thread or the idle thread?

Likely idle.

>      I have no other threads in the user level, and I assume there are no
> background threads in the kernel or L4Re.

Yes, then idle.

> In addition, I guess each thread
> associates with a Context.

Yes, a Context is a base class of a Thread.

> If my assumptions are right and that current Context is idle thread,
> 3.  At the last of this function, it calls c->handle_drq(). But when does
> the server thread's handle_drq() is called?

There's also a _pending_rqq where the sender CPU puts in requests and
the receiver takes them out and processes themesses them.

> 4.  In what situation, the variable "resched" will be set to true?

Whenever schedule() must be called because threads changed their state
and a reevaluation is needed.

> When it is true,
> 5. c->schedule() will be called, does it mean that we can switch to another
> thread in the interrupt context?
>     It cannot make sense to me.

Yes, this is done. But do not think of this as an interrupt context
(like Linux?), it's much more the same than an entry via a thread's
syscall.



Adam
-- 
Adam                 [email protected]
  Lackorzynski         http://os.inf.tu-dresden.de/~adam/