1. 02 Apr, 2015 16 commits
    • Cornelia Huck's avatar
      glib-compat: fix problems with not-quite glib 2.22 · 14655e9a
      Cornelia Huck authored
      Commit 89b516d8
      
       ("glib: add
      compatibility interface for g_get_monotonic_time()") aimed
      at making qemu build with old glib versions. At least SLES11SP3,
      however, contains a backport of g_get_monotonic_time() while
      keeping the reported glib version at 2.22.
      
      Let's work around this by a strategically placed #define.
      
      Signed-off-by: default avatarCornelia Huck <cornelia.huck@de.ibm.com>
      Message-id: 1427987865-433-2-git-send-email-cornelia.huck@de.ibm.com
      Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      14655e9a
    • Peter Maydell's avatar
      Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging · a8a7ef14
      Peter Maydell authored
      
      Another round of small fixes.  I am not including the
      virtio-blk fix, because Wen only posted a prototype and the changes
      I made were pretty large.  It definitely needs another pair of eyes
      (but it is a 2.3 regression and a blocker).
      
      # gpg: Signature made Thu Apr  2 14:59:56 2015 BST using RSA key ID 78C7AE83
      # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>"
      # gpg:                 aka "Paolo Bonzini <pbonzini@redhat.com>"
      # gpg: WARNING: This key is not certified with sufficiently trusted signatures!
      # gpg:          It is not certain that the signature belongs to the owner.
      # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4  E2F7 7E15 100C CD36 69B1
      #      Subkey fingerprint: F133 3857 4B66 2389 866C  7682 BFFB D25F 78C7 AE83
      
      * remotes/bonzini/tags/for-upstream:
        Use $(MAKE) for recursive make
        kvm-all: Sync dirty-bitmap from kvm before kvm destroy the corresponding dirty_bitmap
        util/qemu-config: fix regression of qmp_query_command_line_options
        target-i386: clear bsp bit when designating bsp
        qga: fitering out -fstack-protector-strong
        target-i386: save 64-bit CR3 in 64-bit SMM state save area
      
      Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      a8a7ef14
    • Ed Maste's avatar
      Use $(MAKE) for recursive make · fb8597bb
      Ed Maste authored
      
      On BSDs "make" is typically BSD make, while "gmake" is GNU make.
      
      Signed-off-by: default avatarEd Maste <emaste@freebsd.org>
      Message-Id: <1427911118-21905-1-git-send-email-emaste@freebsd.org>
      [Fix $(INSTALLER) too as reported by Fam Zheng. - Paolo]
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      fb8597bb
    • zhanghailiang's avatar
      kvm-all: Sync dirty-bitmap from kvm before kvm destroy the corresponding dirty_bitmap · 4cc856fa
      zhanghailiang authored
      
      Sometimes, we destroy the dirty_bitmap in kvm_memory_slot before any sync action
      occur, this bit in dirty_bitmap will be missed, and which will lead the corresponding
      dirty pages to be missed in migration.
      
      This usually happens when do migration during VM's Start-up or Reboot.
      
      Signed-off-by: default avatarzhanghailiang <zhang.zhanghailiang@huawei.com>
      [Use s->migration_log instead of exec.c's in_migration. - Paolo]
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      4cc856fa
    • Marcel Apfelbaum's avatar
      util/qemu-config: fix regression of qmp_query_command_line_options · 0a7cf217
      Marcel Apfelbaum authored
      Commit 49d2e648
      
       (machine: remove qemu_machine_opts global list)
      made machine options specific to machine sub-type, leaving
      the qemu_machine_opts desc array empty. Sadly this is the place
      qmp_query_command_line_options is looking for supported options.
      
      As a fix for for 2.3 the machine_qemu_opts (the generic ones)
      are restored only for qemu-config scope.
      We need to find a better fix for 2.4.
      
      Reported-by: default avatarTony Krowiak <akrowiak@linux.vnet.ibm.com>
      Signed-off-by: default avatarMarcel Apfelbaum <marcel@redhat.com>
      Message-Id: <1427906841-1576-1-git-send-email-marcel@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      0a7cf217
    • Nadav Amit's avatar
      target-i386: clear bsp bit when designating bsp · 9cb11fd7
      Nadav Amit authored
      
      Since the BSP bit is writable on real hardware, during reset all the CPUs which
      were not chosen to be the BSP should have their BSP bit cleared. This fix is
      required for KVM to work correctly when it changes the BSP bit.
      
      An additional fix is required for QEMU tcg to allow software to change the BSP
      bit.
      
      Signed-off-by: default avatarNadav Amit <namit@cs.technion.ac.il>
      Message-Id: <1427932716-11800-1-git-send-email-namit@cs.technion.ac.il>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      9cb11fd7
    • Joseph Hindin's avatar
      qga: fitering out -fstack-protector-strong · 420957a5
      Joseph Hindin authored
      configure script may add -fstack-protector-strong option instead
      of -fstack-protector-all, depending on availability ( see
      commit 63678e17
      
       ). Both options have to by filtered out for
      qga-vss.dll, otherwise MinGW cross-compilation fails at linking
      stage.
      
      Signed-off-by: default avatarJoseph Hindin <jhindin@daynix.com>
      Message-Id: <1427906337-20805-2-git-send-email-jhindin@daynix.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      420957a5
    • Paolo Bonzini's avatar
      target-i386: save 64-bit CR3 in 64-bit SMM state save area · cbea0c26
      Paolo Bonzini authored
      
      The x86_64 CR3 register is 64 bits wide, save all of them!
      
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      cbea0c26
    • Peter Maydell's avatar
      Merge remote-tracking branch 'remotes/armbru/tags/pull-hw-2015-04-02' into staging · 913fbe9a
      Peter Maydell authored
      
      hw: Contain drive, serial, parallel, net misuse
      
      # gpg: Signature made Thu Apr  2 14:32:00 2015 BST using RSA key ID EB918653
      # gpg: Good signature from "Markus Armbruster <armbru@redhat.com>"
      # gpg:                 aka "Markus Armbruster <armbru@pond.sub.org>"
      
      * remotes/armbru/tags/pull-hw-2015-04-02:
        sysbus: Make devices picking up backends unavailable with -device
        sdhci: Make device "sdhci-pci" unavailable with -device
        hw: Mark device misusing nd_table[] FIXME
        hw: Mark devices picking up char backends actively FIXME
        hw: Mark devices picking up block backends actively FIXME
      
      Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      913fbe9a
    • Markus Armbruster's avatar
      sysbus: Make devices picking up backends unavailable with -device · 9f9bdf43
      Markus Armbruster authored
      
      Device models aren't supposed to go on fishing expeditions for
      backends.  They should expose suitable properties for the user to set.
      For onboard devices, board code sets them.
      
      A number of sysbus devices pick up block backends in their init() /
      instance_init() methods with drive_get_next() instead: sl-nand,
      milkymist-memcard, pl181, generic-sdhci.
      
      Likewise, a number of sysbus devices pick up character backends in
      their init() / realize() methods with qemu_char_get_next_serial():
      cadence_uart, digic-uart, etraxfs,serial, lm32-juart, lm32-uart,
      milkymist-uart, pl011, stm32f2xx-usart, xlnx.xps-uartlite.
      
      All these mistakes are already marked FIXME.  See the commit that
      added these FIXMEs for a more detailed explanation of what's wrong.
      
      Fortunately, only machines ppce500 and pseries-* support -device with
      sysbus devices, and none of the devices above is supported with these
      machines.
      
      Set cannot_instantiate_with_device_add_yet to preserve our luck.
      
      Cc: Andrzej Zaborowski <balrogg@gmail.com>
      Cc: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
      Cc: Antony Pavlov <antonynpavlov@gmail.com>
      Cc: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>
      Cc: Michael Walle <michael@walle.cc>
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      9f9bdf43
    • Markus Armbruster's avatar
      sdhci: Make device "sdhci-pci" unavailable with -device · 19109131
      Markus Armbruster authored
      
      Device models aren't supposed to go on fishing expeditions for
      backends.  They should expose suitable properties for the user to set.
      For onboard devices, board code sets them.
      
      "sdhci-pci" picks up its block backend in its realize() method with
      drive_get_next() instead.  Already marked FIXME.  See the commit that
      added the FIXME for a more detailed explanation of what's wrong.
      
      We can't fix this in time for the release, but since the device is new
      in 2.3, we can set cannot_instantiate_with_device_add_yet to disable
      it before this mistake becomes ABI, and we have to support command
      lines like
      
          $ qemu -drive if=sd -drive if=sd,file=sd.img -device sdhci-pci -device sdhci-pci
      
      forever.
      
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      19109131
    • Markus Armbruster's avatar
      hw: Mark device misusing nd_table[] FIXME · 19f33f16
      Markus Armbruster authored
      
      NICs defined with -net nic are for board initialization to wire up.
      Board code examines nd_table[] to find them, and creates devices with
      their qdev NIC properties set accordingly.
      
      Except "allwinner-a10" goes on a fishing expedition for NIC
      configuration instead of exposing the usual NIC properties for board
      code to set: it uses nd_table[0] in its instance_init() method.
      
      Picking up the first -net nic option's configuration that way works
      when the device is created by board code.  But it's inappropriate for
      -device and device_add.  Not only is it inconsistent with how the
      other block device models work (they get their configuration from
      properties "mac", "vlan", "netdev"), it breaks when nd_table[0] has
      been picked up by the board or a previous -device / device_add
      already.
      
      Example:
      
          $ qemu-system-arm -S -M cubieboard -device allwinner-a10
          qemu-system-arm: -device allwinner-a10: Property 'allwinner-emac.netdev' can't take value 'hub0port0', it's in use
          Aborted (core dumped)
      
      It also breaks in other entertaining ways:
      
          $ qemu-system-arm -M highbank -device allwinner-a10
          qemu-system-arm: -device allwinner-a10: Unsupported NIC model: xgmac
          $ qemu-system-arm -M highbank -net nic,model=allwinner-emac -device allwinner-a10
          qemu-system-arm: Unsupported NIC model: allwinner-emac
      
      Mark the mistake with a FIXME comment.
      
      Cc: Li Guang <lig.fnst@cn.fujitsu.com>
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      19f33f16
    • Markus Armbruster's avatar
      hw: Mark devices picking up char backends actively FIXME · d71b22bb
      Markus Armbruster authored
      
      Character devices defined with -serial and -parallel are for board
      initialization to wire up.  Board code examines serial_hds[] and
      parallel_hds[] to find them, and creates devices with their qdev
      chardev properties set accordingly.
      
      Except a few devices go on a fishing expedition for a suitable backend
      instead of exposing a chardev property for board code to set: they use
      serial_hds[] (often via qemu_char_get_next_serial()) or parallel_hds[]
      in their realize() or init() method to connect to a backend.
      
      Picking up backends that way works when the devices are created by
      board code.  But it's inappropriate for -device or device_add.  Not
      only is it inconsistent with how the other characrer device models
      work (they connect to a backend explicitly identified by a "chardev"
      property), it breaks when the backend has been picked up by the board
      or a previous -device / device_add already.
      
      Example:
      
          $ qemu-system-ppc64 -M bamboo -S -device i82378 -device pc87312 -device pc87312
          qemu-system-ppc64: -device pc87312: Property 'isa-parallel.chardev' can't take value 'parallel0', it's in use
      
      Mark them with suitable FIXME comments.
      
      Cc: Li Guang <lig.fnst@cn.fujitsu.com>
      Cc: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
      Cc: Antony Pavlov <antonynpavlov@gmail.com>
      Cc: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>
      Cc: Michael Walle <michael@walle.cc>
      Cc: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
      Cc: "Andreas Färber" <andreas.faerber@web.de>
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      d71b22bb
    • Markus Armbruster's avatar
      hw: Mark devices picking up block backends actively FIXME · af9e40aa
      Markus Armbruster authored
      
      Drives defined with if!=none are for board initialization to wire up.
      Board code calls drive_get() or similar to find them, and creates
      devices with their qdev drive properties set accordingly.
      
      Except a few devices go on a fishing expedition for a suitable backend
      instead of exposing a drive property for board code to set: they call
      driver_get() or drive_get_next() in their realize() or init() method
      to implicitly connect to the "next" backend with a certain interface
      type.
      
      Picking up backends that way works when the devices are created by
      board code.  But it's inappropriate for -device or device_add.  Not
      only is this inconsistent with how the other block device models work
      (they connect to a backend explicitly identified by a "drive"
      property), it breaks when the "next" backend has been picked up by the
      board already.
      
      Example:
      
          $ qemu-system-arm -S -M connex -pflash flash.img -device ssi-sd
          Aborted (core dumped)
      
      Mark them with suitable FIXME comments.
      
      Cc: Andrzej Zaborowski <balrogg@gmail.com>
      Cc: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
      Cc: "Andreas Färber" <andreas.faerber@web.de>
      Cc: Michael Walle <michael@walle.cc>
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      af9e40aa
    • Peter Maydell's avatar
      hw/arm/vexpress: Don't double-free flash filename · 11f10cf8
      Peter Maydell authored
      Commits 6e05a12f and db25a158
      
       both attempt to fix the
      same "failed to free memory containing flash filename" bug,
      with the effect that when they were both applied we ended
      up freeing the memory twice. Delete the spurious extra free.
      
      Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      Reviewed-by: default avatarStefan Weil <sw@weilnetz.de>
      Message-id: 1427968334-14527-1-git-send-email-peter.maydell@linaro.org
      11f10cf8
    • Shannon Zhao's avatar
      hw/arm/virt: Fix corruption due to double free · c408d27a
      Shannon Zhao authored
      As 4de9a883(hw/arm/virt: Fix memory leak reported by Coverity)
      and 6e05a12f
      
      (arm: fix memory leak) both handle the memory leak
      reported by Coverity, this cause qemu corruption due to
      double free.
      
      Signed-off-by: default avatarShannon Zhao <zhaoshenglong@huawei.com>
      Signed-off-by: default avatarShannon Zhao <shannon.zhao@linaro.org>
      Reviewed-by: default avatarStefan Weil <sw@weilnetz.de>
      Message-id: 1427944026-8968-1-git-send-email-zhaoshenglong@huawei.com
      Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      c408d27a
  2. 01 Apr, 2015 18 commits
  3. 31 Mar, 2015 4 commits
  4. 30 Mar, 2015 2 commits