1. 02 6月, 2017 1 次提交
  2. 19 5月, 2017 2 次提交
  3. 16 3月, 2017 1 次提交
  4. 28 2月, 2017 3 次提交
    • H
      migration/vmstate: fix array of ptr with nullptrs · 07d4e691
      Halil Pasic 提交于
      Make VMS_ARRAY_OF_POINTER cope with null pointers. Previously the
      reward for trying to migrate an array with some null pointers in it was
      an illegal memory access, that is a swift and painless death of the
      process.  Let's make vmstate cope with this scenario.
      
      The general approach is, when we encounter a null pointer (element),
      instead of following the pointer to save/load the data behind it, we
      save/load a placeholder. This way we can detect if we expected a null
      pointer at the load side but not null data was saved instead.
      Signed-off-by: NHalil Pasic <pasic@linux.vnet.ibm.com>
      Reviewed-by: NGuenther Hutzl <hutzl@linux.vnet.ibm.com>
      Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
      Message-Id: <20170222160119.52771-4-pasic@linux.vnet.ibm.com>
      Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
      07d4e691
    • H
      migration/vmstate: split up vmstate_base_addr · cbfda0e6
      Halil Pasic 提交于
      Currently vmstate_base_addr does several things: it pinpoints the field
      within the struct, possibly allocates memory and possibly does the first
      pointer dereference. Obviously allocation is needed only for load.
      
      Let us split up the functionality in vmstate_base_addr and move the
      address manipulations (that is everything but the allocation logic) to
      load and save so it becomes more obvious what is actually going on. Like
      this all the address calculations (and the handling of the flags
      controlling these) is in one place and the sequence is more obvious.
      
      The newly introduced function vmstate_handle_alloc also fixes the
      allocation for the unused VMS_VBUFFER|VMS_MULTIPLY|VMS_ALLOC scenario
      and is substantially simpler than the original vmstate_base_addr.
      
      In load and save some asserts are added so it's easier to debug
      situations where we would end up with a null pointer dereference.
      Signed-off-by: NHalil Pasic <pasic@linux.vnet.ibm.com>
      Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
      Message-Id: <20170222160119.52771-3-pasic@linux.vnet.ibm.com>
      Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
      cbfda0e6
    • H
      migration/vmstate: renames in (load|save)_state · e84641f7
      Halil Pasic 提交于
      The vmstate_(load|save)_state start out with an a void *opaque pointing
      to some struct, and manipulate one or more elements of one field within
      that struct.
      
      First the field within the struct is pinpointed as opaque + offset, then
      if this is a pointer the pointer is dereferenced to obtain a pointer to
      the first element of the vmstate field. Pointers to further elements if
      any are calculated as first_element + i * element_size (where i is the
      zero based index of the element in question).
      
      Currently base_addr and addr is used as a variable name for the pointer
      to the first element and the pointer to the current element being
      processed. This is suboptimal because base_addr is somewhat
      counter-intuitive (because obtained as base + offset) and both base_addr
      and addr not very descriptive (that we have a pointer should be clear
      from the fact that it is declared as a pointer).
      
      Let make things easier to understand by renaming base_addr to first_elem
      and addr to curr_elem. This has the additional benefit of harmonizing
      with other names within the scope (n_elems, vmstate_n_elems).
      Signed-off-by: NHalil Pasic <pasic@linux.vnet.ibm.com>
      Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
      Message-Id: <20170222160119.52771-2-pasic@linux.vnet.ibm.com>
      Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
      e84641f7
  5. 14 2月, 2017 2 次提交
    • D
      migration: Add VMSTATE_WITH_TMP · bcf45131
      Dr. David Alan Gilbert 提交于
      VMSTATE_WITH_TMP is for handling structures where some calculation
      or rearrangement of the data needs to be performed before the data
      hits the wire.
      For example,  where the value on the wire is an offset from a
      non-migrated base, but the data in the structure is the actual pointer.
      
      To use it, a temporary type is created and a vmsd used on that type.
      The first element of the type must be 'parent' a pointer back to the
      type of the main structure.  VMSTATE_WITH_TMP takes care of allocating
      and freeing the temporary before running the child vmsd.
      
      The post_load/pre_save on the child vmsd can copy things from the parent
      to the temporary using the parent pointer and do any other calculations
      needed; it can then use normal VMSD entries to do the actual data
      storage without having to fiddle around with qemu_get_*/qemu_put_*
      Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
      Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au>
      Reviewed-by: NJuan Quintela <quintela@redhat.com>
      Message-Id: <20170203160651.19917-3-dgilbert@redhat.com>
      Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
      bcf45131
    • H
      migration: consolidate VMStateField.start · 59046ec2
      Halil Pasic 提交于
      The member VMStateField.start is used for two things, partial data
      migration for VBUFFER data (basically provide migration for a
      sub-buffer) and for locating next in QTAILQ.
      
      The implementation of the VBUFFER feature is broken when VMSTATE_ALLOC
      is used. This however goes unnoticed because actually partial migration
      for VBUFFER is not used at all.
      
      Let's consolidate the usage of VMStateField.start by removing support
      for partial migration for VBUFFER.
      Signed-off-by: NHalil Pasic <pasic@linux.vnet.ibm.com>
      
      Message-Id: <20170203175217.45562-1-pasic@linux.vnet.ibm.com>
      Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
      Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
      59046ec2
  6. 25 1月, 2017 4 次提交
  7. 13 10月, 2016 2 次提交
  8. 17 6月, 2016 1 次提交
  9. 23 5月, 2016 1 次提交
  10. 29 1月, 2016 1 次提交
  11. 16 1月, 2016 2 次提交
  12. 07 7月, 2015 1 次提交
  13. 12 6月, 2015 2 次提交
  14. 06 2月, 2015 3 次提交
  15. 16 12月, 2014 1 次提交
    • D
      Start migrating migration code into a migration directory · 60fe637b
      Dr. David Alan Gilbert 提交于
      The migration code now occupies a fair chunk of the top level .c
      files, it seems time to give it it's own directory.
      
      I've not touched:
         arch_init.c - that's mostly RAM migration but has a few random other
                       bits
         savevm.c    - because it's built target specific
      
      This is purely a code move; no code has changed.
         - it fails checkpatch because of old violations, it feels safer
           to keep this as purely a move and fix those at some mythical future
           date.
      
      The xbzrle and vmstate tests are now only run for softmmu builds
      since they require files in the migrate/ directory which is only built
      for softmmu.
      Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
      Signed-off-by: NAmit Shah <amit.shah@redhat.com>
      60fe637b
  16. 14 10月, 2014 1 次提交
  17. 27 6月, 2014 1 次提交
    • A
      vmstate: Add preallocation for migrating arrays (VMS_ALLOC flag) · f32935ea
      Alexey Kardashevskiy 提交于
      There are few helpers already to support array migration. However they all
      require the destination side to preallocate arrays before migration which
      is not always possible due to unknown array size as it might be some
      sort of dynamic state. One of the examples is an array of MSIX-enabled
      devices in SPAPR PHB - this array may vary from 0 to 65536 entries and
      its size depends on guest's ability to enable MSIX or do PCI hotplug.
      
      This adds new VMSTATE_VARRAY_STRUCT_ALLOC macro which is pretty similar to
      VMSTATE_STRUCT_VARRAY_POINTER_INT32 but it can alloc memory for migratign
      array on the destination side.
      
      This defines VMS_ALLOC flag for a field.
      
      This changes vmstate_base_addr() to do the allocation when receiving
      migration.
      Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
      Reviewed-by: NJuan Quintela <quintela@redhat.com>
      [agraf: drop g_malloc_n usage]
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      f32935ea
  18. 24 6月, 2014 1 次提交
  19. 06 5月, 2014 2 次提交
  20. 05 5月, 2014 2 次提交
  21. 27 3月, 2014 1 次提交
  22. 25 2月, 2014 1 次提交
  23. 13 1月, 2014 1 次提交