Age | Commit message (Collapse) | Author |
|
The idea is that when we reboot, we zero out
memory written by processes that have the private
flag set (such as factotum and keyfs), and also
clear the secrmem pool, which contains TLS keys
and the state of the random number generator.
This is so the newly booted kernel or firmware
will not find these secret keys in memory.
|
|
procs come from the dynamic pools, so we don't need
to remove the memory used by possible procs from the
total available.
|
|
we might as well handle the per process cycle
counter in the portable part instead of duplicating the code
in every arch and have inconsistent implementations.
we now have a portable kenter() and kexit() function,
that is ment to be used in trap/syscall from user,
which updates the counters.
some kernels missed initializing Mach.cyclefreq.
|
|
replace machine specific userinit() by a portable
implemntation that uses kproc() to create the first
process. the initcode text is mapped using kmap(),
so there is no need for machine specific tmpmap()
functions.
initcode stack preparation should be done in init0()
where the stack is mapped and can be accessed directly.
replacing the machine specific userinit() allows some
big simplifications as sysrfork() and kproc() are now
the only callers of newproc() and we can avoid initializing
fields that we know are being initialized by these
callers.
rename autogenerated init.h and reboot.h headers.
the initcode[] and rebootcode[] blobs are now in *.i
files and hex generation was moved to portmkfile. the
machine specific mkfile only needs to specify how to
build rebootcode.out and initcode.out.
|
|
for device drivers
|
|
|
|
the only architecture dependence of devether was enabling interrupts,
which is now done at the end of the driver's reset() function now.
the wifi stack and dummy ethersink also go to port/.
do the IRQ2->IRQ9 hack for pc kernels in intrenabale(), so not
every caller of intrenable() has to be aware of it.
|
|
specific fpu handling
introducing the PFPU structue which allows the machine specific
code some flexibility on how to handle the FPU process state.
for example, in the pc and pc64 kernel, the FPsave structure is
arround 512 bytes. with avx512, it could grow up to 2K. instead
of embedding that into the Proc strucutre, it is more effective
to allocate it on first use of the fpu, as most processes do not
use simd or floating point in the first place. also, the FPsave
structure has special 16 byte alignment constraint, which further
favours dynamic allocation.
this gets rid of the memmoves in pc/pc64 kernels for the aligment.
there is also devproc, which is now checking if the fpsave area
is actually valid before reading it, avoiding debuggers to see
garbage data.
the Notsave structure is gone now, as it was not used on any
machine.
|
|
|
|
mapped)
|
|
|
|
cpus on pc64
|
|
introduce cpushutdown() function that does the common
operation of initiating shutdown, returning once all
cpu's got the message and are about to shutdown. this
avoids duplicated code which isnt really machine specific.
automatic reboot on panic only when *debug= is not set
and the machine is a cpu server or has no display,
otherwise just hang.
|
|
|
|
|
|
sometimes, machine would crash on boot because
of data cache inconsistency. invalidating the
cache before booting cpu1 fixes it.
|
|
|
|
work with it
map the whole ocm memory on boot so we can translate physical to
virtual addresses and back for uncached memory using KADDR() and
PADDR().
replace ualloc() with ucalloc() returning virtual address. physical
address can be acquired with PADDR() now.
as ocm is now always mapped, use KADDR() instead of tmpmap() for
mp bootstrap.
|
|
there are no kernels currently that do page coloring,
so the only use of cachectl[] is flushing the icache
(on arm and ppc).
on pc64, cachectl consumes 32 bytes in each page resulting
in over 200 megabytes of overhead for 32gb of ram with 4K
pages.
this change removes cachectl[] and adds txtflush ulong
that is set to ~0 by pio() to instruct putmmu() to flush
the icache.
|
|
|
|
implement multiprocessor support.
|
|
|
|
|
|
|