1. 18 2月, 2014 1 次提交
  2. 05 2月, 2014 1 次提交
  3. 29 1月, 2014 2 次提交
  4. 27 1月, 2014 1 次提交
  5. 16 1月, 2014 1 次提交
  6. 07 1月, 2014 3 次提交
  7. 23 12月, 2013 2 次提交
  8. 17 12月, 2013 1 次提交
    • L
      qemu_opts_parse(): always check return value · f46e720a
      Laszlo Ersek 提交于
      qemu_opts_parse() can always return NULL, even if the QemuOptsList.desc in
      question would be trivial to satisfy (eg. because it's empty). For
      example:
      
      qemu_opts_parse()
        opts_parse()
          qemu_opts_create()
            id_wellformed()
      
      In practice:
      
        $ .../qemu-system-x86_64 -acpitable id=3
        qemu-system-x86_64: -acpitable id=3: Parameter 'id' expects an identifier
        **
        ERROR:vl.c:3491:main: assertion failed: (opts != NULL)
        Aborted (core dumped)
      
        $ .../qemu-system-x86_64 -smbios id=3
        qemu-system-x86_64: -smbios id=3: Parameter 'id' expects an identifier
        Segmentation fault (core dumped)
      
      I checked all qemu_opts_parse() invocations (and all drive_def()
      invocations too, because it blindly forwards the former's retval). Only
      the two above examples look problematic.
      Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Message-id: 1385658779-7529-1-git-send-email-lersek@redhat.com
      Signed-off-by: NAnthony Liguori <aliguori@amazon.com>
      f46e720a
  9. 10 12月, 2013 2 次提交
  10. 02 12月, 2013 1 次提交
    • G
      add firmware to machine options · 1442d3e6
      Gerd Hoffmann 提交于
      This patch adds firmware to the machine options.  -bios <file> becomes a
      shortcut for -machine firmware=<file>.  Advantage is that the firmware
      can be specified via config file as -machine is parsed using QemuOpts
      and it is also possible to use different defaults for different
      machine types (via QEMUMachine->default_machine_opts).
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      1442d3e6
  11. 30 11月, 2013 2 次提交
  12. 25 11月, 2013 1 次提交
  13. 14 11月, 2013 1 次提交
  14. 13 11月, 2013 1 次提交
  15. 04 11月, 2013 1 次提交
    • P
      vl: allow "cont" from panicked state · df390768
      Paolo Bonzini 提交于
      After reporting the GUEST_PANICKED monitor event, QEMU stops the VM.
      The reason for this is that events are edge-triggered, and can be lost if
      management dies at the wrong time.  Stopping a panicked VM lets management
      know of a panic even if it has crashed; management can learn about the
      panic when it restarts and queries running QEMU processes.  The downside
      is of course that the VM will be paused while management is not running,
      but that is acceptable if it only happens with explicit "-device pvpanic".
      
      Upon learning of a panic, management (if configured to do so) can pick a
      variety of behaviors: leave the VM paused, reset it, destroy it.  In
      addition to all of these behaviors, it is possible to dump the VM core
      from the host.
      
      However, right now, the panicked state is irreversible, and can only be
      exited by resetting the machine.  This means that any policy decision
      is entirely in the hands of the host.  In particular there is no way to
      use the "reboot on panic" option together with pvpanic.
      
      This patch makes the panicked state reversible (and removes various
      workarounds that were there because of the state being irreversible).
      With this change, management has a wider set of possible policies: it
      can just log the crash and leave policy to the guest, it can leave the
      VM paused.  In particular, the "log the crash and continue" is implemented
      simply by sending a "cont" as soon as management learns about the panic.
      Management could also implement the "irreversible paused state" itself.
      And again, all such actions can be coupled with dumping the VM core.
      
      Unfortunately we cannot change the behavior of 1.6.0.  Thus, even if
      it uses "-device pvpanic", management should check for "cont" failures.
      If "cont" fails, management can then log that the VM remained paused
      and urge the administrator to update QEMU.
      Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
      Reviewed-by: NLuiz Capitulino <lcapitulino@redhat.com>
      Acked-by: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      df390768
  16. 17 10月, 2013 1 次提交
    • G
      spice: fix multihead support · 9fa03286
      Gerd Hoffmann 提交于
      This patch fixes spice display initialization to handle
      multihead properly.
      
      spice-core now keeps track of which QemuConsole has a spice
      display channel attached to it and which has not.  It also
      manages display channel ids.
      
      spice-display looks at all QemuConsoles and will pick up any
      graphic console not yet bound to a spice channel (which in practice
      are all non-qxl graphic devices).
      
      Result is that
       (a) you'll get a spice client window for each graphical device
           now (first only without this patch), and
       (b) mixing qxl and non-qxl vga cards works properly.
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      9fa03286
  17. 14 10月, 2013 1 次提交
  18. 05 10月, 2013 1 次提交
  19. 29 9月, 2013 2 次提交
    • M
      smbios: Make multiple -smbios type= accumulate sanely · fc3b3295
      Markus Armbruster 提交于
      Currently, -smbios type=T,NAME=VAL,... adds one field (T,NAME) with
      value VAL to fw_cfg for each unique NAME.  If NAME occurs multiple
      times, the last one's VAL is used (before the QemuOpts conversion, the
      first one was used).
      
      Multiple -smbios can add multiple fields with the same (T, NAME).
      SeaBIOS reads all of them from fw_cfg, but uses only the first field
      (T, NAME).  The others are ignored.
      
      "First one wins, subsequent ones get ignored silently" isn't nice.  We
      commonly let the last option win.  Useful, because it lets you
      -readconfig first, then selectively override with command line
      options.
      
      Clean up -smbios to work the common way.  Accumulate the settings,
      with later ones overwriting earlier ones.  Put the result into fw_cfg
      (no more useless duplicates).
      
      Bonus cleanup: qemu_uuid_parse() no longer sets SMBIOS system uuid by
      side effect.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      fc3b3295
    • M
      smbios: Convert to QemuOpts · 4f953d2f
      Markus Armbruster 提交于
      So that it can be set in config file for -readconfig.
      
      This tightens parsing of -smbios, and makes it more consistent with
      other options: unknown parameters are rejected, numbers with trailing
      junk are rejected, when a parameter is given multiple times, last
      rather than first wins, ...
      
      MST: drop one chunk to fix build errors
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      4f953d2f
  20. 26 9月, 2013 1 次提交
    • L
      qemu: Adjust qemu wakeup · 4bc78a87
      Liu, Jinsong 提交于
      Currently Xen hvm s3 has a bug coming from the difference between
      qemu-traditioanl and qemu-xen. For qemu-traditional, the way to
      resume from hvm s3 is via 'xl trigger' command. However, for
      qemu-xen, the way to resume from hvm s3 inherited from standard
      qemu, i.e. via QMP, and it doesn't work under Xen.
      
      The root cause is, for qemu-xen, 'xl trigger' command didn't reset
      devices, while QMP didn't unpause hvm domain though they did qemu
      system reset.
      
      We have two qemu patches and one xl patch to fix Xen hvm s3 bug.
      This patch is the qemu patch 1. It adjusts qemu wakeup so that
      Xen s3 resume logic (which will be implemented at qemu patch 2)
      will be notified after qemu system reset.
      Signed-off-by: NLiu Jinsong <jinsong.liu@intel.com>
      Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
      Reviewed-by: NAnthony PERARD <anthony.perard@citrix.com>
      4bc78a87
  21. 10 9月, 2013 2 次提交
  22. 28 8月, 2013 1 次提交
    • M
      hw: Clean up bogus default boot order · c1654732
      Markus Armbruster 提交于
      We set default boot order "cad" in every single machine definition
      except "pseries" and "moxiesim", even though very few boards actually
      care for boot order, and "cad" makes sense for even fewer.
      
      Machines that care:
      
      * pc and its variants
      
        Accept up to three letters 'a', 'b' (undocumented alias for 'a'),
        'c', 'd' and 'n'.  Reject all others (fatal with -boot).
      
      * nseries (n800, n810)
      
        Check whether order starts with 'n'.  Silently ignored otherwise.
      
      * prep, g3beige, mac99
      
        Extract the first character the machine understands (subset of
        'a'..'f').  Silently ignored otherwise.
      
      * spapr
      
        Accept an arbitrary string (vl.c restricts it to contain only
        'a'..'p', no duplicates).
      
      * sun4[mdc]
      
        Use the first character.  Silently ignored otherwise.
      
      Strip characters these machines ignore from their default boot order.
      
      For all other machines, remove the unused default boot order
      alltogether.
      
      Note that my rename of QEMUMachine member boot_order to
      default_boot_order and QEMUMachineInitArgs member boot_device to
      boot_order has a welcome side effect: it makes every use of boot
      orders visible in this patch, for easy review.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      c1654732
  23. 23 8月, 2013 2 次提交
  24. 20 8月, 2013 1 次提交
  25. 30 7月, 2013 1 次提交
  26. 11 7月, 2013 1 次提交
    • S
      add timestamp to error_report() · 5e2ac519
      Seiji Aguchi 提交于
      [Issue]
      When we offer a customer support service and a problem happens
      in a customer's system, we try to understand the problem by
      comparing what the customer reports with message logs of the
      customer's system.
      
      In this case, we often need to know when the problem happens.
      
      But, currently, there is no timestamp in qemu's error messages.
      Therefore, we may not be able to understand the problem based on
      error messages.
      
      [Solution]
      Add a timestamp to qemu's error message logged by
      error_report() with g_time_val_to_iso8601().
      Signed-off-by: NSeiji Aguchi <seiji.aguchi@hds.com>
      Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
      Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
      5e2ac519
  27. 10 7月, 2013 4 次提交
    • M
      vl: Tighten parsing of -machine option phandle_start · c1b71b0c
      Markus Armbruster 提交于
      Make it QEMU_OPT_NUMBER, so it gets parsed by generic code, which
      actually bothers to check for errors, rather than its user, which
      doesn't.
      
      Cc: Alexander Graf <agraf@suse.de>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Acked-by: NAlexander Graf <agraf@suse.de>
      Message-id: 1372943363-24081-8-git-send-email-armbru@redhat.com
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      c1b71b0c
    • M
      Simplify -machine option queries with qemu_get_machine_opts() · 2ff3de68
      Markus Armbruster 提交于
      The previous two commits fixed bugs in -machine option queries.  I
      can't find fault with the remaining queries, but let's use
      qemu_get_machine_opts() everywhere, for consistency, simplicity and
      robustness.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Message-id: 1372943363-24081-7-git-send-email-armbru@redhat.com
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      2ff3de68
    • M
      Fix -machine options accel, kernel_irqchip, kvm_shadow_mem · 36ad0e94
      Markus Armbruster 提交于
      Multiple -machine options with the same ID are merged.  All but the
      one without an ID are to be silently ignored.
      
      In most places, we query these options with a null ID.  This is
      correct.
      
      In some places, we instead query whatever options come first in the
      list.  This is wrong.  When the -machine processed first happens to
      have an ID, options are taken from that ID, and the ones specified
      without ID are silently ignored.
      
      Example:
      
          $ upstream-qemu -nodefaults -S -display none -monitor stdio -machine id=foo -machine accel=kvm,usb=on
          $ upstream-qemu -nodefaults -S -display none -monitor stdio -machine id=foo,accel=kvm,usb=on -machine accel=xen
          $ upstream-qemu -nodefaults -S -display none -monitor stdio -machine accel=xen -machine id=foo,accel=kvm,usb=on
      
          $ qemu-system-x86_64 -nodefaults -S -display none -monitor stdio -machine accel=kvm,usb=on
          QEMU 1.5.50 monitor - type 'help' for more information
          (qemu) info kvm
          kvm support: enabled
          (qemu) info usb
          (qemu) q
          $ qemu-system-x86_64 -nodefaults -S -display none -monitor stdio -machine id=foo -machine accel=kvm,usb=on
          QEMU 1.5.50 monitor - type 'help' for more information
          (qemu) info kvm
          kvm support: disabled
          (qemu) info usb
          (qemu) q
          $ qemu-system-x86_64 -nodefaults -S -display none -monitor stdio -machine id=foo,accel=kvm,usb=on -machine accel=xen
          QEMU 1.5.50 monitor - type 'help' for more information
          (qemu) info kvm
          kvm support: enabled
          (qemu) info usb
          USB support not enabled
          (qemu) q
          $ qemu-system-x86_64 -nodefaults -S -display none -monitor stdio -machine accel=xen -machine id=foo,accel=kvm,usb=on
          xc: error: Could not obtain handle on privileged command interface (2 = No such file or directory): Internal error
          xen be core: can't open xen interface
          failed to initialize Xen: Operation not permitted
      
      Option usb is queried correctly, and the one without an ID wins,
      regardless of option order.
      
      Option accel is queried incorrectly, and which one wins depends on
      option order and ID.
      
      Affected options are accel (and its sugared forms -enable-kvm and
      -no-kvm), kernel_irqchip, kvm_shadow_mem.
      
      Additionally, option kernel_irqchip is normally on by default, except
      it's off when no -machine options are given.  Bug can't bite, because
      kernel_irqchip is used only when KVM is enabled, KVM is off by
      default, and enabling always creates -machine options.  Downstreams
      that enable KVM by default do get bitten, though.
      
      Use qemu_get_machine_opts() to fix these bugs.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Message-id: 1372943363-24081-5-git-send-email-armbru@redhat.com
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      36ad0e94
    • M
      vl: New qemu_get_machine_opts() · 7f9d6e54
      Markus Armbruster 提交于
      To be used in the next few commits to fix or clean up queries of
      "machine" options (-machine and its sugared forms).
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Message-id: 1372943363-24081-4-git-send-email-armbru@redhat.com
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      7f9d6e54
  28. 29 6月, 2013 1 次提交
    • M
      vl: convert -smp to qemu_opts_parse() · 12b7f57e
      Michael Tokarev 提交于
      This also introduces a new suboption, "cpus=",
      which is the default.  So after this patch,
      
       -smp n,sockets=y
      
      is the same as
      
        -smp cpus=n,sockets=y
      
      (with "cpu" being some generic thing, referring to
      either cores, or threads, or sockets, as before).
      
      We still don't validate relations between different
      numbers, for example it is still possible to say
      
        -smp 1,sockets=10
      
      and it will be accepted to mean sockets=1.
      Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>
      Message-id: 1372072012-30305-1-git-send-email-mjt@msgid.tls.msk.ru
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      12b7f57e