1. 15 8月, 2019 6 次提交
  2. 15 7月, 2019 1 次提交
  3. 15 5月, 2019 5 次提交
  4. 02 4月, 2019 1 次提交
    • M
      Revert "migration: move only_migratable to MigrationState" · 811f8652
      Markus Armbruster 提交于
      This reverts commit 3df663e5.
      This reverts commit b605c47b.
      
      Command line option --only-migratable is for disallowing any
      configuration that can block migration.
      
      Initially, --only-migratable set global variable @only_migratable.
      
      Commit 3df663e5 "migration: move only_migratable to MigrationState"
      replaced it by MigrationState member @only_migratable.  That was a
      mistake.
      
      First, it doesn't make sense on the design level.  MigrationState
      captures the state of an individual migration, but --only-migratable
      isn't a property of an individual migration, it's a restriction on
      QEMU configuration.  With fault tolerance, we could have several
      migrations at once.  --only-migratable would certainly protect all of
      them.  Storing it in MigrationState feels inappropriate.
      
      Second, it contributes to a dependency cycle that manifests itself as
      a bug now.
      
      Putting @only_migratable into MigrationState means its available only
      after migration_object_init().
      
      We can't set it before migration_object_init(), so we delay setting it
      with a global property (this is fixup commit b605c47b "migration:
      fix handling for --only-migratable").
      
      We can't get it before migration_object_init(), so anything that uses
      it can only run afterwards.
      
      Since migrate_add_blocker() needs to obey --only-migratable, any code
      adding migration blockers can run only afterwards.  This contributes
      to the following dependency cycle:
      
      * configure_blockdev() must run before machine_set_property()
        so machine properties can refer to block backends
      
      * machine_set_property() before configure_accelerator()
        so machine properties like kvm-irqchip get applied
      
      * configure_accelerator() before migration_object_init()
        so that Xen's accelerator compat properties get applied.
      
      * migration_object_init() before configure_blockdev()
        so configure_blockdev() can add migration blockers
      
      The cycle was closed when recent commit cda4aa9a "Create block
      backends before setting machine properties" added the first
      dependency, and satisfied it by violating the last one.  Broke block
      backends that add migration blockers.
      
      Moving @only_migratable into MigrationState was a mistake.  Revert it.
      
      This doesn't quite break the "migration_object_init() before
      configure_blockdev() dependency, since migrate_add_blocker() still has
      another dependency on migration_object_init().  To be addressed the
      next commit.
      
      Note that the reverted commit made -only-migratable sugar for -global
      migration.only-migratable=on below the hood.  Documentation has only
      ever mentioned -only-migratable.  This commit removes the arcane &
      undocumented alternative to -only-migratable again.  Nobody should be
      using it.
      
      Conflicts:
      	include/migration/misc.h
      	migration/migration.c
      	migration/migration.h
      	vl.c
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Message-Id: <20190401090827.20793-3-armbru@redhat.com>
      Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
      811f8652
  5. 06 3月, 2019 2 次提交
  6. 05 3月, 2019 1 次提交
  7. 23 1月, 2019 2 次提交
  8. 27 11月, 2018 2 次提交
  9. 31 10月, 2018 1 次提交
  10. 19 10月, 2018 4 次提交
  11. 27 9月, 2018 2 次提交
  12. 26 9月, 2018 1 次提交
    • J
      Add a hint message to loadvm and exits on failure · 827beacb
      Jose Ricardo Ziviani 提交于
      This patch adds a small hint for the failure case of the load snapshot
      process. It may be useful for users to remember that the VM
      configuration has changed between the save and load processes.
      
      (qemu) loadvm vm-20180903083641
      Unknown savevm section or instance 'cpu_common' 4.
      Make sure that your current VM setup matches your saved VM setup, including any hotplugged devices
      Error -22 while loading VM state
      (qemu) device_add host-spapr-cpu-core,core-id=4
      (qemu) loadvm vm-20180903083641
      (qemu) c
      (qemu) info status
      VM status: running
      
      It also exits Qemu if the snapshot cannot be loaded before reaching the
      main loop (-loadvm in the command line).
      
      $ qemu-system-ppc64 ... -loadvm vm-20180903083641
      qemu-system-ppc64: Unknown savevm section or instance 'cpu_common' 4.
      Make sure that your current VM setup matches your saved VM setup, including any hotplugged devices
      qemu-system-ppc64: Error -22 while loading VM state
      $
      Signed-off-by: NJose Ricardo Ziviani <joserz@linux.ibm.com>
      Message-Id: <20180903162613.15877-1-joserz@linux.ibm.com>
      Reviewed-by: NJuan Quintela <quintela@redhat.com>
      Signed-off-by: NJuan Quintela <quintela@redhat.com>
      Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
      827beacb
  13. 22 8月, 2018 1 次提交
  14. 10 7月, 2018 3 次提交
  15. 04 6月, 2018 1 次提交
    • C
      migration: discard non-migratable RAMBlocks · b895de50
      Cédric Le Goater 提交于
      On the POWER9 processor, the XIVE interrupt controller can control
      interrupt sources using MMIO to trigger events, to EOI or to turn off
      the sources. Priority management and interrupt acknowledgment is also
      controlled by MMIO in the presenter sub-engine.
      
      These MMIO regions are exposed to guests in QEMU with a set of 'ram
      device' memory mappings, similarly to VFIO, and the VMAs are populated
      dynamically with the appropriate pages using a fault handler.
      
      But, these regions are an issue for migration. We need to discard the
      associated RAMBlocks from the RAM state on the source VM and let the
      destination VM rebuild the memory mappings on the new host in the
      post_load() operation just before resuming the system.
      
      To achieve this goal, the following introduces a new RAMBlock flag
      RAM_MIGRATABLE which is updated in the vmstate_register_ram() and
      vmstate_unregister_ram() routines. This flag is then used by the
      migration to identify RAMBlocks to discard on the source. Some checks
      are also performed on the destination to make sure nothing invalid was
      sent.
      
      This change impacts the boston, malta and jazz mips boards for which
      migration compatibility is broken.
      Signed-off-by: NCédric Le Goater <clg@kaod.org>
      Reviewed-by: NJuan Quintela <quintela@redhat.com>
      Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
      Signed-off-by: NJuan Quintela <quintela@redhat.com>
      b895de50
  16. 02 6月, 2018 1 次提交
  17. 16 5月, 2018 6 次提交