After this talk, I agree with Damien about the cpu enumeration (reading from ACPI tables), must be implemented in gnumach. But my question is, how can I avoid the dirty addressing currently in use?
Currently, the APIC table is read before configure paging, to avoid paging restrictions when I access to this memory space. But this cause another problem: the lapic is mapped in a very high address (upper to 0x7000), and is unreachable in this moment. In my solution, I take notes about the lapic address and wait until paging is enabled to map this address. But this is a dirty solution, in my opinion. My code is here: https://github.com/AlmuHS/GNUMach_SMP/blob/smp/i386/i386at/acpi_rsdp.c Are there any other solution for this? Furthermore, I create many global variables that, talking with Richard, he told me that is a bad practice. How can I solve this problem? Thanks El mié., 22 abr. 2020 a las 10:03, Samuel Thibault (<samuel.thiba...@gnu.org>) escribió: > Damien Zammit, le mer. 22 avril 2020 15:57:26 +1000, a ecrit: > > >> I have a feeling we are going to need all of acpica incorporated into > gnumach eventually, > > >> because you need a full ACPI parser for learning the PCI interrupts > and proper shutdown mechanism. > > > > > > Can't the parsing be done in userland (like we do for shutdown), and > > > just hand over the information to the kernel? > > > > Shutdown mechanism can be done this way, yes - there is plenty of time > to parse the tables in userspace before shutdown. > > > > However, I believe interrupt configuration of the IOAPIC(s) and > activation of the other cores > > needs to be done very early, even before the first disk interrupt occurs. > > I was thinking that perhaps the system can boot with just one core and > enable the other cores after bootstrap. We don't really need smp support > very early in the boot. > > > It seems much more appropriate and easier to read the in-memory ACPI > tables at a fixed memory address (eg. ESCD 0xe0000) > > in gnumach and bootstrap the system from an SMP enabled kernel so the > kernel already knows > > how to drive interrupts and timers before any other servers launch. > > If parsing the ACPI tables just for SMP is simple enough, yes, that > should be fine and make the whole picture simpler. > > > Are you suggesting to create an interrupt/timer server? > > No, that seems too extreme to me. > > Samuel > >