Re: Recent patches break ACPI tables

[Almudena Garcia]

But the code which starts the secondary cpus is so much later than the crash.

Then, the crash could be produced by the reading of ACPI tables, which are 
supposed to be in a certain memory region, defined by a physical address. 

phystokv will doesn't solve fully the problem, because the lapic address is out 
of the range allowed by this function. Currently, we are using paging to map 
every ACPI table which we need to access (to get a virtual address of this).

But the search of the initial ACPI address is based in a physical address 
range.  

El lunes 19 de junio de 2023, luca@orpolo.org escribió:
> Hi,
> 
> Il 18/06/23 22:52, Samuel Thibault ha scritto:
> > Hello,
> > 
> > Damien Zammit, le dim. 18 juin 2023 00:48:15 +0000, a ecrit:
> >> Almu and I discovered that the following commit breaks --enable-apic 
> >> --enable-ncpus= >1 --disable-linux-groups
> >>    
> >> * d972c01c pmap: only map lower BIOS memory 1:1 when using Linux drivers
> >>
> >> I believe the ACPI tables need temporary low memory mapping to access them.
> > 
> > Luca, what do you think?
> > 
> > Can we perhaps fix the ACPI code to use phystokv to translate from
> > physical addresses to virtual addresses?
> 
> yes that's probably the best way to fix the code.
> 
> By the way, how, is it exactly crashing? It might not be related to 
> ACPI/APIC code, I tried a simple program on a 32-bit kernel with 
> --enable-apic but without --enable-ncpus and it seems to work. If I use 
> --enable-ncpus=2 it seems to fail quite early, even without -smp=2 in 
> qemu. At the moment I'm not able to set a breakpoint even to the C entry 
> point, I'm not sure why, I think I did it in the past.
> 
> Maybe there is some other part, SMP_specific, that assumes the lower 
> memory is mapped 1:1? I remember there was some bootstrap code to start 
> the secondary cpus, but I don't remember the details.
> 
> 
> Luca
> 
>

-- 
Enviado desde mi dispositivo Sailfish