Re: Need help from a VAX abi expert (was: Reproducable kernel crash)

[Anders Magnusson <ragge%tethuvudet.se@localhost>]

    Happy new year yourself Martin! :-)

Den 2025-01-11 kl. 13:14, skrev Martin Husemann:

> Hi folks,
>
> new year, new try: I would love to get some help from someone who understands
> the low level details of a VAX calls frame better than me:
>
> https://mail-index.netbsd.org/port-vax/2024/02/29/msg004920.html
>
> The problem: I would like to get rid of the superflous (and harmfull)
> pmap_activate() call in vax/vm_machdep.c
>
> https://nxr.netbsd.org/xref/src/sys/arch/vax/vax/vm_machdep.c#113
>
>
>     107 	/*
>     108 	 * Activate address space for the new process.	The PTEs have
>     109 	 * already been allocated by way of pmap_create().
>     110 	 * This writes the page table registers to the PCB.
>     111 	 */
>     112 	pcb2->pcb_pm = NULL;
> ->> 113 	pmap_activate(l2);
>     
    Not that I really know how everything about this is expected to
    interact, but I at least understand what the routine does :-)
    I'll explain how it works currently.
    
    pmap_activate() ensures that the page tables for the new lwp are correctly setup (as is written in the comment above).
    
    Since an lwp on vax runs as its own (vax) process it must have
    everything setup in its PCB as a new process and must be handled as
    a new process, so cpu_lwp_fork() must initialize the page tables as
    well.  
    
    The panic given in the ticket is that it gets an AST in kernel mode,
    which is unwanted.   ASTs are delivered to userspace to force a
    context switch.
    This error is typical that the PCB is not initialized correctly.
    
    So, I do not think it has anything to do with the CALLS frame.
    
    Followup question is: If this is not the correct way of working
    (which means I misunderstood something sometime 🙂 ), how should it
    work?
    
    -- Ragge
    
>     114 
>     115 	/* Mark guard page invalid in kernel stack */
>     116 	kvtopte((uintptr_t)uv + REDZONEADDR)->pg_v = 0;
>     117 
>     118 	/*
>     119 	 * Set up the calls frame above (below) the trapframe and populate
>     120 	 * it with something good.  This is so that we can simulate that we
>     121 	 * called cpu_lwp_bootstrap with a CALLS insn and it can return to
>     122 	 * sret.
>     123 	 */
>
> Without that pmap_activate() the new lwp can not start (lwp_startup crashes
> when jumping into it). My guess: the pmap_activate() hides something missing
> from the cpu_lwp_bootstrap() setup.
>
> Can you help spot what is missing there?
>
> Thanks,
>
> Martin
>