exec: move listener from AddressSpaceDispatch to AddressSpace

This will help having two copies of AddressSpaceDispatch during the
recreation of the radix tree (one being built, and one that is complete
and will be protected by RCU).  We do not want to have to unregister and
re-register the listener.

Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
exec: separate current radix tree from the one being built

This same treatment previously done to phys_node_map and phys_sections
is now applied to the dispatch field of AddressSpace.  Topology updates
use as->next_dispatch while accesses use as->dispatch.

Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
exec: put memory map in AddressSpaceDispatch

After this patch, AddressSpaceDispatch holds a constistent tuple of
(phys_map, nodes, sections).  This will be important when updates
of the topology will run concurrently with reads.

cur_map is not used anymore except for freeing it at the end of the
topology update.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
exec: remove cur_map

cur_map is not used anymore; instead, each AddressSpaceDispatch
has its own nodes/sections pair.  The priorities of the
MemoryListeners, and in the future RCU, guarantee that the
nodes/sections are not freed while they are still in use.

(In fact, next_map itself is not needed except to free the data on the
next update).

To avoid incorrect use, replace cur_map with a temporary copy that
is only valid while the topology is being updated.  If you use it,
the name prev_map makes it clear that you're doing something weird.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
exec: change some APIs to take AddressSpaceDispatch

Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>