kernel - Fix serious issue w/ smp_invltlb(), plus other issues.
* smp_invltlb() was running asynchronously when it really needs to run
synchronously. Generally speaking the asynchronous ipi did in fact work
pretty well but it still presents a 1uS window of opportunity which
bypasses normal write ordering safeties.
Run smp_invltlb() synchronously.
* Fixing the above lea to the discovery of an ACPI issue. The ACPI
cpu idle halt code, at least on the gigabyte phenom x 6 I've been
testing with, can cause IPIs to be lost. Not just delayed, straight
out lost. Gone. Poof. It doesn't matter whether the IPI is a
broadcast IPI or a directed IPI, it can still get lost.
This was particularly noticeable when I fixed smp_invltlb() and my
test box started locking up due to a random cpu sometimes not receiving
the Xinvltlb IPI, and it is quite possible that this issue was also
responsible for the random seg-faults we would sometimes get on 64-bit
boxes.
For now the acpi halt code has been disabled. It can be enabled with
sysctl machdep.cpu_idle_hlt=2 if you want to risk it.
* Use doreti_syscall_ret and doreti_iret in several cases that were
previously popping the interrupt frame and iret'ing manually. This
is operationally equivalent.
* Add a missing "sti" in the idle loop. Usually the cpu_idle_hook()
deals with this but there are some alternative paths which might not,
potentially causing interrupts to be delayed unnecessarily.
At worst the idle thread has an extra sti in it.
* Add v_smpinvltlb to struct vmmeter, plus some reserved slots for
future expansion.
* Adjust vmstat -s to report smpinvltlb's.
13 files changed: