Replace cpu_mb1() and cpu_mb2() with cpu_mfence(), cpu_lfence(), cpu_sfence(),

Replace cpu_mb1() and cpu_mb2() with cpu_mfence(), cpu_lfence(), cpu_sfence(),
and cpu_ccfence().  These provide memory and compiler fences to guarentee
read/write ordering of memory and to prevent the compiler itself from
generating reordered code in particular cases.

Most of the cases where care must be taken are tail-chasing FIFO cases,
especially in the IPI messaging code.

At the moment on SMP boxes we use a locked bus cycle on (%%esp) for the
lfence and mfence.  The only other choices are to use a cpuid instruction
or one of the {S,L,M}FENCE instructions.  cpuid is usually horrible, and
the *FENCE instructions do not exist on older cpus.

Linux seems to use the locked bus cycle or *FENCE instruction method.

Although I have no conclusive evidence, a number of crash dumps provided
by David Rhodus has led me to believe that speculative reads by modern cpus,
in particular in HTT situations with Intel cpus, can survive many more
instructions then previously believed.  The only safe solution is to use
an instruction sequence which guarentees proper operation.

I would prefer to avoid the use of a locked bus cycle but at least in the
IPIQ case (the most common case we have to worry about), only one locked
bus cycle is required and then the entire IPIQ can be processed without
further locked cycles.