| Age | Commit message (Collapse) | Author |
|---|
|
cleanup, responsible for various reaper panics pointed out on bugs@ this
morning.
ok deraadt@
|
|
commit.
ok deraadt@
|
|
ok mpi@ deraadt@
|
|
this is like src/sys/arch/alpha/alpha/mutex.c r1.14.
this changes sgi mutexes so they record which cpu owns the lock
rather than just if the lock is held or not. the diagnostics compare
the owner to the current cpus curcpu() address so they can actually
tell if the current cpu holds the lock instead of whether any cpu
holds the lock.
instead of using custom asm to implement a cas this uses atomic_cas_ptr.
while im here i also shuffled the code. on MULTIPROCESSOR systems
instead of duplicating code between mtx_enter and mtx_enter_try,
mtx_enter simply loops on mtx_enter_try until it succeeds.
this also provides an alternative implementation of mutexes on
!MULTIPROCESSOR systems that avoids interlocking opcodes. mutexes
wont contend on UP boxes, theyre basically wrappers around spls.
we can just do the splraise, stash the owner as a guard value for
DIAGNOSTIC and return. similarly, mtx_enter_try on UP will never
fail, so we can just call mtx_enter and return 1.
tested by and ok miod@
|
|
ok kettenis@
|
|
processors.
|
|
This is currently only enabled on hypervisors because on real hardware, it
requires interrupt remapping which we don't support yet. But on virtualization
it reduces the number of vmexits required per IPI from 4 to 1, causing a
significant speed-up for MP guests.
ok kettenis@
|
|
ok armani, guenther, sthen
|
|
Noticed by mlarkin@
|
|
This commit ports the infrastructure to do binary code patching from amd64.
The existing code patching for SMAP is converted to the new infrastruture.
ok kettenis@
"should go in" deraadt@
|
|
interpretation of it isn't quite right. So instead of allocating memory
and slicing it based on the parameters returned by CPUID, simply use a member
in struct cpu_info like basically all other OSes out there do. Our struct
cpu_info is large enough to never cause any overlap. This makes the
mwait-based idle loop actually work. We still execute the CPUID instruction
to make sure monitor/mwait is properly supported by the hardware we're
running on.
ok sthen@, deraadt@, guenther@
|
|
EIP/RIP adjustment for ERESTART
ok mlarkin@
|
|
MUTEX_ASSERT_UNLOCKED, but it turns out alpha mutexes arent very
friendly to diagnostics on smp systems.
alpha mutexes contained an mtx_lock member. when 0 the mutex was
unlocked, and when 1 it was locked. the MUTEX_ASSERT_UNLOCKED checked
if mtx_lock was 1 to see if the current cpu owned the mutex, but
in an mp system another cpu may have set mtx_lock to 1, which causes
the assert to fire.
this changes alpha mutexes so they record which cpu owns the lock
rather than just if the lock is held or not. the diagnostics compare
the owner to the current cpus curcpu() address so they can actually
tell if the current cpu holds the lock instead of whether any cpu
holds the lock.
instead of using custom asm to implement a cas this uses atomic_cas_ptr,
which on alpha uses gcc cas code. miod says he has far more confidence
in the gcc cas than the code that was there before.
while im here i also shuffled the code. on MULTIPROCESSOR systems
instead of duplicating code between mtx_enter and mtx_enter_try,
mtx_enter simply loops on mtx_enter_try until it succeeds.
this also provides an alternative implementation of mutexes on
!MULTIPROCESSOR systems that avoids interlocking opcodes. mutexes
wont contend on UP boxes, theyre basically wrappers around spls.
we can just do the splraise, stash the owner as a guard value for
DIAGNOSTIC and return. similarly, mtx_enter_try on UP will never
fail, so we can just call mtx_enter and return 1.
ok miod@
|
|
unification...
|
|
|
|
|
|
unneeded disable/enable_intr sequence around the PTE unmap operation.
|
|
there's no need to do it in m_devget(9).
Stop passing an ``ifp'' will help for upcoming interface pointer -> index
conversion.
While here remove unused ``ifp'' argument from m_clget(9) and kill two
birds^W layer violations in one commit.
ok henning@
|
|
reduce differences between PAE and no-PAE i386 pmaps.
|
|
certain pmap structures are allocated.
No functional change.
|
|
to deraadt, then myself) brings the PAE pmap on i386 (not touched in any
significant way for years) closer to the current non-PAE pmap and allows
us to take a big next step toward better i386 W^X in the kernel (similar to
what we did a few months ago on amd64). Unlike the original PAE pmap, this
diff will not be supporting > 4GB physical memory on i386 - this effort is
specifically geared toward providing W^X (via NX) only.
There still seems to be a bug removing certain pmap entries when PAE is
enabled, so I'm leaving PAE mode disabled for the moment until we can
figure out what is going on, but with this diff in the tree hopefully
others can help.
The pmap functions now operate through function pointers, due to the need
to support both non-PAE and PAE forms. My unscientific testing showed
less than 0.3% (a third of a percent) slowdown with this approach during
a base build.
Discussed for months with guenther, kettenis, and deraadt.
ok kettenis@, deraadt@
|
|
for non-DIAGNOSTIC kernels.
ok deraadt@
|
|
pv lists with a mutex. Some minor code adjustments to prevent holding locks
too long. This should make pmap_enter(9), pmap_remove(9) and
pmap_page_protect(9) safe to use without holding the kernel lock.
|
|
|
|
when we call pmap_release(). Turn debug code into printf and remove the code
that tried to mop up. Override Debugger() such that it inserts a trap
instruction directly into the code such that we get useful backtraces.
This way I don't need to worry about pmap_release() removing pv entries when
making this pmap mpsafe.
|
|
when no cable is plugged in but the interface is brough up.
inputs and ok kettenis@
|
|
ok dlg@
|
|
In fact we even use the firmware interface for "bsd -c" and "bsd -d".
So do the necessary firmware calls before calling initppc() to be able
to use printf() really early in the boot sequence.
|
|
Tested with simh using a floppy image built by miod@
|
|
might be overwritten by pseudo-drivers.
ok dlg@, henning@
|
|
mutex when necessary.
ok kettenis@, ratchov@
|
|
ok kettenis@, miod@
|
|
Tested by jsg@ with Qemu
|
|
"sure" deraadt@
|
|
|
|
|
|
unused headers.
|
|
|
|
in use) now so that libkvm can be fixed before the rest of the bulk of PAE
support is committed.
requested by and ok deraadt@
|
|
|
|
processors that support it.
Due to the way trap code is patched it is currently not possible to
enabled/disable BAT at runtime.
ok miod@, kettenis@
|
|
ok miod@, kettenis@ as part of a larger diff
|
|
generation of G5s. Without this my PowerMac11,2 hang when smu(4)
attaches.
|
|
the interrupt frame was at the same address as the frame that was interrupted.
Correct the calculated frame pointer for the interrupt frame to have the same
offset to the struct trapframe on the stack as does syscall and trap.
ok kettenis@ mlarkin@
|
|
happier
ok dlg@ jsing@ kettenis@ mlarkin@
|
|
|
|
behind a sun4m iommu.
Move the existing dvma routines from vm_machdep.c to this new dvma.c; this
allows for a few declarations to be removed from public headers.
Extend the device attachment arguments (struct confargs) to pass a
bus_dma_tag_t. mainbus receives the dvma bus_dma_tag_t, and devices pass the
tag unchanged to their children, except for iommu(4) which replaces it with
its own.
Change the few sun4m-only drivers to pick the bus_dma_tag_t from confargs
rather than assume iommu; this allows qlw(4) to attach and work on sun4c.
ok kettenis@
|
|
not correspond to the PCI function.
Hopefully the first device that I find hitting this case is the second
bge(4) interface of my PowerMac11,2.
|
|
and enable the mpic on G5 machines and finally introduce some helpers
needed for suspend/resume. Is this called a rewrite?
In my forest since s2k11, committing now that I need this for supporting
Quad G5 machines.
|
|
|
