IRC channel logs

<damo22>i already wrote some code to do this in my Gnumach_SMP fork using lapic timers but i couldnt finish it because i didnt know where to get the ACPI info

<damo22> https://github.com/zamaudio/GNUMach_SMP/tree/feat-ioapic

<damo22>feel free to take my work and adapt it

<damo22>the interrupt handling has changed upstream in gnumach since i did this work

<damo22>i did not have time to rebsae

<damo22>i dont know if you can use multiprocessor without advanced PIC interrupts

<damo22>so you probably need to fix both

<almuhs>Richard told me that IOAPIC is necessary to real SMP

<damo22>yup

<almuhs>but I want to refactor my code, because Richard told me that my code is very dirty

<almuhs>and, the most dirty piece of my code is the cpu enumeration, and the search in ACPI tables

<damo22>i calibrated the lapic timer using PIT

<damo22>all the code for that is in my branch

<almuhs>but, if your IOAPIC code is based in the mine, you will need to refactor your code too

<almuhs>by this reason, I want to use your ACPI translator, to clean this dirty piece

<damo22>thats right, but if youre refactoring yours, and adding IOAPIC support, you can borrow code from my branch to get the IOAPIC working

<almuhs>It's true

<damo22>you dont have to start from scratch

<almuhs>the next step, when I get to find APIC structures from your translator, will be share this information to gnumach

<almuhs>**when I get, I said

<damo22>there is another difficult part i did not fix yet

<almuhs>I will have to study how to do this

<damo22>getting the timer working is quite tricky

<damo22>because some motherboards have timer interrupt wired to PIC even though they use APIC for everything else

<almuhs>after this, I will need to modify the gnumach boot sequence. Because, in the current sequence, the cpus are turning on before load Hurd

<almuhs>I need to move this tasks to a next step. Probably, separate this functions from the gnumach boot sequence

<damo22>start with one thing

<damo22>decide how to communicate the acpi info to gnumach

<almuhs>my first step is to explode your translator for get the APIC structures

<almuhs>at first, only find these

<damo22>hmm this means bootstrap will need to load ACPI translator as well

<damo22>we need to bootstrap every translator almost

<almuhs>yes. The SMP process will start after Hurd loading

<almuhs>instead start from gnumach, starts from hurd

<damo22>errr

<damo22>shouldnt the kernel boot first

<almuhs>I will use your translator to find APIC structures. After this, I will share this information with gnumach. And then, I will start the cpus startup

<damo22>i dont think this will work

<almuhs>gnumach starts without knowledge about another cpus

<almuhs>when Hurd starts, then we starts the another cpus

<almuhs>It's necessary to be careful about concurrency, but It's possible

<damo22>it seems gnumach could function better if it had ACPI built in

<damo22>otherwise its going to be crazy to start the system

<almuhs>the problem is that, in the current implementation, the ACPI reading requires very dirty addressing

<almuhs>because the ACPI reading is done before paging is configured.

<almuhs>and, if I move the ACPI reading after paging, then I have more restrictions to access to this memory

<damo22>ACPI translator needs /dev/mem

<almuhs>maybe I can set any flag to detect when ACPI translator and /dev/mem are ready

<damo22>if you want that to work without a root filesystem we will need to vm_map it

<damo22>but if paging is not available..

<damo22>then gnumach needs ACPI built in

<almuhs>the advantage of start the process from Hurd is that, in this boot step, the paging is ready

<almuhs>and the memory is already configured

<almuhs>so I can avoid these strange addressing problems

<damo22>pci has a similar issue

<damo22>its a hardcoded address

<damo22>i solved it by vm_map on /dev/mem and providing the offset as a device

<damo22>device_map

<almuhs>my idea is wait until hurd (and the most system) is loaded and then, start the cpus startup process

<damo22>i think we would want the startup process to benefit from multiprocessor

<almuhs>keep the cpus startup in gnumach boot sequence?

<damo22>instead of hacking the boot process to work around missing ACPI

<damo22>just put it in the kernel

<almuhs>but then we have the current problem

<almuhs>I don't want to hardcode the lapic address because It's possible than this could cbange in some machines

<damo22>read it from the table

<damo22>its in memory at boot

<almuhs>but, before paging is very dirty, and after paging can be restricted to access

<damo22>you dont even need paging

<damo22>its at a hardcoded address

<damo22>to find the ACPI table

<almuhs>my current implementation is built as you're told me

<damo22>no you hardcoded 0xfee00000

<almuhs>but It's very dirty and even dangerous

<damo22>i mean, hardcode the ACPI start

<damo22>and parse the table in kernel

<damo22>it should be pretty minimal

<almuhs>hardcode RSDT address?

<damo22>yeah

<damo22>0xe000 or someting

<almuhs>but we continues with problems to access to lapic address

<damo22>why?

<almuhs>because is very high

<damo22>its less than 4GB

<almuhs>before paging, we cannot access this address

<damo22>0xfee0000 < 4GiB

<almuhs>yes, but in this step, the memory addressing space is even more limited

<almuhs>we can not read after 0x7000

<almuhs>because the kernel is mapped after this

<damo22>err do it in protected mode

<almuhs>I think this step is in protected mode

<almuhs>with segmentation

<damo22>at the point where you need ACPI tables, you should have access to < 4GiB of ram

<almuhs>I think is not get until paging

<damo22>if its in protected mode it should work to do *((volatile uint32_t *)0xfee00000) ?

<damo22>or wherever the address is configure

<damo22>d

<almuhs>depending if segmentation configuration, is not?

<almuhs>depending of the kernel GDT

<almuhs>**depending of

<damo22>idk, maybe you can change it

<damo22>i gtg

<damo22>work

<almuhs>gtg?

<damo22>got to go

<damo22>im working now

<almuhs>oh, ok

<almuhs>I have to sleep

<damo22>i suggest to write a minimal module that you can use to parse the APIC table only and then you can use it in the kernel itself it would be easier

<almuhs>parse ACPI table from gnumach, is not?

<damo22>yeah

<almuhs>ok

<almuhs>and move the code to a next step, after protected mode

<damo22>i cant see how you will make it boot otherwise

<damo22>it would be very messy

<almuhs>otherwise is to boot gnumach using one cpu, and find the rest of the cpus once Hurd has booted, using your translator

<almuhs>this is the idea that Samuel told me a year ago

<damo22>we need the APIC to be functioning by the time ext2fs asks rump for the disk

<damo22>otherwise we cant get disk interrupts

<damo22>for the root filesystem

<almuhs>ext2fs cannot be bounded to cpu0?

<damo22>it probably can, but i think we should make gnumach multiprocessor aware

<damo22>from the beginning

<almuhs>gnumach probably runs in one core. The most important parallelization is the Hurd servers

<almuhs>get that hurd servers can be distributed in multiple cpus

<damo22>yeah, lets not make it cpu0 bound just because we want to put ACPI outside the kernel

<damo22>its a bad design imho

<damo22>the kernel needs to know 1. how many processors are in the system 2. how interrupts are configured

<damo22>and it already has the info in memory at a hardcoded address

<almuhs>yes, but is It needed to know this during the boot?

<damo22>so why put that into userspace first, and then read it back into the kernel?

<damo22>it makes no sense

<almuhs>my sense is to avoid addressing problems, really

<almuhs>but I understand what you're telling

<damo22>ESCD address = 0xe0000

<damo22>this does not change

<almuhs>but where can I put the cpus enumeration call?

<almuhs>the ACPI reading, in other terms

<damo22>i dont know exactly

<almuhs>this is the problem

<damo22>but im saying you can write something that parses the ACPI table to get the hardcoded address

<damo22>then you will have it

<almuhs>yes, but I need to access to ACPI table to parse It

<damo22>you can do it

<damo22>change cpu mode if necesssary

<almuhs>change GDT?

<damo22>or boot up into BSP

<damo22>and then when it has access to 4GiB

<damo22>read it

<damo22>idk

<damo22>sorry i need to go

<almuhs>I have to find if BSP have access to 4GiB before paging

<almuhs>ok

<almuhs>I need to sleep, It's very late

<almuhs>bye

<damo22>bye

<damo22>i think we should store a pointer to the acpi tables in gnumach within a global variable in an acpi.c module that allows getting the tables

<damo22>and any parsing can be done in the module

<damo22>it can be very small

<damo22>youpi: if interrupts were handled via a server task, perhaps we would get irq scheduling for free?

<damo22>im happy to port some of my acpi code to gnumach, it should be trivial to read from a fixed address

<damo22>the main problem with making interrupts handled in userspace is that the timer interrupt needs to be configured in gnumach, and it needs to configure the APIC to do this, so it really does need the ACPI tables for SMP somehow

<damo22>but to enable native PCI interrupts you need a full ACPI parser

<damo22>to know their configuration

<damo22>i think the config for that is buried in one of the huge ACPI tables

<damo22>yep we need ASL parser in gnumach to fully support the IOAPIC

<damo22>otherwise the pci interrupts will be undefined

<damo22> https://www.acpica.org/licensing

<damo22>GPLv2/BSD/"intel" licence

<damo22>can i copy the linux implementation instead in drivers/acpi/acpica it looks better written /* SPDX-License-Identifier: BSD-3-Clause OR GPL-2.0 */

<gnu_srs1> damo22: Maybe you should be reluctant with gpl-2.0 code?

<damo22>it says it is dual bsd / gpl2

<damo22>i checked every file

<youpi>importing BSD-available code into gnumach is fine

<damo22>youpi: is this okay if i import direct from linux kernel: /* SPDX-License-Identifier: BSD-3-Clause OR GPL-2.0 */

<damo22>i assume so

<damo22>but i dont know the copyright line

<damo22>i think we just need drivers/acpi/acpica/*.{c,h}

<damo22> $ git clone https://github.com/acpica/acpica

<damo22> $ cd acpica

<damo22> $ generate/linux/make-patches.sh -u [commit ID]

<damo22>we use that to generate the sources

<damo22>maybe one day we can have generate/hurd/..

<damo22>ok i have a script that can generate the latest linux acpica sources from upstream acpi

***rekado_ is now known as rekado

<almuhs>damo22: what address do you use to map APIC table? or RSDT table. to hardcode this address in my code

<almuhs>btw, what is the page size in gnumach?

<youpi>on x86 it's 4096 bytes

<almuhs>then I go to check the MADT size

<almuhs>oops, It's very complex to calculate

<almuhs>44 bytes + the size of Interrupt Controller Structure

<almuhs>wait... if the page size is 4096 bytes, the system only have one page

<almuhs>wait, not not

<almuhs>4 KiB, not 4GiB ... a lapsus

IRC channel logs

2020-04-22.log