Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging

* KVM page size fix for PPC
* Support for Linux 4.4's new Hyper-V features
* Eliminate g_slice from areas I maintain
* checkpatch fix
* Peter's cpu_reload_memory_map() cleanups
* More changes to MAINTAINERS
* Require Python 2.6
* chardev creation fixes
* PCI requester id for ARM KVM
* cleanups and doc fixes
* Allow customization of the Hyper-V vendor id

# gpg: Signature made Mon 19 Oct 2015 09:13:10 BST using RSA key ID 78C7AE83
# gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>"
# gpg:                 aka "Paolo Bonzini <pbonzini@redhat.com>"

* remotes/bonzini/tags/for-upstream: (49 commits)
  kvm: Allow the Hyper-V vendor ID to be specified
  kvm: Move x86-specific functions into target-i386/kvm.c
  kvm: Pass PCI device pointer to MSI routing functions
  hw/pci: Introduce pci_requester_id()
  kvm: Make KVM_CAP_SIGNAL_MSI globally available
  doc/rcu: fix g_free_rcu() usage example
  qemu-char: cleanup after completed conversion to cd->create
  qemu-char: convert ringbuf backend to data-driven creation
  qemu-char: convert vc backend to data-driven creation
  qemu-char: convert spice backend to data-driven creation
  qemu-char: convert console backend to data-driven creation
  qemu-char: convert stdio backend to data-driven creation
  qemu-char: convert testdev backend to data-driven creation
  qemu-char: convert braille backend to data-driven creation
  qemu-char: convert msmouse backend to data-driven creation
  qemu-char: convert mux backend to data-driven creation
  qemu-char: convert null backend to data-driven creation
  qemu-char: convert pty backend to data-driven creation
  qemu-char: convert UDP backend to data-driven creation
  qemu-char: convert socket backend to data-driven creation
  ...

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

1 files changed, 17 insertions, 16 deletions

diff --git a/cpu-exec-common.c b/cpu-exec-common.c
index 16d305b911..43edf36777 100644
--- a/cpu-exec-common.c
+++ b/cpu-exec-common.c
@@ -37,31 +37,32 @@ void cpu_resume_from_signal(CPUState *cpu, void *puc)
     siglongjmp(cpu->jmp_env, 1);
 }
 
-void cpu_reload_memory_map(CPUState *cpu)
+void cpu_reloading_memory_map(void)
 {
-    AddressSpaceDispatch *d;
-
     if (qemu_in_vcpu_thread()) {
-        /* Do not let the guest prolong the critical section as much as it
-         * as it desires.
+        /* The guest can in theory prolong the RCU critical section as long
+         * as it feels like. The major problem with this is that because it
+         * can do multiple reconfigurations of the memory map within the
+         * critical section, we could potentially accumulate an unbounded
+         * collection of memory data structures awaiting reclamation.
+         *
+         * Because the only thing we're currently protecting with RCU is the
+         * memory data structures, it's sufficient to break the critical section
+         * in this callback, which we know will get called every time the
+         * memory map is rearranged.
          *
-         * Currently, this is prevented by the I/O thread's periodinc kicking
-         * of the VCPU thread (iothread_requesting_mutex, qemu_cpu_kick_thread)
-         * but this will go away once TCG's execution moves out of the global
-         * mutex.
+         * (If we add anything else in the system that uses RCU to protect
+         * its data structures, we will need to implement some other mechanism
+         * to force TCG CPUs to exit the critical section, at which point this
+         * part of this callback might become unnecessary.)
          *
          * This pair matches cpu_exec's rcu_read_lock()/rcu_read_unlock(), which
-         * only protects cpu->as->dispatch.  Since we reload it below, we can
-         * split the critical section.
+         * only protects cpu->as->dispatch. Since we know our caller is about
+         * to reload it, it's safe to split the critical section.
          */
         rcu_read_unlock();
         rcu_read_lock();
     }
-
-    /* The CPU and TLB are protected by the iothread lock.  */
-    d = atomic_rcu_read(&cpu->as->dispatch);
-    cpu->memory_dispatch = d;
-    tlb_flush(cpu, 1);
 }
 #endif