IRC channel logs
2023-06-20.log
back to list of logs
<Guest20>Regarding the comments Luca is encountering on CPUNUMBER in GnuMach, perhaps the solution is to do like Linux and use swapgs for per-cpu variables <damo22>well its the same address for all cpus <damo22>another solution is to set the base address of lapic using MSRs and then assume the lapic is at a fixed address <damo22>instead of reading it from a structure <damo22>youpi: this lapic stuff is very x86 ISA specific <luckyluke>damo22: the issue is rather that the lapic structure is used unitialized, the specific address is not relevant <damo22>luckyluke: the lapic structure is a mirror of what is in the hardcoded register layout <damo22>i thought the problem is that the base address is unavailable because the pointer cannot be dereferenced without page tables? <luckyluke>The pointer is 0 before lapic is initialized, and during init it creates the mapping to access the registers <luckyluke>Before my patch "0" was a valid address, mapped 1:1 <damo22>if you know the base address is 0xfee00000 in advance of the pointer being initialized, cant you just use that? <damo22>and we can enforce it to be that address <damo22>for example, we could access the MMIO via a constant offset from the base address <luckyluke>We need to map the physical address somewhere to access it anyway <damo22> lapic_unit = kmem_map_aligned_table(apic->lapic_addr, sizeof(ApicLocalUnit), <luckyluke>But yes, we could map it directly without a pointer, anyway it needs to be done before CPU_NUMBER is called, or we force CPU=0 as almuhs suggested <damo22>when is the first CPU_NUMBER called? <damo22> /* Load int_stack_top[cpu] -> esp */ <damo22> movl CX(EXT(int_stack_top), %edx), %esp <luckyluke>It's before enabling the other cpus, I think I added the backtrace in my email <damo22>i dont understand why lapic is not initialised yet at that point.... setup_main is called after i386at_init <damo22>i think we should avoid putting more instructions into CPU_NUMBER <luckyluke>I like the idea of avoiding the pointer dereference, we could initialize the directmap (so with a fixed offset) early for all memory-mapped registers <luckyluke>IIRC lapic is also initialized in setup_ma in, but after vm_mem_bootstrap <damo22>ohhh machine_init is called later <youpi>if it's just a pointer that is not initialized yet, it can be pre-initialized to point to a dumb bootstrap structure <youpi>that e.g. always says it's cpu 0 <damo22>static ApicLocalUnit dummy_lapic = {0}; <damo22>volatile ApicLocalUnit* lapic = &dummy_lapic; <luckyluke>Yeah that is simpler indeed, I was having issues yesterday with that approach but I suspect I have some bad RAM on my laptop <luckyluke>The early map can maybe wait for a kernel map cleanup, to allow e.g. a bigger ramdisk <damo22>the change i suggested fixes master <janneke>ACTION built rumpkernel natively on the (Guix) Hurd <janneke>(mostly thanks to pruning the rumpkernel archive) <janneke>what, does hurd not have a "check" target? <janneke>make: *** No rule to make target 'check'. Stop. <janneke>ACTION tries to build the hurd natively <janneke>hmm INSTALL says there is a check target <janneke>damo22: i've just built rumpkernel natively on the hurd, not sure what problem you had building it? <luckyluke>janneke: is guix hurd using only userspace drivers now? <janneke>luckyluke: if you start with "noide", yes <gabber>i'm struggeling getting autoconf to create a config file for my proto riscv64 port.. m4 complains "ERROR: end of file in string" at line 51 of this paste: https://termbin.com/qjcl -- is the m4 manual the best way to understand this issue?