1. 13 1月, 2016 1 次提交
  2. 17 12月, 2015 1 次提交
    • E
      qapi: Don't let implicit enum MAX member collide · 7fb1cf16
      Eric Blake 提交于
      Now that we guarantee the user doesn't have any enum values
      beginning with a single underscore, we can use that for our
      own purposes.  Renaming ENUM_MAX to ENUM__MAX makes it obvious
      that the sentinel is generated.
      
      This patch was mostly generated by applying a temporary patch:
      
      |diff --git a/scripts/qapi.py b/scripts/qapi.py
      |index e6d014b..b862ec9 100644
      |--- a/scripts/qapi.py
      |+++ b/scripts/qapi.py
      |@@ -1570,6 +1570,7 @@ const char *const %(c_name)s_lookup[] = {
      |     max_index = c_enum_const(name, 'MAX', prefix)
      |     ret += mcgen('''
      |     [%(max_index)s] = NULL,
      |+// %(max_index)s
      | };
      | ''',
      |                max_index=max_index)
      
      then running:
      
      $ cat qapi-{types,event}.c tests/test-qapi-types.c |
          sed -n 's,^// \(.*\)MAX,s|\1MAX|\1_MAX|g,p' > list
      $ git grep -l _MAX | xargs sed -i -f list
      
      The only things not generated are the changes in scripts/qapi.py.
      
      Rejecting enum members named 'MAX' is now useless, and will be dropped
      in the next patch.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Message-Id: <1447836791-369-23-git-send-email-eblake@redhat.com>
      Reviewed-by: NJuan Quintela <quintela@redhat.com>
      [Rebased to current master, commit message tweaked]
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      7fb1cf16
  3. 03 12月, 2015 1 次提交
  4. 19 11月, 2015 2 次提交
  5. 13 11月, 2015 3 次提交
  6. 10 11月, 2015 21 次提交
  7. 04 11月, 2015 2 次提交
    • L
      migration: rename qemu_savevm_state_cancel · ea7415fa
      Liang Li 提交于
      The function qemu_savevm_state_cancel is called after the migration
      in migration_thread, it seems strange to 'cancel' it after completion,
      rename it to qemu_savevm_state_cleanup looks better.
      Signed-off-by: NLiang Li <liang.z.li@intel.com>
      Reviewed-by: Juan Quintela <quintela@redhat.com>al3
      Reviewed-by: Amit Shah <amit.shah@redhat.com>al3
      Signed-off-by: Juan Quintela <quintela@redhat.com>al3
      ea7415fa
    • L
      migration: defer migration_end & blk_mig_cleanup · 94f5a437
      Liang Li 提交于
      Because of the patch 3ea3b7fa9af067982f34b of kvm, which introduces a
      lazy collapsing of small sptes into large sptes mechanism, now
      migration_end() is a time consuming operation because it calls
      memroy_global_dirty_log_stop(), which will trigger the dropping of small
      sptes operation and takes about dozens of milliseconds, so call
      migration_end() before all the vmsate data has already been transferred
      to the destination will prolong VM downtime. This operation should be
      deferred after all the data has been transferred to the destination.
      
      blk_mig_cleanup() can be deferred too.
      
      For a VM with 8G RAM, this patch can reduce the VM downtime about 30 ms.
      Signed-off-by: NLiang Li <liang.z.li@intel.com>
      Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
      Reviewed-by: Juan Quintela <quintela@redhat.com>al3
      Reviewed-by: Amit Shah <amit.shah@redhat.com>al3
      Signed-off-by: Juan Quintela <quintela@redhat.com>al3
      94f5a437
  8. 15 10月, 2015 2 次提交
  9. 30 9月, 2015 4 次提交
  10. 29 9月, 2015 2 次提交
  11. 04 8月, 2015 1 次提交