Eliminate pvh_global_lock from the amd64 pmap.

The only current purpose of the pvh lock was explained there
On Wed, Jan 09, 2013 at 11:46:13PM -0600, Alan Cox wrote:

Let me lay out one example for you in detail. Suppose that we have
three processors and two of these processors are actively using the same
pmap. Now, one of the two processors sharing the pmap performs a
pmap_remove(). Suppose that one of the removed mappings is to a
physical page P. Moreover, suppose that the other processor sharing
that pmap has this mapping cached with write access in its TLB. Here's
where the trouble might begin. As you might expect, the processor
performing the pmap_remove() will acquire the fine-grained lock on the
PV list for page P before destroying the mapping to page P. Moreover,
this processor will ensure that the vm_page's dirty field is updated
before releasing that PV list lock. However, the TLB shootdown for this
mapping may not be initiated until after the PV list lock is released.
The processor performing the pmap_remove() is not problematic, because
the code being executed by that processor won't presume that the mapping
is destroyed until the TLB shootdown has completed and pmap_remove() has
returned. However, the other processor sharing the pmap could be
problematic. Specifically, suppose that the third processor is
executing the page daemon and concurrently trying to reclaim page P.
This processor performs a pmap_remove_all() on page P in preparation for
reclaiming the page. At this instant, the PV list for page P may
already be empty but our second processor still has a stale TLB entry
mapping page P. So, changes might still occur to the page after the
page daemon believes that all mappings have been destroyed. (If the PV
entry had still existed, then the pmap lock would have ensured that the
TLB shootdown completed before the pmap_remove_all() finished.) Note,
however, the page daemon will know that the page is dirty. It can't
possibly mistake a dirty page for a clean one. However, without the
current pvh global locking, I don't think anything is stopping the page
daemon from starting the laundering process before the TLB shootdown has
completed.

I believe that a similar example could be constructed with a clean page
P' and a stale read-only TLB entry. In this case, the page P' could be
"cached" in the cache/free queues and recycled before the stale TLB
entry is flushed.

TLBs for addresses with updated PTEs are always flushed before pmap
lock is unlocked. On the other hand, amd64 pmap code does not always
flushes TLBs before PV list locks are unlocked, if previously PTEs
were cleared and PV entries removed.

To handle the situations where a thread might notice empty PV list but
third thread still having access to the page due to TLB invalidation
not finished yet, introduce delayed invalidation. Comparing with the
pvh_global_lock, DI does not block entered thread when
pmap_remove_all() or pmap_remove_write() (callers of
pmap_delayed_invl_wait()) are executed in parallel. But _invl_wait()
callers are blocked until all previously noted DI blocks are leaved,
thus ensuring that neccessary TLB invalidations were performed before
returning from pmap_remove_all() or pmap_remove_write().

See comments for detailed description of the mechanism, and also for
the explanations why several pmap methods, most important
pmap_enter(), do not need DI protection.

Reviewed by: alc, jhb (turnstile KPI usage)
Tested by: pho (previous version)
Sponsored by: The FreeBSD Foundation
Differential revision: https://reviews.freebsd.org/D5747