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

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