kernel - Fix serious issue w/ smp_invltlb(), plus other issues.

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.