|
Hi Subin:
i am not familiar with other architecture, but for ARM, Linux Kernel 2.6.35, i checked the function handle_level_irq()and handle_edge_irq() in chip.c, both of them will call handle_IRQ_event() which is in handle.c. and the function handle_IRQ_event() will call the interrupt handler written by user. Kernel does not open interrupt(ARM CPSR I bit)when calling interrupt handler in handle_IRQ_event() function. this is only for top-half interrupt handling. for bottom-half, it is no doubt that the interrupt will be opened. so if you register a interrupt by request_irq(), the interrupt handler will be called with irq disabled. i tested on Cortex-A9 dual core platform, it is right.
> Date: Thu, 23 Feb 2012 11:12:06 -0600 > Subject: Re: pagetables used in interrupt context > From: subingangadharan@xxxxxxxxx > To: buyit@xxxxxxx > CC: c.a.subramaniam@xxxxxxxxx; dhylands@xxxxxxxxx; kernelnewbies@xxxxxxxxxxxxxxxxx > > Hi , > > > can support nest interrupt if it wants(2.6.35 does not support this). and it > > is very simple to use the interrupted thread's kernel mode stack as the > > interrupt context. if kernel use a specific stack which is for interrupt > > Thanks for the crystal clear explanation of the page table usage in > interrupt context. I have one more doubt, so in 2.6.35 as you said it > doesn't support > nested interrupt, does it mean that all other interrupts are > completely disabled, (I mean no other can interrupt the processor) > while executing an interrupt handler. > > > > 2012/2/23 卜弋天 <buyit@xxxxxxx>: > > Hi : > > > > for ARM architecture, from the point of my view, interrupt can be > > handled in IRQ, SVC, or SYSTEM modes. > > 1.if kernel handles interrupt in IRQ mode, it can use separate specific > > stack of IRQ mode to handle interrupt,but it cannot support nest interupt, > > suppose you are running interrupt handler in IRQ mode, a new coming > > interrupt will corrupt the lr_irq which is used for current function. > > 2. if kernel handles interrupt in SYSTEM mode, the sequences will be : > > hardware interrupt occurs-->IRQ mode-->SYSTEM mode -->call > > interrupt handler. > > kernel can support nest interrupt well by this way, the problem is > > SYSTEM mode use the same register with USER mode, which means kernel will > > use the interrupted thread's user mode stack, this will leake information > > of kernel to user space, so it is not a good ide a, although i did this for > > many years for OMAP chipset(the OS is not linux, it is mixed by REX and my > > own design.). > > 3. Linux kernel choose the last one, handle interrupt in SVC mode, which > > can support nest interrupt if it wants(2.6.35 does not support this). and it > > is very simple to use the interrupted thread's kernel mode stack as the > > interrupt context. if kernel use a specific stack which is for interrupt > > only, the sequences will be : hardware interrupt occurs-->IRQ mode-->SVC > > mode-->backup sp register of interrupted thread to it's TCB--->set sp > > register to be the specific kernel stack address-->call interrupt > > handler--->restore sp of interrupted thread--->return from interrupt. > > this is a little complicated compared with the current design. so i > > agree with the current design. > > > > > > Best Regards > > > >> Date: Thu, 23 Feb 2012 08:41:28 -0600 > > > >> Subject: Re: pagetables used in interrupt context > >> From: c.a.subramaniam@xxxxxxxxx > >> To: buyit@xxxxxxx > >> CC: dhylands@xxxxxxxxx; subingangadharan@xxxxxxxxx; > >> kernelnewbies@xxxxxxxxxxxxxxxxx > > > >> > >> On Thu, Feb 23, 2012 at 6:52 AM, 卜弋天 <buyit@xxxxxxx> wrote: > >> > Hi Subin: > >> > > >> > for kernel version 2.6.35, ARM architecture, when interrupt occurs, > >> > kernel will change from USER/SVC mode to IRQ mode,backup some registers > >> > and > >> > change to SVC mode immediately, handle the real interrupt handler in SVC > >> > mode, which people say in interrupt context. > >> > kernel will use the stack(interrupt context) of interrupted thread to > >> > handle the interrupt, a nd there is no MMU operation which do page table > >> > switch. > >> > so the thread which is interrupted by interrupt, it's kernel mode stack > >> > will be choosed as the interrupt context of current interrupt. > >> > > >> Thanks ! thats a terse explanation! Can you please mention why we do > >> not have a IRQ stack (in terms of size of the stack) to do the > >> processing? > >> > > >> >> Date: Tue, 21 Feb 2012 19:18:32 -0700 > >> >> Subject: Re: pagetables used in interrupt context > >> >> From: subingangadharan@xxxxxxxxx > >> >> To: dhylands@xxxxxxxxx > >> >> CC: kernelnewbies@xxxxxxxxxxxxxxxxx > >> > > >> >> > >> >> Thank you for clearing my doubt. > >> >> > >> >> On Mon, Feb 20, 2012 at 8:39 PM, Dave Hylands <dhylands@xxxxxxxxx> > >> >> wrote: > >> >> > Hi Subin, > >> >> > > >> >> > On Mon, Feb 20, 2012 at 6:47 PM, subin gangadharan > >> >> > <subingangadharan@xxxxxxxxx> wrote: > >> >> >> Hi All, > >> >> >> > >> >> >> Please correct me if I am wrong. In linux each process will have its > >> >> >> own page tables, so when a interrupt happens processor will switch > >> >> >> to > >> >> >> interrupt context > >> >> >> and execute the proper handler. So my doubt, if this is the case, > >> >> >> interrupt hanlder will be using the pagetables of the interrupted > >> >> >> process or is there a separate page table for this. > >> >> > > >> >> > Yep - that's right. Co nceptually you can imagine that the kernel page > >> >> > tables are replicated in each process, so when the interrupt occurs, > >> >> > the kernel mappings will always be in effect regardless of which task > >> >> > is running. How this is actually achieved may vary from architecture > >> >> > to architecture. > >> >> > > >> >> > -- > >> >> > Dave Hylands > >> >> > Shuswap, BC, Canada > >> >> > http://www.davehylands.com > >> >> > >> >> > >> >> > >> >> -- > >> >> With Regards > >> >> Subin Gangadharan > >> >> > >> >> I am not afraid and I am also not afraid of being afraid. > >> >> > >> >> _______________________________________________ > >> >> Kernelnewbies mailing list > >> >> Kernelnewbies@xxxxxxxxxxxxxxxxx > >> >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > >> > > >> > _______________________________________________ > >> > Kernelnewbies mailing list > >> > Kernelnewbies@xxxxxxxxxxxxxxxxx > >> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > >> > > >> > >> _______________________________________________ > >> Kernelnewbies mailing list > >> Kernelnewbies@xxxxxxxxxxxxxxxxx > >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > > > -- > With Regards > Subin Gangadharan > > I am not afraid and I am also not afraid of being afraid. |
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
