Re: Recent patches break ACPI tables

[Almudena Garcia]

Maybe add a little conditional in the assembly code (return 0 if lapic is 0, 
using cmp and je) could fix the problem in a simpler way

El lunes 19 de junio de 2023, luca@orpolo.org escribió:
> Il 19/06/23 20:35, Almudena Garcia ha scritto:
> > 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.
> 
> I could go a bit further with debugging, and it seems that the problem 
> is a bit different, it seems removing the 1:1 map exposed an issue that 
> went hidden so far.
> 
> In my test the cpu is reset by a triple fault (you can see this by 
> enabling interrupt and cpu_reset logging with qemu, e.g. using -d 
> int,cpu_reset) which is triggered after the first call to splvm:
> 
> (gdb) bt
> #0  splvm () at ../i386/i386/spl.S:122
> #1  0xc1001da6 in pmap_enter (pmap=<optimized out>, v=<optimized out>, 
> pa=<optimized out>, prot=<optimized out>, wired=<optimized out>) at 
> ../i386/intel/pmap.c:2171
> #2  0xc1029b99 in pmap_steal_memory (size=<optimized out>) at 
> ../vm/vm_resident.c:278
> #3  0xc1029c48 in vm_page_bootstrap (startp=<optimized out>, 
> endp=<optimized out>) at ../vm/vm_resident.c:207
> #4  0xc101b893 in vm_mem_bootstrap () at ../vm/vm_init.c:65
> #5  0xc10161d1 in setup_main () at ../kern/startup.c:115
> #6  0xc1004652 in c_boot_entry (bi=<optimized out>) at 
> ../i386/i386at/model_dep.c:578
> #7  0xc1000093 in iplt_done () at ../i386/i386at/boothdr.S:103
> (gdb) si
> 124           cli
> 1: x/i $pc
> => 0xc100ac5d <splvm+5>:      cli
> (gdb)
> 125           CPU_NUMBER(%edx)
> 1: x/i $pc
> => 0xc100ac5e <splvm+6>:      mov    %cs:0xc109bc6c,%edx
> (gdb)
> 0xc100ac65    125             CPU_NUMBER(%edx)
> 1: x/i $pc
> => 0xc100ac65 <splvm+13>:     mov    %cs:0x20(%edx),%edx
> (gdb)
> t_page_fault () at ../i386/i386/locore.S:435
> 435           pushl   $(T_PAGE_FAULT)         /* mark a page fault trap */
> 1: x/i $pc
> => 0xc100a42c <t_page_fault>: push   $0xe
> 
> ... and here it will enter recursively t_page_fault, because in 
> trap_from_kernel there is another CPU_NUMBER. I guess the triple fault 
> is triggered because at some point the exception stack overflows.
> 
> With --enable-ncpu=2 it seems that CPU_NUMBER is
> 
> #define       CPU_NUMBER(reg) \
>       movl    %cs:lapic, reg          ;\
>       movl    %cs:APIC_ID(reg), reg   ;\
>       shrl    $24, reg                ;\
> 
> and at this stage the lapic pointer is not yet initialized:
> 
> (gdb) p lapic
> $4 = (volatile ApicLocalUnit *) 0x0
> (gdb) x &lapic
> 0xc109bc6c <lapic>:   0x00000000
> 
> I guess so far this worked because the address 0 was mapped, and now it 
> isn't.
> 
> I'm not sure what would be the proper way to solve this. I tried 
> anticipating the call to machine_init() to be before vm_mem_bootstrap() 
> (to have lapic initialized) but this triggers another assert.
> 
> Any idea?
> 
> 
> Luca
> 
>

-- 
Enviado desde mi dispositivo Sailfish