IRC channel logs


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>lapic is not per-cpu
<damo22>well its the same address for all cpus
<damo22>but independent values per cpu
<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
<damo22>where should the logic live?
<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>it is not "initialized"
<damo22>it points to mmaped io
<luckyluke>I mean, the pointer to the apice structure
<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>we dont need the lapic pointer
<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>oh ok
<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?
<luckyluke>During vm bootstrap
<damo22>cpuboot.S ?
<damo22> /* Load int_stack_top[cpu] -> esp */
<damo22> CPU_NUMBER(%edx)
<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
<luckyluke>#0 splvm () at ../i386/i386/spl.S:122... (full message at <>)
<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
<damo22>its a severe performance hit
<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>Probably with some linker script support
<luckyluke>IIRC lapic is also initialized in setup_ma in, but after vm_mem_bootstrap
<damo22>ohhh machine_init is called later
<damo22>yeah that makes sense
<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
<damo22>well youpi suggested it
<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>ACTION whips up a patch
<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: -- is the m4 manual the best way to understand this issue?
<gabber>nvm, got it