I removed these from my group reply, as they don't seem to partake in
this discussion.
Cc: rubini@xxxxxxxx, rubini@xxxxxxxxx, rubini@xxxxxxxx,
rubini@xxxxxxxxxxxxx, rubini@xxxxxxx
On Wed, Sep 15, 2004 at 12:00:24AM +0530, Dhiman, Gaurav wrote:
> [..] If this is the physical base address of IDT, where in kernel are
> we setting the "idtr" register, so CPU has reference to IDT.
It's set in head.S. Search for idt_descr. And it's the virtual address.
The physical address would be (virt_addr - KERNEL_OFFSET).
> [...] But according to my knowledge and what I read IDT should not
> exceed more than 1 MB.
That limitation applies to the real mode. In protected mode, the IDTR
provides not only a base address, but also a limit (which _can_ exceed 1
MB).
> d) As Intel CPU multiplies the IRQ number (which it receives from PIC)
> with 4 (as entry in IDT should be of 4 bytes), why linux IDT entries are
> of 16 bytes. Don't they corrupt the CPU calculations for getting the
> actual ISR address form IDT entry ?
4 bytes in real mode, in protected mode 8 bytes for ia32, 16 bytes for
ia64.
> [...] in kernel I did not see any code which interprets the received
> bit string to actual IRQ number. Where this conversion is done ?
2.4: include/asm-i386/hw_irq.h:BUILD_IRQ(nr)
2.6: entry.S:irq_entries_start
For each vector the vector number (minus 256) is pushed on the stack and
retrieved in do_IRQ (regs.orig_eax) to determine the IRQ number.
> Please if you know some link to good article which can tell how CPU
> interprets the IRQ number received from PIC and map it to the IDT entry
> index.
Intel Architecture Manuals.
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
