Date: Tue, 7 May 2019 02:05:27 -0700 From: Mark Millard <marklmi@yahoo.com> To: Justin Hibbits <chmeeedalf@gmail.com>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: PowerMac G5 live slb entries before moea64_mid_bootstrap for bsp vs. later: are duplications of ESID's avoided? Message-ID: <3DC0E9FF-9A75-4AD4-837E-DEDCECE7DDF0@yahoo.com>
next in thread | raw e-mail | index | archive | help
moea64_mid_bootstrap has:
for (i =3D 0; i < 64; i++) {
pcpup->pc_aim.slb[i].slbv =3D 0;
pcpup->pc_aim.slb[i].slbe =3D 0;
}
which does not try to use slbmfee and slbmfev
to copy the live information from prior context,
such as Apple's openfirmware. (There seems to
be no use of slbfev at all, though there is
use of slbmfee.) One means of dealing with what
this note is about might be to fill in the
live entries here. (But the hard coded 64 might
not be correct for what range have potential
live values to get.)
Is there a presumption that openfirmware and
the loader and such were all strictly:
MSR.IR=3D0 and MSR.DR=3D0? Is that really true of
Apple's openfirmware?
(Even usefdt mode would have had openfirmware
in use before disabling it. There likely would
still be previously established live-slb
entries around for MSR.IR=3D1 or MSR.DR=3D1.)
It also appears the only comparisons for checking
for already-existing esid's are from the
pcpup->pc_aim.slb[?].slbe content, no check of live
(via slbfee).
That includes in handle_kernel_slb_spill itself,
effectively not checking for a duplication of
a live esid with V=3D1.
(The documentation explicitly reports that
duplications mean undefined behavior as I
remember.)
This would appear to mean that starting to actually
assign the first slb entries needs to be after a
slbia (in a MSR.IR=3D0 context until things are
re-established) so that the addition(s) do not
potentially duplicate other ESID's that are valid
in the live context. But that is not done.
So it appears to me that in moea64_late_bootstrap
and its:
mtmsr(mfmsr() | PSL_DR | PSL_IR);
pmap_bootstrapped++;
. . .
virtual_avail =3D VM_MIN_KERNEL_ADDRESS;
virtual_end =3D VM_MAX_SAFE_KERNEL_ADDRESS;
. . .
i =3D 0;
for (va =3D virtual_avail; va < virtual_end && i<n_slbs-1; va +=3D=
SEGMENT_LENGTH, i++)
moea64_bootstrap_slb_prefault(va, 0);
there is no check for avoiding duplicates. (Not that
I'm claiming duplications are likely. But there is
more to this than duplications . . .)
Also, the code ends up causing handle_kernel_slb_spill
use as it replaces the slb entry(s) for the esid's
involved in the instruction fetches (for example).
This means that the loop establishes fewer pre-faulted
entries than it suggests.
(I've actually observed handle_kernel_slb_spill use in
over the loop by having handle_kernel_slb_spill count
its activity and sampling before vs. after.)
Overall, it does not look like the kernel is fully
dealing with the transition from prior activity's
live slb entries to just its own.
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DC0E9FF-9A75-4AD4-837E-DEDCECE7DDF0>