1. 25 4月, 2015 4 次提交
    • E
      qmp: Give saner messages related to qmp_capabilities misuse · 2d5a8346
      Eric Blake 提交于
      Pretending that QMP doesn't understand a command merely because
      we are not in the right mode doesn't help first-time users figure
      out what to do to correct things.  Although the documentation for
      QMP calls out capabilities negotiation, we should also make it
      clear in our error messages what we were expecting.  With this
      patch, I now get the following transcript:
      
      $ ./x86_64-softmmu/qemu-system-x86_64 -qmp stdio -nodefaults
      {"QMP": {"version": {"qemu": {"micro": 93, "minor": 2, "major": 2}, "package": ""}, "capabilities": []}}
      {"execute":"huh"}
      {"error": {"class": "CommandNotFound", "desc": "The command huh has not been found"}}
      {"execute":"quit"}
      {"error": {"class": "CommandNotFound", "desc": "Expecting capabilities negotiation with 'qmp_capabilities' before command 'quit'"}}
      {"execute":"qmp_capabilities"}
      {"return": {}}
      {"execute":"qmp_capabilities"}
      {"error": {"class": "CommandNotFound", "desc": "Capabilities negotiation is already complete, command 'qmp_capabilities' ignored"}}
      {"execute":"quit"}
      {"return": {}}
      {"timestamp": {"seconds": 1429110729, "microseconds": 181935}, "event": "SHUTDOWN"}
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Tested-By: NKashyap Chamarthy <kchamart@redhat.com>
      Reviewed-by: NPaulo Vital <paulo.vital@profitbricks.com>
      Reviewed-by: NJohn Snow <jsnow@redhat.com>
      Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
      2d5a8346
    • P
      qmp-commands: fix incorrect uses of ":O" specifier · 43d0a2c1
      Paolo Bonzini 提交于
      As far as the QMP parser is concerned, neither the 'O' nor the 'q' format specifiers
      put any constraint on the command.  However, there are two differences:
      
      1) from a documentation point of view 'O' says that this command takes
      a dictionary.  The dictionary will be converted to QemuOpts in the
      handler to match the corresponding HMP command.
      
      2) 'O' sets QMP_ACCEPT_UNKNOWNS, resulting in the command accepting invalid
      extra arguments.  For example the following is accepted:
      
         { "execute": "send-key",
              "arguments": { "keys": [ { "type": "qcode", "data": "ctrl" },
                                       { "type": "qcode", "data": "alt" },
                                       { "type": "qcode", "data": "delete" } ], "foo": "bar" } }
      
      Neither send-key nor migrate-set-capabilities take a QemuOpts-like
      dictionary; they take an array of dictionaries.  And neither command
      really wants to have extra unknown arguments.  Thus, the right
      specifier to use in this case is 'q'; with this patch the above
      command fails with
      
         {"error": {"class": "GenericError", "desc": "Invalid parameter 'foo'"}}
      
      as intended.
      Reported-by: NAlberto Garcia <berto@igalia.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Reviewed-by: NAlberto Garcia <berto@igalia.com>
      Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
      43d0a2c1
    • E
      qapi: Drop dead genlist parameter · 6540e9f3
      Eric Blake 提交于
      Defaulting a parameter to True, then having all callers omit or
      pass an explicit True for that parameter, is pointless. Looks
      like it has been dead since introduction in commit 06d64c62, more
      than 4 years ago.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
      6540e9f3
    • L
      balloon: improve error msg when adding second device · 46abb812
      Luiz Capitulino 提交于
      A VM supports only one balloon device, but due to several changes
      in infrastructure the error message got messed up when trying
      to add a second device. Fix it.
      
      Before this fix
      
      Command-line:
      
      qemu-qmp: -device virtio-balloon-pci,id=balloon0: Another balloon device already registered
      qemu-qmp: -device virtio-balloon-pci,id=balloon0: Adding balloon handler failed
      qemu-qmp: -device virtio-balloon-pci,id=balloon0: Device 'virtio-balloon-pci' could not be initialized
      
      HMP:
      
      Another balloon device already registered
      Adding balloon handler failed
      Device 'virtio-balloon-pci' could not be initialized
      
      QMP:
      
      { "execute": "device_add", "arguments": { "driver": "virtio-balloon-pci", "id": "balloon0" } }
      {
      	"error": {
      		"class": "GenericError",
      		"desc": "Adding balloon handler failed"
      	}
      }
      
      After this fix
      
      Command-line:
      
      qemu-qmp: -device virtio-balloon-pci,id=balloon0: Only one balloon device is supported
      qemu-qmp: -device virtio-balloon-pci,id=balloon0: Device 'virtio-balloon-pci' could not be initialized
      
      HMP:
      
      (qemu) device_add virtio-balloon-pci,id=balloon0
      Only one balloon device is supported
      Device 'virtio-balloon-pci' could not be initialized
      (qemu)
      
      QMP:
      
      { "execute": "device_add",
                "arguments": { "driver": "virtio-balloon-pci", "id": "balloon0" } }
      {
          "error": {
              "class": "GenericError",
              "desc": "Only one balloon device is supported"
          }
      }
      Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      46abb812
  2. 24 4月, 2015 1 次提交
  3. 21 4月, 2015 1 次提交
  4. 20 4月, 2015 1 次提交
  5. 17 4月, 2015 5 次提交
  6. 14 4月, 2015 2 次提交
  7. 13 4月, 2015 3 次提交
    • P
      Revert seccomp tests that allow it to be used on non-x86 architectures · ae6e8ef1
      Peter Maydell 提交于
      Unfortunately it turns out that libseccomp 2.2 still does not work
      correctly on non-x86 architectures; return to the previous configure
      setup of insisting on libseccomp 2.1 or better and i386/x86_64 and
      disabling seccomp support in all other situations.
      
      This reverts the two commits:
       * "seccomp: libseccomp version varying according to arch"
         (commit 896848f0)
       * "seccomp: update libseccomp version and remove arch restriction"
         (commit 8e27fc20)
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      Message-id: 1428670681-23032-1-git-send-email-peter.maydell@linaro.org
      ae6e8ef1
    • T
      pci: Fix crash with illegal "-net nic, model=xxx" option · 4d0ecde4
      Thomas Huth 提交于
      Current QEMU crashes when specifying an illegal model with the
      "-net nic,model=xxx" option, e.g.:
      
       $ qemu-system-x86_64 -net nic,model=n/a
       qemu-system-x86_64: Unsupported NIC model: n/a
      
       Program received signal SIGSEGV, Segmentation fault.
      
      The gdb backtrace looks like this:
      
      0x0000555555965fe0 in error_get_pretty (err=0x0) at util/error.c:152
      152	    return err->msg;
      (gdb) bt
       0  0x0000555555965fe0 in error_get_pretty (err=0x0) at util/error.c:152
       1  0x0000555555965ffd in error_report_err (err=0x0) at util/error.c:157
       2  0x0000555555809c90 in pci_nic_init_nofail (nd=0x555555e49860 <nd_table>, rootbus=0x5555564409b0,
          default_model=0x55555598c37b "e1000", default_devaddr=0x0) at hw/pci/pci.c:1663
       3  0x0000555555691e42 in pc_nic_init (isa_bus=0x555556f71900, pci_bus=0x5555564409b0)
          at hw/i386/pc.c:1506
       4  0x000055555569396b in pc_init1 (machine=0x5555562abbf0, pci_enabled=1, kvmclock_enabled=1)
          at hw/i386/pc_piix.c:248
       5  0x0000555555693d27 in pc_init_pci (machine=0x5555562abbf0) at hw/i386/pc_piix.c:310
       6  0x000055555572ddf5 in main (argc=3, argv=0x7fffffffe018, envp=0x7fffffffe038) at vl.c:4226
      
      The problem is that pci_nic_init_nofail() does not check whether the err
      parameter from pci_nic_init has been set up and thus passes a NULL pointer
      to error_report_err(). Fix it by correctly checking the err parameter.
      Signed-off-by: NThomas Huth <thuth@redhat.com>
      Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
      Reviewed-by: NJason Wang <jasowang@redhat.com>
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      4d0ecde4
    • A
      stm32f205: Fix SoC type name · 342b0711
      Andreas Färber 提交于
      The type name for the SoC device, unlike those of its sub-devices,
      did not follow the QOM naming conventions. While the usage is internal
      only, this is exposed through QMP and HMP, so fix it before release.
      
      Cc: Alistair Francis <alistair.francis@xilinx.com>
      Signed-off-by: NAndreas Färber <afaerber@suse.de>
      Reviewed-by: NAlistair Francis <alistair@alistair23.me>
      Message-id: 1428676676-23056-1-git-send-email-afaerber@suse.de
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      342b0711
  8. 11 4月, 2015 1 次提交
  9. 10 4月, 2015 4 次提交
  10. 09 4月, 2015 5 次提交
    • P
      Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' into staging · a6f2cb03
      Peter Maydell 提交于
      # gpg: Signature made Thu Apr  9 10:55:11 2015 BST using RSA key ID 81AB73C8
      # gpg: Good signature from "Stefan Hajnoczi <stefanha@redhat.com>"
      # gpg:                 aka "Stefan Hajnoczi <stefanha@gmail.com>"
      
      * remotes/stefanha/tags/block-pull-request:
        block/iscsi: handle zero events from iscsi_which_events
        aio: strengthen memory barriers for bottom half scheduling
        virtio-blk: correctly dirty guest memory
        qcow2: Fix header update with overridden backing file
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      a6f2cb03
    • P
      tcg/tcg-op.c: Fix ld/st of 64 bit values on 32-bit bigendian hosts · cf811fff
      Peter Maydell 提交于
      Commit 951c6300 out-of-lined the 32-bit-host versions of
      tcg_gen_{ld,st}_i64, but in the process it inadvertently changed
      an #ifdef HOST_WORDS_BIGENDIAN to #ifdef TCG_TARGET_WORDS_BIGENDIAN.
      Since the latter doesn't get defined anywhere this meant we always
      took the "LE host" codepath, and stored the two halves of the value
      in the wrong order on BE hosts. This typically breaks any 64-bit
      guest on a 32-bit BE host completely, and will have possibly more
      subtle effects even for 32-bit guests.
      
      Switch the ifdef back to HOST_WORDS_BIGENDIAN.
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      Reviewed-by: NRichard Henderson <rth@twiddle.net>
      Tested-by: NAndreas Färber <afaerber@suse.de>
      Message-id: 1428523029-13620-1-git-send-email-peter.maydell@linaro.org
      cf811fff
    • P
      block/iscsi: handle zero events from iscsi_which_events · 05b685fb
      Peter Lieven 提交于
      newer libiscsi versions may return zero events from iscsi_which_events.
      
      In this case iscsi_service will return immediately without any progress.
      To avoid busy waiting for iscsi_which_events to change we deregister all
      read and write handlers in this case and schedule a timer to periodically
      check iscsi_which_events for changed events.
      
      Next libiscsi version will introduce async reconnects and zero events
      are returned while libiscsi is waiting for a reconnect retry.
      Signed-off-by: NPeter Lieven <pl@kamp.de>
      Message-id: 1428437295-29577-1-git-send-email-pl@kamp.de
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      05b685fb
    • P
      aio: strengthen memory barriers for bottom half scheduling · e8d3b1a2
      Paolo Bonzini 提交于
      There are two problems with memory barriers in async.c.  The fix is
      to use atomic_xchg in order to achieve sequential consistency between
      the scheduling of a bottom half and the corresponding execution.
      
      First, if bh->scheduled is already 1 in qemu_bh_schedule, QEMU does
      not execute a memory barrier to order any writes needed by the callback
      before the read of bh->scheduled.  If the other side sees req->state as
      THREAD_ACTIVE, the callback is not invoked and you get deadlock.
      
      Second, the memory barrier in aio_bh_poll is too weak.  Without this
      patch, it is possible that bh->scheduled = 0 is not "published" until
      after the callback has returned.  Another thread wants to schedule the
      bottom half, but it sees bh->scheduled = 1 and does nothing.  This causes
      a lost wakeup.  The memory barrier should have been changed to smp_mb()
      in commit 924fe129 (aio: fix qemu_bh_schedule() bh->ctx race condition,
      2014-06-03) together with qemu_bh_schedule()'s.  Guess who reviewed
      that patch?
      
      Both of these involve a store and a load, so they are reproducible on
      x86_64 as well.  It is however much easier on aarch64, where the
      libguestfs test suite triggers the bug fairly easily.  Even there the
      failure can go away or appear depending on compiler optimization level,
      tracing options, or even kernel debugging options.
      
      Paul Leveille however reported how to trigger the problem within 15
      minutes on x86_64 as well.  His (untested) recipe, reproduced here
      for reference, is the following:
      
         1) Qcow2 (or 3) is critical – raw files alone seem to avoid the problem.
      
         2) Use “cache=directsync” rather than the default of
         “cache=none” to make it happen easier.
      
         3) Use a server with a write-back RAID controller to allow for rapid
         IO rates.
      
         4) Run a random-access load that (mostly) writes chunks to various
         files on the virtual block device.
      
            a. I use ‘diskload.exe c:25’, a Microsoft HCT load
               generator, on Windows VMs.
      
            b. Iometer can probably be configured to generate a similar load.
      
         5) Run multiple VMs in parallel, against the same storage device,
         to shake the failure out sooner.
      
         6) IvyBridge and Haswell processors for certain; not sure about others.
      
      A similar patch survived over 12 hours of testing, where an unpatched
      QEMU would fail within 15 minutes.
      
      This bug is, most likely, also the cause of failures in the libguestfs
      testsuite on AArch64.
      
      Thanks to Laszlo Ersek for initially reporting this bug, to Stefan
      Hajnoczi for suggesting closer examination of qemu_bh_schedule, and to
      Paul for providing test input and a prototype patch.
      Reported-by: NLaszlo Ersek <lersek@redhat.com>
      Reported-by: NPaul Leveille <Paul.Leveille@stratus.com>
      Reported-by: NJohn Snow <jsnow@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Message-id: 1428419779-26062-1-git-send-email-pbonzini@redhat.com
      Suggested-by: NPaul Leveille <Paul.Leveille@stratus.com>
      Suggested-by: NStefan Hajnoczi <stefanha@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      e8d3b1a2
    • D
      arm: memory: Replace memory_region_init_ram with memory_region_allocate_system_memory · c8623c02
      Dirk Müller 提交于
      Commit 0b183fc8:"memory: move mem_path handling to
      memory_region_allocate_system_memory" split memory_region_init_ram and
      memory_region_init_ram_from_file. Also it moved mem-path handling a step
      up from memory_region_init_ram to memory_region_allocate_system_memory.
      
      Therefore for any board that uses memory_region_init_ram directly,
      -mem-path is not supported.
      
      Fix this by replacing memory_region_init_ram with
      memory_region_allocate_system_memory.
      Signed-off-by: NDirk Mueller <dmueller@suse.com>
      Message-id: CAL5wTH4UHYKpJF=dLJfFzxpufjY189chnCow47-ySuLf8GLbug@mail.gmail.com
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      c8623c02
  11. 08 4月, 2015 2 次提交
  12. 07 4月, 2015 1 次提交
    • P
      Merge remote-tracking branch 'remotes/mjt/tags/pull-trivial-patches-2015-04-04' into staging · 5a24f20a
      Peter Maydell 提交于
      trivial patches for 2015-04-04
      
      # gpg: Signature made Sat Apr  4 08:07:49 2015 BST using RSA key ID A4C3D7DB
      # gpg: Good signature from "Michael Tokarev <mjt@tls.msk.ru>"
      # gpg:                 aka "Michael Tokarev <mjt@corpit.ru>"
      # gpg:                 aka "Michael Tokarev <mjt@debian.org>"
      
      * remotes/mjt/tags/pull-trivial-patches-2015-04-04:
        vhost: fix typo in vq_index description
        gitignore: Ignore more .pod files.
        target-tricore: Fix check which was always false
        target-i386: remove superfluous TARGET_HAS_SMC macro
        pcspk: Fix I/O port name
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      5a24f20a
  13. 04 4月, 2015 5 次提交
  14. 03 4月, 2015 1 次提交
  15. 02 4月, 2015 4 次提交
    • C
      glib-compat: fix problems with not-quite glib 2.22 · 14655e9a
      Cornelia Huck 提交于
      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: NCornelia Huck <cornelia.huck@de.ibm.com>
      Message-id: 1427987865-433-2-git-send-email-cornelia.huck@de.ibm.com
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      14655e9a
    • P
      Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging · a8a7ef14
      Peter Maydell 提交于
      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: NPeter Maydell <peter.maydell@linaro.org>
      a8a7ef14
    • E
      Use $(MAKE) for recursive make · fb8597bb
      Ed Maste 提交于
      On BSDs "make" is typically BSD make, while "gmake" is GNU make.
      Signed-off-by: NEd 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: NPaolo Bonzini <pbonzini@redhat.com>
      fb8597bb
    • Z
      kvm-all: Sync dirty-bitmap from kvm before kvm destroy the corresponding dirty_bitmap · 4cc856fa
      zhanghailiang 提交于
      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: Nzhanghailiang <zhang.zhanghailiang@huawei.com>
      [Use s->migration_log instead of exec.c's in_migration. - Paolo]
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      4cc856fa