bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to create a Hurd translator?


From: Almudena Garcia
Subject: Re: How to create a Hurd translator?
Date: Wed, 22 Apr 2020 19:18:48 +0200

fix: lapic address is higher than 0xC0000000 (not 0x7000)

El mié., 22 abr. 2020 a las 19:15, Almudena Garcia (<liberamenso10000@gmail.com>) escribió:
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.thibault@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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]