PowerMac G5's vs. PSL_ME manipulation in the msr: mtmsr ignores it, only rfid can set it? (How to avoid checkstop on the ap's?)

[Mark Millard]

Quoting: PPC_Vers201_Book3_public.pdf

QUOTE
The only instruction that can alter MSR.ME is the rfid instruction.
END QUOTE

(Doing so involves using mtsrr1 before the rfid instruction.)

Various places in FreeBSD are trying to control the PDL_ME bit via
mtmsr. In fact, most FreeBSD PSL_ME use for the context is
associated with mtmsr.

So far I only see:

enter_idle_powerx sets PSL_ME via mtsrr1 and rfid.

kbootentry clears srr1 completely via mtsrr1 before
doing ba EXC_RST.

Other mtsrr1 usage are just save/restore or
do updates not involving PSL_ME changes.


How I got into looking at PSL_ME use: How
it relates to the hang-up problem investigation
. . .

Note: CPU 1 never makes it to handle_kernel_slb_spill
when the it tries the td_pcb-> access in
cpudep_ap_bootstrap. CPU 1 appears to have ended up
checkstop'd, not getting other traps
either.

There are the following dependencies on
td_pcb-> access in powerpc/powerpc/trap.c :

handle_onfault:                 td->td_pcb->pcb_onfault
trap_pfault:                    Can use handle_onfault
trap for kernel EXC_MCHK:       Uses handle_onfault
trap for kernel EXC_DSI:        Uses trap_pfault
trap for kernel EXC_DSE:        td->td_pcb->pcb_cpu.aim.usr_vsid
fix_unaligned for ESR_SPE:      td->td_pcb->pcb_vec.vr[reg]
fix_unaligned for EXC_ALI_LFD:  td->td_pcb->pcb_fpu.fpr[reg].fp
fix_unaligned for EXC_ALI_STFD: td->td_pcb->pcb_fpu.fpr[reg].fp

As near as I can tell, for the PowerMac G5's,
PDL_ME is as openfirmware or the loader
set it for each CPU. But CPU 1 does happen to
have the PSL_ME bit enabled.

With td_pcb-> access in cpudep_ap_bootstrap failing
to get to handle_kernel_slb_spill at all when the
slb does not cover the segment, the rest of the
above are not likely to work under such conditions
ether. slbtrap's and handle_kernel_slb_spill would
be involved.

My evidence gathering, some notes:

I have handle_kernel_slb_spill recording CPU 1
activity but it never reports any activity except
before the pcpup->pc_curthread-> access attempt.
I also have recording in trap's kernel trap path
for CPU 1 and it also reports nothing.

(The reporting is to memory, with the bsp looking
at what was recorded and reporting based on such
via printf's when there is something to report.)


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)