Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 19 Oct 2019 07:10:15 +0000 (UTC)
From:      Andriy Gapon <avg@FreeBSD.org>
To:        src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   svn commit: r353747 - head/sys/amd64/vmm
Message-ID:  <201910190710.x9J7AFnV052852@repo.freebsd.org>

next in thread | raw e-mail | index | archive | help
Author: avg
Date: Sat Oct 19 07:10:15 2019
New Revision: 353747
URL: https://svnweb.freebsd.org/changeset/base/353747

Log:
  vmm: remove a wmb() call
  
  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

Modified:
  head/sys/amd64/vmm/vmm.c

Modified: head/sys/amd64/vmm/vmm.c
==============================================================================
--- head/sys/amd64/vmm/vmm.c	Sat Oct 19 02:47:32 2019	(r353746)
+++ head/sys/amd64/vmm/vmm.c	Sat Oct 19 07:10:15 2019	(r353747)
@@ -1235,22 +1235,6 @@ vcpu_require_state_locked(struct vm *vm, int vcpuid, e
 		panic("Error %d setting state to %d", error, newstate);
 }
 
-static void
-vm_set_rendezvous_func(struct vm *vm, vm_rendezvous_func_t func)
-{
-
-	KASSERT(mtx_owned(&vm->rendezvous_mtx), ("rendezvous_mtx not locked"));
-
-	/*
-	 * Update 'rendezvous_func' and execute a write memory barrier to
-	 * ensure that it is visible across all host cpus. This is not needed
-	 * for correctness but it does ensure that all the vcpus will notice
-	 * that the rendezvous is requested immediately.
-	 */
-	vm->rendezvous_func = func;
-	wmb();
-}
-
 #define	RENDEZVOUS_CTR0(vm, vcpuid, fmt)				\
 	do {								\
 		if (vcpuid >= 0)					\
@@ -1281,7 +1265,7 @@ vm_handle_rendezvous(struct vm *vm, int vcpuid)
 		if (CPU_CMP(&vm->rendezvous_req_cpus,
 		    &vm->rendezvous_done_cpus) == 0) {
 			VCPU_CTR0(vm, vcpuid, "Rendezvous completed");
-			vm_set_rendezvous_func(vm, NULL);
+			vm->rendezvous_func = NULL;
 			wakeup(&vm->rendezvous_func);
 			break;
 		}
@@ -2535,7 +2519,7 @@ restart:
 	vm->rendezvous_req_cpus = dest;
 	CPU_ZERO(&vm->rendezvous_done_cpus);
 	vm->rendezvous_arg = arg;
-	vm_set_rendezvous_func(vm, func);
+	vm->rendezvous_func = func;
 	mtx_unlock(&vm->rendezvous_mtx);
 
 	/*



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201910190710.x9J7AFnV052852>