code and then a single line adjusted to make it look identical to the
openbsd sparc64 version, who provided inspiration for this.
NOTE: not really tested yet with a real device, but, it can't really
be worse than panic() in a device mmap()...
When switching from SVC32->UND32 to read/write R13_und we don't need to clear
the mode bits as:
PSR_SVC32_MODE | PSR_UND32_MODE = PSR_UND32_MODE
While reading the code I also noted that interrupts are enabled for most of
the function as pmap_switch returns with interrupts in the state they are on
entry. This appears to be different to what the code after pmap_switch
expects, in that the behaviour suggests they should be disabled.
Because of this I've made the writing of R13_und explicitly disable.
interupts as part of the mode switch.
This also means that the IRQenableALL call is now redundant as the
interrupts are already enabled.
XXX: it's not clear if arm_fpe_core_changecontext should be called with
interrupts disabled.
Remove unused items: IRQdisableALL, IRQenableALL & Lcpufuncs.
Tested on cats. lmbench shows no performance change.
other funcs a switchframe needs to be a multiple of 8 bytes. Stash sp as
well in the switchframe to bump it to 24bytes.
Setup the switchframe appropriately in cpu_lwp_fork.
Remove savectx - nothing uses it.
All of this make gdb's life much easier when dealing with crash dumps and
live kernels.
Reviewd by chris.
had the potential to cause problems prior to 4.99.48 because it called into
the VM system without kernel_lock held.
XXX1 pmap_update() should be waiting for shootdown jobs to complete. It's
not clear how to do that because the shootdowns happen at IPL_VM.
- KNF, ANSIfy, remove __P()
- use __func__ to print function names
- use __arraycount()
- include "ioconf.h" for struct cfdriver
- u_intNN_t -> uintNN_t
- wrap long lines
etc.
branch is still active and will see i386PAE support developement).
Sumary of changes:
- switch xeni386 to the x86/x86/pmap.c, and the xen/x86/x86_xpmap.c
pmap bootstrap.
- merge back most of xen/i386/ to i386/i386
- change the build to reduce diffs between i386 and amd64 in file locations
- remove include files that were identical to the i386/amd64 counterparts,
the build will find them via the xen-ma/machine link.
the call to pci_configure_bus(9) and it's supporting code is
copied verbatim from the prep port.
this allows us to completely remove the really gross pegasos
specific pegasospci_indirect_attach_hook() that set various
pci command regs, since all those devices (mostly work now,
see below) and additionally PCI plugin cards work now too.
it also makes the pegasos onboard vr(4) ethernet work with
disk boot (it previously only worked with netboot.)
in the generic macppc ofw pci conf hook and for pegasos,
don't configure the viaide(4) device, and don't configure
memory space on the fwohci(4) device.
with this, and my other recent ofppc/ppc changes the pegasos
port is mostly functional. the marvell gige is not working,
and my 512mb appears as only about 256mb, but otherwise
this port is almost done!
on my pegasos:
- don't chop off the 2nd part of the OFW address, it makes it
match pcib (ISA bridge - dev 12 fn 0) instead of viaide (dev 12
fn 1).
- now that it's available, provide an "addr2" that has the
second address present.
- for pci devices match against device and function, not just
function.
- remove the special case and actually broken check in the
"pciide" section, and use the now generic "addr2" and check
against the drive and channel number if provided.
- support "viaide" and "slide" in here, as well as "pciide".
(is there a good way to say "any ide adapter"?)
- add the useful space and control registers to struct reg
- update process_{read,write}_regs accordingly
- use MID_HPPA in core dumps.
- dump the fp regs into cores.
- add single stepping support from OpenBSD.
Davis for Coyote Point. Though this does not modify the kernel core
format (it uses multiple memory segments, a feature previously unused on
i386) it is nonetheless disabled by default. Sysctl machdep.sparse_dump=1
to turn this feature on.
Dumps of even busy, large-memory systems are generally a few tens of
megabytes.
drochner