IRC channel logs

<damo22>youpi: does ICR need to be set to apic destination self to receive an interrupt?

<damo22>if ISR is set, that necessarily means the interrupt is triggered right?

<youpi>I don't know what ICR and ISR are

<youpi>really I have next to zero knowledge of how SMP works on x86

<youpi>the only thing I know is that there's IPI that allows to perform cross-cpu interrupts

<youpi>but even that I have no idea how it's configured

<damo22>hmm sizeof(idt) is that size of only one entry??

<youpi>depends what type idt is exactly

<youpi>(but the answer in all cases is: no)

<damo22>sizeof(mp_desc_table[cpu]->idt)

<youpi>that's struct real_gate. idt[IDTSZ];

<youpi>so sizeof will give you the size of the idt structure field

<youpi>i.e. the whole array

<youpi>if it was struct real_gate *idt;, sizeof would have given you the size of a pointer

<youpi>only sizeof(*idt) would give you the size of one element (since that's what you designate)

<damo22>struct mp_desc_table {

<damo22> struct real_gate idt[IDTSZ]; /* IDT */

<damo22>ah :

<damo22> while (iie->entrypoint)

<damo22> {

<damo22> _fill_idt_gate(mp_desc_table[cpu]->idt, iie->vector, iie->entrypoint,

<damo22>so if the first ones are zero

<damo22>or undefined, it will skip the rest

<youpi>yes

<youpi>but how can some entries have entrypoint set to NULL?

<youpi>idt_inittab has its element with a non-NULL entrypoint field

<damo22>ah this is not for regular interrupts anyway

<damo22>i need int_init.c

<damo22>andddd the IDT on APs is loaded BEFORE the gates are filled for regular interrupts!

<damo22>hmm didnt help, maybe i need processor focus on

<damo22>is it possible the idt_table needs to be consecutive all the way to 255?

<damo22>int_table

<damo22>like, does the position in the intterrupt table correspond necessarily to the vector?

<youpi>in real mode, yes

<youpi>in protected mode, no

<youpi>the idt is just the length you want

<youpi>but it needs to be consecutive, indexed by interrupt number, yes

<damo22>i have an entry INTERRUPT(251)

<damo22>its at postition 16

<damo22>counting from 0

<damo22>but its not working

<damo22>CR2=fffffffc

<damo22>i set the LDR to apic id of self

<damo22>i think that means the processor receiving an interrupt will service it itself

<damo22>wierd i got it to raise an ISR 251 but the vector is masked and wont unmask:

<damo22>LVT1 0x000180fb active-hi level masked Fixed (vec 251)

<damo22>ISR 251(level)

<damo22>ok managed to unmask the irq but it still crashes

<damo22>it must be something related to the IDT

<damo22>"*NOTE* Because IA-32 tasks are not re-entrant, an interrupt-handler task must disable interrupts between the time it completes handling the interrupt and the time it executes the IRET instruction. This action prevents another interrupt from occurring while the interrupt task's TSS is still marked busy, which would cause a general-protection (#GP) exception."

<Pellescours>but you already do that no?

<damo22>yeah its already in the code

<damo22>i saw that the IDT is not set up correctly in memory

<damo22>its somehow pointing to the wrong memory address for the entrypoint

<Pellescours>linear vs physical memory issue when configuring idtr?

<damo22>no the GDT is already set up

<damo22>int_entry_table[16] is somehow at 0xc1008e00 but that is wrong

<Pellescours>the int_entry_table is hardcoded in asm, how could his value be wrong?

<damo22>the value in the binary is good

<damo22>the value that gets loaded into RAM is bad

<Pellescours>is it allowed to modify the idt after it was loaded ? Because currently, we load idt before setting the int_entry_table in it

<damo22>it should be 0xc1008014

<damo22>for the entrypoint

<damo22>i think so

<damo22>bsp does it anyway

<Pellescours>I suppose that, for cpu0 the entrypoint is correct, otherwise we would have issues already

<damo22>why is INTERRUPT(n) defined with .data 2

<damo22>isnt that two bytes?

<Pellescours>damo22: in gdt.h KERNEL_TSS is defined with a comment /* master TSS (uniprocessor) */ should this value be different per cpu ?

<damo22>0x00088014 0xc1008e00

<damo22>somehow the address should be 0xc1008014

***roptat is now known as Guest2228

<damo22>unless qemu is showing bytes differently

<damo22>grouped*

***Guest2228 is now known as roptat_

<Pellescours>having in ap_ktss_init the exception_stack is static variable in the function. Does that mean all cpu will share the same memory area?

<damo22>lets get -smp 2 working first

<damo22>0x00087a48 0xc1008f00 <--- that is the idt entry for vector 0 on the bsp

<damo22>i dont know why the 8e and 8f are different

<damo22>0008 7a48 c100 8f 00

<damo22>SEL LOW HIGH TYPE 00

<damo22>ok the address is correct

<damo22>its split into two words

<damo22>what is IDT type 0x8f and 0x8e ?

<damo22>c11d41e0: 0x48 0x7a 0x08 0x00 0x00 0x8f 0x00 0xc1

<damo22>(bsp vector 0)

<damo22>f51f27d8: 0x14 0x80 0x08 0x00 0x00 0x8e 0x00 0xc1

<damo22>(AP vector 251)

<damo22>0x8e is interrupt gate, 0x8f is trap gate

***roptat_ is now known as roptat

***roptat is now known as help

<damo22>i think theres a page fault on the AP

<damo22>when the interrupt happens

<damo22>since CR2 = 0xfffffffc

<damo22>EIP = ca2ea520:

<damo22>ive pushed something that still doesnt quite work

***job is now known as pandakekok9

IRC channel logs

2022-10-15.log