869dbab7ba
After removing wmb(), vm_set_rendezvous_func() became super trivial, so there was no point in keeping it. The wmb (sfence on amd64, lock nop on i386) was not needed. This can be explained from several points of view. First, wmb() is used for store-store ordering (although, the primitive is undocumented). There was no obvious subsequent store that needed the barrier. Second, x86 has a memory model with strong ordering including total store order. An explicit store barrier may be needed only when working with special memory (device, special caching mode) or using special instructions (non-temporal stores). That was not the case for this code. Third, I believe that there is a misconception that sfence "flushes" the store buffer in a sense that it speeds up the propagation of stores from the store buffer to the global visibility. I think that such propagation always happens as fast as possible. sfence only makes subsequent stores wait for that propagation to complete. So, sfence is only useful for ordering of stores and only in the situations described above. Reviewed by: jhb MFC after: 23 days Differential Revision: https://reviews.freebsd.org/D21978 |
||
|---|---|---|
| .. | ||
| amd | ||
| intel | ||
| io | ||
| vmm_dev.c | ||
| vmm_host.c | ||
| vmm_host.h | ||
| vmm_instruction_emul.c | ||
| vmm_ioport.c | ||
| vmm_ioport.h | ||
| vmm_ktr.h | ||
| vmm_lapic.c | ||
| vmm_lapic.h | ||
| vmm_mem.c | ||
| vmm_mem.h | ||
| vmm_stat.c | ||
| vmm_stat.h | ||
| vmm_util.c | ||
| vmm_util.h | ||
| vmm.c | ||
| x86.c | ||
| x86.h | ||