kern: Eliminate most __HAVE_ATOMIC_AS_MEMBAR conditionals.

I'm leaving in the conditional around the legacy membar_enters
(store-before-load, store-before-store) in kern_mutex.c and in
kern_lock.c b

kern: Eliminate most __HAVE_ATOMIC_AS_MEMBAR conditionals.

I'm leaving in the conditional around the legacy membar_enters
(store-before-load, store-before-store) in kern_mutex.c and in
kern_lock.c because they may still matter: store-before-load barriers
tend to be the most expensive kind, so eliding them is probably
worthwhile on x86. (It also may not matter; I just don't care to do
measurements right now, and it's a single valid and potentially
justifiable use case in the whole tree.)

However, membar_release/acquire can be mere instruction barriers on
all TSO platforms including x86, so there's no need to go out of our
way with a bad API to conditionalize them. If the procedure call
overhead is measurable we just could change them to be macros on x86
that expand into __insn_barrier.

Discussed on tech-kern:
https://mail-index.netbsd.org/tech-kern/2023/02/23/msg028729.html

show more ...

ipi(9): Convert membar_exit/enter to membar_release/acquire.

No store-before-load ordering needed here, just need to ensure that
in

A, ipi_send, ipi receive, B,

memory operations in A happen-befo

ipi(9): Convert membar_exit/enter to membar_release/acquire.

No store-before-load ordering needed here, just need to ensure that
in

A, ipi_send, ipi receive, B,

memory operations in A happen-before memory operations in B.

show more ...

ipi: Membar audit.

ipi: Split up initialization into two parts.

First part runs early so ipi_register can be used in module
initialization, e.g. via pktqueue_create; second part runs after CPUs
have been detected.

Add and use __FPTRCAST, requested by uwe@

Add void * function pointer casts. There are different ways to "fix" those
warnings:
1. this one: add a void * cast (which I think is the least intrusive)
2. add pragmas to elide the warning

Add void * function pointer casts. There are different ways to "fix" those
warnings:
1. this one: add a void * cast (which I think is the least intrusive)
2. add pragmas to elide the warning
3. add intermediate inline conversion functions
4. change the called function prototypes, adding unused arguments and
converting some of the pointer arguments to void *.
5. make the functions varyadic (which defeats the purpose of checking)
6. pass command line flags to elide the warning
I did try 3 and 4 and I was not pleased with the result (sys_ptrace_common.c)
(3) added too much code and defines, and (4) made the regular use clumsy.

show more ...

requires memory barrier before IPI ack.
Problem was seen on the aarch64 cpus.

Fixes PR/54009

Add an ipi_trigger_broadcast() call, like ipi_trigger_multi() but to the
full set of attached CPUs, with an optional "skip_self" argument to skip
the calling CPU. Add a "skip_self" to the ipi_broadc

Add an ipi_trigger_broadcast() call, like ipi_trigger_multi() but to the
full set of attached CPUs, with an optional "skip_self" argument to skip
the calling CPU. Add a "skip_self" to the ipi_broadcast() call for
symmetry.

(Kernel version bump coming in a subsequent commit.)

show more ...

Implement ipi_trigger_multi(9); requested by cherry@.

MI IPI interface:
- Implement support for the asynchronous IPI calls.
- Rework synchronous IPI code to reuse the asynchronous mechanism.
- Add ipi(9) manual page; needs wizd(8).

Note: MD code can no

MI IPI interface:
- Implement support for the asynchronous IPI calls.
- Rework synchronous IPI code to reuse the asynchronous mechanism.
- Add ipi(9) manual page; needs wizd(8).

Note: MD code can now provide a low level primitive for the ipi(9) and
reuse this interface instead of open-coding. Portmasters are encouraged
to convert. Ride 6.99.43!

show more ...

Implement MI IPI interface with cross-call support.