Question about IPI interrupt handler
adam at os.inf.tu-dresden.de
Mon Aug 11 22:59:02 CEST 2014
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?
> 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
Adam adam at os.inf.tu-dresden.de
More information about the l4-hackers