qemu-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] cff3e8: scsi: Ignore executable for in-tree b


From: GitHub
Subject: [Qemu-commits] [qemu/qemu] cff3e8: scsi: Ignore executable for in-tree builds
Date: Tue, 03 Oct 2017 09:42:03 -0700

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: cff3e8b8d65abf3ac8be50de2020b92b54df0547
      
https://github.com/qemu/qemu/commit/cff3e8b8d65abf3ac8be50de2020b92b54df0547
  Author: Eric Blake <address@hidden>
  Date:   2017-09-29 (Fri, 29 Sep 2017)

  Changed paths:
    M .gitignore

  Log Message:
  -----------
  scsi: Ignore executable for in-tree builds

The new qemu-pr-helper (commit b855f8d17) should not be checked in,
even when doing in-tree builds.

Signed-off-by: Eric Blake <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: 65072c157e466db2785748a929e775703b20eefe
      
https://github.com/qemu/qemu/commit/65072c157e466db2785748a929e775703b20eefe
  Author: Eduardo Habkost <address@hidden>
  Date:   2017-09-29 (Fri, 29 Sep 2017)

  Changed paths:
    M iothread.c

  Log Message:
  -----------
  iothread: Make iothread_stop() idempotent

Currently, iothread_stop_all() makes all iothread objects unsafe
to be destroyed, because qemu_thread_join() ends up being called
twice.

To fix this, make iothread_stop() idempotent by checking
thread->stopped.

Fixes the following crash:

  qemu-system-x86_64 -object iothread,id=iothread0 -monitor stdio -display none
  QEMU 2.10.50 monitor - type 'help' for more information
  (qemu) quit
  qemu: qemu_thread_join: No such process
  Aborted (core dumped)

Reported-by: Christian Borntraeger <address@hidden>
Signed-off-by: Eduardo Habkost <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: d4083f50e021f52addd02c9f83465937f8486556
      
https://github.com/qemu/qemu/commit/d4083f50e021f52addd02c9f83465937f8486556
  Author: Alexey Perevalov <address@hidden>
  Date:   2017-09-29 (Fri, 29 Sep 2017)

  Changed paths:
    M include/standard-headers/asm-x86/hyperv.h
    M include/standard-headers/linux/pci_regs.h
    M include/standard-headers/linux/virtio_ring.h
    M linux-headers/asm-s390/kvm.h
    M linux-headers/linux/kvm.h
    M linux-headers/linux/userfaultfd.h

  Log Message:
  -----------
  linux-headers: sync against v4.14-rc1

Signed-off-by: Alexey Perevalov <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: 62dd4edaaf859b60f74a51f2a526d4d3d85d0248
      
https://github.com/qemu/qemu/commit/62dd4edaaf859b60f74a51f2a526d4d3d85d0248
  Author: Greg Kurz <address@hidden>
  Date:   2017-10-02 (Mon, 02 Oct 2017)

  Changed paths:
    M accel/kvm/kvm-all.c
    M accel/stubs/kvm-stub.c
    M include/sysemu/kvm.h

  Log Message:
  -----------
  kvm: check KVM_CAP_SYNC_MMU with kvm_vm_check_extension()

On a server-class ppc host, this capability depends on the KVM type,
ie, HV or PR. If both KVM are present in the kernel, we will always
get the HV specific value, even if we explicitely requested PR on
the command line.

This can have an impact if we're using hugepages or a balloon device.

Since we've already created the VM at the time any user calls
kvm_has_sync_mmu(), switching to kvm_vm_check_extension() is
enough to fix any potential issue.

It is okay for the other archs that also implement KVM_CAP_SYNC_MMU,
ie, mips, s390, x86 and arm, because they don't depend on the VM being
created or not.

While here, let's cache the state of this extension in a bool variable,
since it has several users in the code, as suggested by Thomas Huth.

Signed-off-by: Greg Kurz <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: David Gibson <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: 11748ba72ea4fc03e975aa5f5d876b5b0902e356
      
https://github.com/qemu/qemu/commit/11748ba72ea4fc03e975aa5f5d876b5b0902e356
  Author: Greg Kurz <address@hidden>
  Date:   2017-10-02 (Mon, 02 Oct 2017)

  Changed paths:
    M accel/kvm/kvm-all.c

  Log Message:
  -----------
  kvm: check KVM_CAP_NR_VCPUS with kvm_vm_check_extension()

On a modern server-class ppc host with the following CPU topology:

Architecture:          ppc64le
Byte Order:            Little Endian
CPU(s):                32
On-line CPU(s) list:   0,8,16,24
Off-line CPU(s) list:  1-7,9-15,17-23,25-31
Thread(s) per core:    1

If both KVM PR and KVM HV loaded and we pass:
   -machine pseries,accel=kvm,kvm-type=PR -smp 8

We expect QEMU to warn that this exceeds the number of online CPUs:

Warning: Number of SMP cpus requested (8) exceeds the recommended
 cpus supported by KVM (4)
Warning: Number of hotpluggable cpus requested (8) exceeds the
 recommended cpus supported by KVM (4)

but nothing is printed...

This happens because on ppc the KVM_CAP_NR_VCPUS capability is VM
specific  ndreally depends on the KVM type, but we currently use it
as a global capability. And KVM returns a fallback value based on
KVM HV being present. Maybe KVM on POWER shouldn't presume anything
as long as it doesn't have a VM, but in all cases, we should call
KVM_CREATE_VM first and use KVM_CAP_NR_VCPUS as a VM capability.

This patch hence changes kvm_recommended_vcpus() accordingly and
moves the sanity checking of smp_cpus after the VM creation.

It is okay for the other archs that also implement KVM_CAP_NR_VCPUS,
ie, mips, s390, x86 and arm, because they don't depend on the VM
being created or not.

Signed-off-by: Greg Kurz <address@hidden>
Reviewed-by: David Gibson <address@hidden>
Reviewed-by: Thomas Huth <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: 346b1215b1e9f7cc6d8fe9fb6f3c2778b890afb6
      
https://github.com/qemu/qemu/commit/346b1215b1e9f7cc6d8fe9fb6f3c2778b890afb6
  Author: Jim Somerville <address@hidden>
  Date:   2017-10-02 (Mon, 02 Oct 2017)

  Changed paths:
    M hw/i386/kvm/clock.c

  Log Message:
  -----------
  kvmclock: use the updated system_timer_msr

Fixes e2b6c17 (kvmclock: update system_time_msr address forcibly)
which makes a call to get the latest value of the address
stored in system_timer_msr, but then uses the old address anyway.

Signed-off-by: Jim Somerville <address@hidden>
Message-Id: <address@hidden>
Cc: address@hidden
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: d147f7e815f97cb477e223586bcb80c316ae10ea
      
https://github.com/qemu/qemu/commit/d147f7e815f97cb477e223586bcb80c316ae10ea
  Author: Peter Maydell <address@hidden>
  Date:   2017-10-03 (Tue, 03 Oct 2017)

  Changed paths:
    M .gitignore
    M accel/kvm/kvm-all.c
    M accel/stubs/kvm-stub.c
    M hw/i386/kvm/clock.c
    M include/standard-headers/asm-x86/hyperv.h
    M include/standard-headers/linux/pci_regs.h
    M include/standard-headers/linux/virtio_ring.h
    M include/sysemu/kvm.h
    M iothread.c
    M linux-headers/asm-s390/kvm.h
    M linux-headers/linux/kvm.h
    M linux-headers/linux/userfaultfd.h

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging

* iothread bugfix (Eduardo)
* Linux headers sync (Dave)
* .gitignore fix (Eric)
* KVM capability check fixes (Greg)
* kvmclock fix (Jim)

# gpg: Signature made Mon 02 Oct 2017 14:31:09 BST
# gpg:                using RSA key 0xBFFBD25F78C7AE83
# gpg: Good signature from "Paolo Bonzini <address@hidden>"
# gpg:                 aka "Paolo Bonzini <address@hidden>"
# 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:
  kvmclock: use the updated system_timer_msr
  kvm: check KVM_CAP_NR_VCPUS with kvm_vm_check_extension()
  kvm: check KVM_CAP_SYNC_MMU with kvm_vm_check_extension()
  linux-headers: sync against v4.14-rc1
  iothread: Make iothread_stop() idempotent
  scsi: Ignore executable for in-tree builds

Signed-off-by: Peter Maydell <address@hidden>


Compare: https://github.com/qemu/qemu/compare/0b7fe5aed738...d147f7e815f9

reply via email to

[Prev in Thread] Current Thread [Next in Thread]