IRC channel logs

<damo22>iska: yes we are very close, i mean, it does boot with smp but gets stuck due to some kind of threading issue because we are running code paths that have not been tested with multiprocessor yet

<damo22>start acpi: acpi pci rumpdisk Kernel Page fault trap, eip 0xc10321b9

<damo22>kernel: Page fault (14), code=0

<damo22>Stopped at thread_select.part.0.constprop.0+0xc9: cmpl $0x1,0x58(%eax)

<damo22>thread_select.part.0.constprop.0(0,0,7,0,0)+0xc9

<damo22>thread_block(c1061a80,f484c000,f4845ee0,c1061671)+0x4f

<damo22>what are all those zeroes?

<youpi>kdb doesn't know how many parameters functions take

<youpi>so it just peeks what is on the stack

<damo22>if im iterating through a task's threads to sync the iopbs, do i need to lock the task?

<youpi>you very probably need to lock something to sync on the task list yes

<damo22>im using the iopb simple lock, but not sure if thats enough

<damo22> simple_lock (&new_task->machine.iopb_lock);

<damo22> update_ktss_iopb (new_task->machine.iopb, new_task->machine.iopb_size); <--- this function now iterates through a tasks threads to sync them all

<damo22> simple_unlock (&new_task->machine.iopb_lock);

<youpi>it's not enough concerning the iteration itself

<damo22>ok

<youpi>about iterating over threads to shoot tlb, did you see signal_cpus' comment ?

<damo22>yes its a long comment

<damo22>ohh i need to read it again

<youpi>and PMAP_UPDATE_TLBS' users variable

<damo22>there is a function that is supposed to be called by the interrupt right?

<damo22>by each cpu

<youpi>yes but I'm talking about iterating over threads etc.

<youpi>but that's already handled by the users variable

<damo22>cpus_using ?

<youpi>remember that mach has already been run on smp

<youpi>just not on x86 smp

<youpi>so normally only x86-specific code needs updating

<youpi>yes, cpus_using

<damo22>ok yes

<damo22>im mostly working in i386/

<damo22>i think we need to reintroduce some IPLs

<youpi>I don't think we need

<youpi>linux doesn't use them

<damo22>An implicit assumption made

<damo22>* throughout the TLB code is that all kernel code that runs at or higher

<damo22>* than splvm blocks out update interrupts, and that such code does not

<damo22>* touch pageable pages.

<youpi>disabling interrupts + lock is enough to protect things

<youpi>yes, which means cli

<damo22>ok

<youpi>(is enough)

<damo22>cool

<damo22>but for the TLB sync, i think we just have to implement interrupt_processor(cpuX) as a IPI that triggers pmap_update_interrupt() on cpuX

<youpi>yes

<damo22>and ensure interrupts are enabled when that is called

<damo22>at least on the calling cpu

<youpi>?

<youpi>one doesn't have to ensure interrupts are enabled

<youpi>just that they happen to get enabled sooner or later

<youpi>which is all what spl is about

<damo22>ok

<youpi>you need that for the clock to advance anyway..

<damo22>ok. This ktss thing is tricky though. im not sure why the threading is trampling all over each other

<youpi>for ktss I'd say just interrupt all threads and be done

<youpi>iopl change is rare enough that we don't need to optimize that

<youpi>all *cpus* actually

<damo22>all cpus :D

<damo22>that would be easier

<damo22> for (slot = 0; slot < NCPUS; slot++)

<damo22> {

<damo22> if (machine_slot[slot].is_cpu)

<damo22> update_ktss_iopb_per_cpu (new_iopb, size, slot);

<damo22> }

<damo22>hmm its still page faulting at thread_select

<damo22>after thread_block

<damo22>so when splvm() is called that sets SPL7 ?

<damo22>and cli

<damo22>and we dont need to distinguish between splvm and splsched?

<damo22>youpi: in thread_block, why does cpu_number() get called twice?

<damo22>shouldnt it remember the cpu number it first called?

<damo22>or the opposite, the myprocessor variable should be recomputed inside the spl

<damo22>(qemu) cpu 0

<damo22>(qemu) x 0xf47ffffc

<damo22>f47ffffc: Cannot access memory

<damo22>(qemu) cpu 1

<damo22>(qemu) x 0xf47ffffc

<damo22>f47ffffc: 0x00000000

<damo22>what the hell

<damo22>when the thread swaps, the other cpu cant read its memory

<damo22>why would that be?

<damo22>do we need FS and GS set up?

<damo22>problem is %eax is zero when it shouldnt be

<damo22>its trying to dereference 0x58(%eax)

<damo22>interesing

<damo22>interesting*

<damo22>my CPU_NUMBER() function was borked

<damo22>bad address ff008f

<damo22>...)

<damo22>linux_init(6,c11d0078,f8e90000,f9690000,f67ff000)+0x1a

<damo22>how do i allow low addresses in bios such as 0xf0000 to be allowed in kernel? im getting kernel accessed userspace

<damo22>how do i allow low addresses in bios such as 0xff000 to be allowed in kernel? im getting kernel accessed userspace page fault

IRC channel logs

2022-10-10.log