1. 28 4月, 2015 16 次提交
  2. 26 4月, 2015 1 次提交
  3. 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
  4. 24 4月, 2015 1 次提交
  5. 21 4月, 2015 1 次提交
  6. 20 4月, 2015 1 次提交
  7. 17 4月, 2015 5 次提交
  8. 14 4月, 2015 2 次提交
  9. 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
  10. 11 4月, 2015 1 次提交
  11. 10 4月, 2015 4 次提交
  12. 09 4月, 2015 1 次提交