1. 30 Jul, 2014 1 commit
  2. 27 Jul, 2014 1 commit
  3. 24 Jul, 2014 11 commits
  4. 22 Jul, 2014 10 commits
    • Peter Maydell's avatar
      f368c33d
    • Peter Maydell's avatar
      hw/misc/imx_ccm.c: Add missing VMState list terminator · ef493d5c
      Peter Maydell authored
      
      
      The VMStateDescription for the imx_ccm device was missing its
      terminator. Found by static search of the codebase using
      a regex based on one suggested by Ian Jackson:
        pcregrep -rMi '(?s)VMStateField(?:(?!END_OF_LIST).)*?;' $(git grep -l 'VMStateField\[\]')
      
      Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      Cc: qemu-stable@nongnu.org
      ef493d5c
    • Laszlo Ersek's avatar
      vmstate_xhci_event: fix unterminated field list · 3afca1d6
      Laszlo Ersek authored
      "vmstate_xhci_event" was introduced in commit 37352df3
      
       ("xhci: add live
      migration support"), and first released in v1.6.0. The field list in this
      VMSD is not terminated with the VMSTATE_END_OF_LIST() macro.
      
      During normal use (ie. migration), the issue is practically invisible,
      because the "vmstate_xhci_event" object (with the unterminated field list)
      is only ever referenced -- via "vmstate_xhci_intr" -- if xhci_er_full()
      returns true, for the "ev_buffer" test. Since that field_exists() check
      (apparently) almost always returns false, we almost never traverse
      "vmstate_xhci_event" during migration, which hides the bug.
      
      However, Amit's vmstate checker forces recursion into this VMSD as well,
      and the lack of VMSTATE_END_OF_LIST() breaks the field list terminator
      check (field->name != NULL) in dump_vmstate_vmsd(). The result is
      undefined behavior, which in my case translates to infinite recursion
      (because the loop happens to overflow into "vmstate_xhci_intr", which then
      links back to "vmstate_xhci_event").
      
      Add the missing terminator.
      
      Signed-off-by: default avatarLaszlo Ersek <lersek@redhat.com>
      Reviewed-by: default avatarAmit Shah <amit.shah@redhat.com>
      Reviewed-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Cc: qemu-stable@nongnu.org
      Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      3afca1d6
    • Peter Maydell's avatar
      Merge remote-tracking branch 'remotes/agraf/tags/signed-ppc-for-upstream' into staging · 3a18d449
      Peter Maydell authored
      
      
      Patch queue for ppc - 2014-07-22
      
      Only a single bug fix to make -mem-path only affect RAM regions.
      
      # gpg: Signature made Tue 22 Jul 2014 16:38:04 BST using RSA key ID 03FEDC60
      # gpg: Can't check signature: public key not found
      
      * remotes/agraf/tags/signed-ppc-for-upstream:
        ppc: fix -mem-path failure
      
      Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      3a18d449
    • Hu Tao's avatar
      ppc: fix -mem-path failure · e206ad48
      Hu Tao authored
      commit e938ba0c
      
       tried to enable -mem-path for ppc but breaked some ppc
      boards.
      
      The problems are:
      
      1. it fails when allocating memory for rom, sram whose sizes are less
         than huge page size:
      
         ./ppc-softmmu/qemu-system-ppc  -m 512 -mem-path /hugepages/ \
         -kernel /home/hutao/Downloads/vmlinux-ppc -initrd \
         /home/hutao/Downloads/initrd-ppc.gz
         qemu-system-ppc: /mnt/data/projects/qemu/exec.c:1184: qemu_ram_set_idstr: Assertion `new_block' failed.
      
      2. if there is a numa node backed by memory backend object, qemu fails
         with message:
      
         ./ppc-softmmu/qemu-system-ppc  -m 512 \
         -object memory-backend-file,size=512M,mem-path=/hugepages,id=f0 \
         -numa node,nodeid=0,memdev=f0 \
         -kernel /home/hutao/Downloads/vmlinux-ppc \
         -initrd /home/hutao/Downloads/initrd-ppc.gz
         qemu-system-ppc: memory backend f0 is used multiple times. Each -numa option must use a different memdev value.
      
      This patch does following:
      
      1. replaces memory_region_allocate_system_memory() with
         memory_region_init_ram() for rom, sram. Then only system memory
         is backed by hugepages when specifying mem-path.
      
      2. for memory banks, allocates all ram with
         one memory_region_allocate_system_memory(), and use
         memory_region_init_alias() to initialize memory banks.
      
      Tested machines: default(g3beige), mac99, taihu, bamboo, ref405ep.
      
      Signed-off-by: default avatarHu Tao <hutao@cn.fujitsu.com>
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      e206ad48
    • Peter Maydell's avatar
      Merge remote-tracking branch 'remotes/amit-virtio-rng/for-2.1' into staging · b64c670f
      Peter Maydell authored
      
      
      * remotes/amit-virtio-rng/for-2.1:
        virtio-rng: Add human-readable error message for negative max-bytes parameter
      
      Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      b64c670f
    • John Snow's avatar
      virtio-rng: Add human-readable error message for negative max-bytes parameter · 713e8a10
      John Snow authored
      
      
      If a negative integer is used for the max_bytes parameter, QEMU currently
      calls abort() and leaves behind a core dump. This patch replaces the
      abort with a simple error message to make the reason for the termination
      clearer. This also ensures device-hotplug with invalid input doesn't
      cause qemu to quit.
      
      There is an underlying insufficiency in the parameter parsing code of QEMU
      that renders it unable to reject negative values for unsigned properties,
      thus the error message "a non-negative integer below 2^63" is the most
      user-friendly and correct message we can give until the underlying
      insufficiency is corrected.
      
      Signed-off-by: default avatarJohn Snow <jsnow@redhat.com>
      Reviewed-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: default avatarAmit Shah <amit.shah@redhat.com>
      713e8a10
    • Peter Maydell's avatar
      Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging · 25af8e6b
      Peter Maydell authored
      
      
      One of the two pending migration fix, and a small KVM patch.
      
      # gpg: Signature made Tue 22 Jul 2014 11:49:30 BST using RSA key ID 9B4D86F2
      # gpg: Can't check signature: public key not found
      
      * remotes/bonzini/tags/for-upstream:
        kvm-all: Use 'tmpcpu' instead of 'cpu' in sub-looping to avoid 'cpu' be NULL
        exec: fix migration with devices that use address_space_rw
      
      Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      25af8e6b
    • Chen Gang's avatar
      kvm-all: Use 'tmpcpu' instead of 'cpu' in sub-looping to avoid 'cpu' be NULL · dc54e252
      Chen Gang authored
      
      
      If kvm_arch_remove_sw_breakpoint() in CPU_FOREACH() always be fail, it
      will let 'cpu' NULL. And the next kvm_arch_remove_sw_breakpoint() in
      QTAILQ_FOREACH_SAFE() will get NULL parameter for 'cpu'.
      
      And kvm_arch_remove_sw_breakpoint() can assumes 'cpu' must never be NULL,
      so need define additional temporary variable for 'cpu' to avoid the case.
      
      Cc: qemu-stable@nongnu.org
      Signed-off-by: default avatarChen Gang <gang.chen.5i5j@gmail.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      dc54e252
    • Paolo Bonzini's avatar
      exec: fix migration with devices that use address_space_rw · 6886867e
      Paolo Bonzini authored
      Devices that use address_space_rw to write large areas to memory
      (as opposed to address_space_map/unmap) were broken with respect
      to migration since fe680d0d
      
       (exec: Limit translation limiting in
      address_space_translate to xen, 2014-05-07).  Such devices include
      IDE CD-ROMs.
      
      The reason is that invalidate_and_set_dirty (called by address_space_rw
      but not address_space_map/unmap) was only setting the dirty bit for
      the first page in the translation.
      
      To fix this, introduce cpu_physical_memory_set_dirty_range_nocode that
      is the same as cpu_physical_memory_set_dirty_range except it does not
      muck with the DIRTY_MEMORY_CODE bitmap.  This function can be used if
      the caller invalidates translations with tb_invalidate_phys_page_range.
      
      There is another difference between cpu_physical_memory_set_dirty_range
      and cpu_physical_memory_set_dirty_flag; the former includes a call
      to xen_modified_memory.  This is handled separately in
      invalidate_and_set_dirty, and is not needed in other callers of
      cpu_physical_memory_set_dirty_range_nocode, so leave it alone.
      
      Just one nit: now that invalidate_and_set_dirty takes care of handling
      multiple pages, there is no need for address_space_unmap to wrap it
      in a loop.  In fact that loop would now be O(n^2).
      
      Reported-by: default avatarDave Gilbert <dgilbert@redhat.com>
      Reviewed-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Tested-by: default avatarGerd Hoffmann <kraxel@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      6886867e
  5. 21 Jul, 2014 2 commits
  6. 18 Jul, 2014 15 commits