1. 18 12月, 2018 1 次提交
  2. 17 8月, 2018 1 次提交
  3. 02 7月, 2018 1 次提交
  4. 29 6月, 2018 1 次提交
    • M
      kvm: support -overcommit cpu-pm=on|off · 6f131f13
      Michael S. Tsirkin 提交于
      With this flag, kvm allows guest to control host CPU power state.  This
      increases latency for other processes using same host CPU in an
      unpredictable way, but if decreases idle entry/exit times for the
      running VCPU, so to use it QEMU needs a hint about whether host CPU is
      overcommitted, hence the flag name.
      
      Follow-up patches will expose this capability to guest
      (using mwait leaf).
      
      Based on a patch by Wanpeng Li <kernellwp@gmail.com> .
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      Message-Id: <20180622192148.178309-2-mst@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      6f131f13
  5. 31 5月, 2018 1 次提交
    • I
      cli: add --preconfig option · 047f7038
      Igor Mammedov 提交于
      This option allows pausing QEMU in the new RUN_STATE_PRECONFIG state,
      allowing the configuration of QEMU from QMP before the machine jumps
      into board initialization code of machine_run_board_init()
      
      The intent is to allow management to query machine state and additionally
      configure it using previous query results within one QEMU instance
      (i.e. eliminate the need to start QEMU twice, 1st to query board specific
      parameters and 2nd for actual VM start using query results for
      additional parameters).
      
      The new option complements -S option and could be used with or without
      it. The difference is that -S pauses QEMU when the machine is completely
      initialized with all devices wired up and ready to execute guest code
      (QEMU needs only to unpause VCPUs to let guest execute its code),
      while the "preconfig" option pauses QEMU early before board specific init
      callback (machine_run_board_init) is executed and allows the configuration
      of machine parameters which will be used by board init code.
      
      When early introspection/configuration is done, command 'exit-preconfig'
      should be used to exit RUN_STATE_PRECONFIG and transition to the next
      requested state (i.e. if -S is used then QEMU will pause the second
      time when board/device initialization is completed or start guest
      execution if -S isn't provided on CLI)
      
      PS:
      Initially 'preconfig' is planned to be used for configuring numa
      topology depending on board specified possible cpus layout.
      Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Message-Id: <1526059483-42847-1-git-send-email-imammedo@redhat.com>
      [ehabkost: Changed "since 2.13" to "since 3.0"]
      Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
      047f7038
  6. 26 4月, 2018 3 次提交
  7. 12 3月, 2018 1 次提交
  8. 09 3月, 2018 1 次提交
    • S
      vl: introduce vm_shutdown() · 4486e89c
      Stefan Hajnoczi 提交于
      Commit 00d09fdb ("vl: pause vcpus before
      stopping iothreads") and commit dce8921b
      ("iothread: Stop threads before main() quits") tried to work around the
      fact that emulation was still active during termination by stopping
      iothreads.  They suffer from race conditions:
      1. virtio_scsi_handle_cmd_vq() racing with iothread_stop_all() hits the
         virtio_scsi_ctx_check() assertion failure because the BDS AioContext
         has been modified by iothread_stop_all().
      2. Guest vq kick racing with main loop termination leaves a readable
         ioeventfd that is handled by the next aio_poll() when external
         clients are enabled again, resulting in unwanted emulation activity.
      
      This patch obsoletes those commits by fully disabling emulation activity
      when vcpus are stopped.
      
      Use the new vm_shutdown() function instead of pause_all_vcpus() so that
      vm change state handlers are invoked too.  Virtio devices will now stop
      their ioeventfds, preventing further emulation activity after vm_stop().
      
      Note that vm_stop(RUN_STATE_SHUTDOWN) cannot be used because it emits a
      QMP STOP event that may affect existing clients.
      
      It is no longer necessary to call replay_disable_events() directly since
      vm_shutdown() does so already.
      
      Drop iothread_stop_all() since it is no longer used.
      
      Cc: Fam Zheng <famz@redhat.com>
      Cc: Kevin Wolf <kwolf@redhat.com>
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      Reviewed-by: NFam Zheng <famz@redhat.com>
      Acked-by: NPaolo Bonzini <pbonzini@redhat.com>
      Message-id: 20180307144205.20619-5-stefanha@redhat.com
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      4486e89c
  9. 05 3月, 2018 1 次提交
    • T
      net: Add a new convenience option "--nic" to configure default/on-board NICs · 78cd6f7b
      Thomas Huth 提交于
      The legacy "-net" option can be quite confusing for the users since most
      people do not expect to get a "vlan" hub between their emulated guest
      hardware and the host backend. But so far, we are also not able to get
      rid of "-net" completely, since it is the only way to configure on-board
      NICs that can not be instantiated via "-device" yet. It's also a little
      bit shorter to type "-net nic -net tap" instead of "-device xyz,netdev=n1
      -netdev tap,id=n1".
      
      So what we need is a new convenience option that is shorter to type than
      the full -device + -netdev stuff, and which can be used to configure the
      on-board NICs that can not be handled via -device yet. Thus this patch now
      provides such a new option "--nic": It adds an entry in the nd_table to
      configure a on-board / default NIC, creates a host backend and connects
      the two directly, without a confusing "vlan" hub inbetween.
      Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NThomas Huth <thuth@redhat.com>
      Signed-off-by: NJason Wang <jasowang@redhat.com>
      78cd6f7b
  10. 03 3月, 2018 1 次提交
  11. 09 2月, 2018 2 次提交
  12. 25 1月, 2018 1 次提交
    • G
      sdl: reorganize -no-frame support · 04ff1a39
      Gerd Hoffmann 提交于
      Drop no_frame flag from sdl_display_init argument list, use a global
      variable instead.  This is temporary until -no-frame support is dropped
      altogether when we remove sdl1 support.
      
      Remove any traces of noframe from sdl2 code.  It is just dead code as
      sdl2 doesn't support the SDL_NOFRAME window flag any more.
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      Message-id: 20180115154855.30850-3-kraxel@redhat.com
      04ff1a39
  13. 14 12月, 2017 1 次提交
  14. 10 10月, 2017 1 次提交
    • S
      vl: exit if maxcpus is negative · c0dd1099
      Seeteena Thoufeek 提交于
      Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
      
      ---Steps to Reproduce---
      
      When passed a negative number to 'maxcpus' parameter, Qemu aborts
      with a core dump.
      
      Run the following command with maxcpus argument as negative number
      
      ppc64-softmmu/qemu-system-ppc64 --nographic -vga none -machine
      pseries,accel=kvm,kvm-type=HV -m size=200g -device virtio-blk-pci,
      drive=rootdisk -drive file=/home/images/pegas-1.0-ppc64le.qcow2,
      if=none,cache=none,id=rootdisk,format=qcow2 -monitor telnet
      :127.0.0.1:1234,server,nowait -net nic,model=virtio -net
      user -redir tcp:2000::22 -device nec-usb-xhci -smp 8,cores=1,
      threads=1,maxcpus=-12
      
      (process:12149): GLib-ERROR **: gmem.c:130: failed to allocate
       18446744073709550568 bytes
      
      Trace/breakpoint trap
      Reported-by: NR.Nageswara Sastry <rnsastry@linux.vnet.ibm.com>
      Signed-off-by: NSeeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
      Message-Id: <1504511031-26834-1-git-send-email-s1seetee@linux.vnet.ibm.com>
      Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
      c0dd1099
  15. 28 6月, 2017 1 次提交
  16. 02 6月, 2017 1 次提交
  17. 31 5月, 2017 1 次提交
  18. 23 5月, 2017 3 次提交
    • E
      shutdown: Expose bool cause in SHUTDOWN and RESET events · 08fba7ac
      Eric Blake 提交于
      Libvirt would like to be able to distinguish between a SHUTDOWN
      event triggered solely by guest request and one triggered by a
      SIGTERM or other action on the host.  While qemu_kill_report() was
      already able to give different output to stderr based on whether a
      shutdown was triggered by a host signal (but NOT by a host UI event,
      such as clicking the X on the window), that information was then
      lost to management.  The previous patches improved things to use an
      enum throughout all callsites, so now we have something ready to
      expose through QMP.
      
      Note that for now, the decision was to expose ONLY a boolean,
      rather than promoting ShutdownCause to a QAPI enum; this is because
      libvirt has not expressed an interest in anything finer-grained.
      We can still add additional details, in a backwards-compatible
      manner, if a need later arises (if the addition happens before 2.10,
      we can replace the bool with an enum; otherwise, the enum will have
      to be in addition to the bool); this patch merely adds a helper
      shutdown_caused_by_guest() to map the internal enum into the
      external boolean.
      
      Update expected iotest outputs to match the new data (complete
      coverage of the affected tests is obtained by -raw, -qcow2, and -nbd).
      
      Here is output from 'virsh qemu-monitor-event --loop' with the
      patch installed:
      
      event SHUTDOWN at 1492639680.731251 for domain fedora_13: {"guest":true}
      event STOP at 1492639680.732116 for domain fedora_13: <null>
      event SHUTDOWN at 1492639680.732830 for domain fedora_13: {"guest":false}
      
      Note that libvirt runs qemu with -no-shutdown: the first SHUTDOWN event
      was triggered by an action I took directly in the guest (shutdown -h),
      at which point qemu stops the vcpus and waits for libvirt to do any
      final cleanups; the second SHUTDOWN event is the result of libvirt
      sending SIGTERM now that it has completed cleanup.  Libvirt is already
      smart enough to only feed the first qemu SHUTDOWN event to the end user
      (remember, virsh qemu-monitor-event is a low-level debugging interface
      that is explicitly unsupported by libvirt, so it sees things that normal
      end users do not); changing qemu to emit SHUTDOWN only once is outside
      the scope of this series.
      
      See also https://bugzilla.redhat.com/1384007Signed-off-by: NEric Blake <eblake@redhat.com>
      Message-Id: <20170515214114.15442-6-eblake@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      08fba7ac
    • E
      shutdown: Add source information to SHUTDOWN and RESET · cf83f140
      Eric Blake 提交于
      Time to wire up all the call sites that request a shutdown or
      reset to use the enum added in the previous patch.
      
      It would have been less churn to keep the common case with no
      arguments as meaning guest-triggered, and only modified the
      host-triggered code paths, via a wrapper function, but then we'd
      still have to audit that I didn't miss any host-triggered spots;
      changing the signature forces us to double-check that I correctly
      categorized all callers.
      
      Since command line options can change whether a guest reset request
      causes an actual reset vs. a shutdown, it's easy to also add the
      information to reset requests.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Acked-by: David Gibson <david@gibson.dropbear.id.au> [ppc parts]
      Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> [SPARC part]
      Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> [s390x parts]
      Message-Id: <20170515214114.15442-5-eblake@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      cf83f140
    • E
      shutdown: Prepare for use of an enum in reset/shutdown_request · aedbe192
      Eric Blake 提交于
      We want to track why a guest was shutdown; in particular, being able
      to tell the difference between a guest request (such as ACPI request)
      and host request (such as SIGINT) will prove useful to libvirt.
      Since all requests eventually end up changing shutdown_requested in
      vl.c, the logical change is to make that value track the reason,
      rather than its current 0/1 contents.
      
      Since command-line options control whether a reset request is turned
      into a shutdown request instead, the same treatment is given to
      reset_requested.
      
      This patch adds an internal enum ShutdownCause that describes reasons
      that a shutdown can be requested, and changes qemu_system_reset() to
      pass the reason through, although for now nothing is actually changed
      with regards to what gets reported.  The enum could be exported via
      QAPI at a later date, if deemed necessary, but for now, there has not
      been a request to expose that much detail to end clients.
      
      For the most part, we turn 0 into SHUTDOWN_CAUSE_NONE, and 1 into
      SHUTDOWN_CAUSE_HOST_ERROR; the only specific case where we have enough
      information right now to use a different value is when we are reacting
      to a host signal.  It will take a further patch to edit all call-sites
      that can trigger a reset or shutdown request to properly pass in any
      other reasons; this patch includes TODOs to point such places out.
      
      qemu_system_reset() trades its 'bool report' parameter for a
      'ShutdownCause reason', with all non-zero values having the same
      effect; this lets us get rid of the weird #defines for VMRESET_*
      as synonyms for bools.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Message-Id: <20170515214114.15442-3-eblake@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      aedbe192
  19. 19 5月, 2017 2 次提交
  20. 17 5月, 2017 2 次提交
  21. 12 5月, 2017 1 次提交
    • H
      numa: Allow setting NUMA distance for different NUMA nodes · 0f203430
      He Chen 提交于
      This patch is going to add SLIT table support in QEMU, and provides
      additional option `dist` for command `-numa` to allow user set vNUMA
      distance by QEMU command.
      
      With this patch, when a user wants to create a guest that contains
      several vNUMA nodes and also wants to set distance among those nodes,
      the QEMU command would like:
      
      ```
      -numa node,nodeid=0,cpus=0 \
      -numa node,nodeid=1,cpus=1 \
      -numa node,nodeid=2,cpus=2 \
      -numa node,nodeid=3,cpus=3 \
      -numa dist,src=0,dst=1,val=21 \
      -numa dist,src=0,dst=2,val=31 \
      -numa dist,src=0,dst=3,val=41 \
      -numa dist,src=1,dst=2,val=21 \
      -numa dist,src=1,dst=3,val=31 \
      -numa dist,src=2,dst=3,val=21 \
      ```
      Signed-off-by: NHe Chen <he.chen@linux.intel.com>
      Message-Id: <1493260558-20728-1-git-send-email-he.chen@linux.intel.com>
      Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
      Reviewed-by: NAndrew Jones <drjones@redhat.com>
      Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
      0f203430
  22. 04 5月, 2017 4 次提交
  23. 21 4月, 2017 1 次提交
  24. 16 2月, 2017 2 次提交
  25. 28 1月, 2017 2 次提交
  26. 17 1月, 2017 1 次提交
  27. 13 1月, 2017 1 次提交
  28. 25 10月, 2016 1 次提交