On 13/11/18 05:39, Almudena Garcia wrote:
> In my docs, I've written the procedure to get this:
>
> /- How to find APIC table
> To find APIC table, we can read RSDT table RSDT reference. To get the
> address of RSDT, we need to read RDSP table./
> /Once got RSDT table, we need to read Entry field,
>
> I mean, the kernel can have its own ACPI implementation, just enough to
> get the information needed for SMP.
Ok. What I need is to read RSDT table, to get the pointer to APIC table,
which store the information about processors and ioapic
In my docs, I've written the procedure to get this:
Samuel Thibault, le lun. 12 nov. 2018 19:29:57 +0100, a ecrit:
> Almudena Garcia, le lun. 12 nov. 2018 19:12:16 +0100, a ecrit:
> > I think if you need ACPI in gnumach to provide SMP support for the
> > kernel, then ACPI tables reading functionality should be in gnumach
> > then?
> >
> >
Almudena Garcia, le lun. 12 nov. 2018 19:12:16 +0100, a ecrit:
> I think if you need ACPI in gnumach to provide SMP support for the
> kernel, then ACPI tables reading functionality should be in gnumach then?
>
> I agree. In this case, access to ACPI tables through a translator could
> pro
>
> I think if you need ACPI in gnumach to provide SMP support for the
> kernel, then ACPI tables reading functionality should be in gnumach then?
I agree. In this case, access to ACPI tables through a translator could
produce a recursive dependency problem (Translator could need gnumach, and
gnu
Hello,
This patch provides a translator for mounting x86 ACPI tables under a
path as read-only files. I believe it is needed so that other things
that depend on ACPI to find the base address such as Intel's IOMMU (DMAR
table), memory mapped PCI space (MCFG table) etc, can be discovered in
userspa
