[Qemu-commits] [qemu/qemu] 346645: qemu-common: add VEC_OR macro

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 34664507c7f038842f20a2c787915680b1fabba2
      
https://github.com/qemu/qemu/commit/34664507c7f038842f20a2c787915680b1fabba2
  Author: Artyom Tarasenko <address@hidden>
  Date:   2015-06-26 (Fri, 26 Jun 2015)

  Changed paths:
    M include/qemu-common.h

  Log Message:
  -----------
  qemu-common: add VEC_OR macro

Intel C Compiler version 15.0.3.187 Build 20150407 doesn't support
'|' function for non floating-point simd operands.

Define VEC_OR macro which uses _mm_or_si128 supported
both in icc and gcc on x86 platform.

Signed-off-by: Artyom Tarasenko <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: 27e7755bea57c66097000f7612271ceefcbeb4a4
      
https://github.com/qemu/qemu/commit/27e7755bea57c66097000f7612271ceefcbeb4a4
  Author: Artyom Tarasenko <address@hidden>
  Date:   2015-06-26 (Fri, 26 Jun 2015)

  Changed paths:
    M util/cutils.c

  Log Message:
  -----------
  cutils: allow compilation with icc

Use VEC_OR macro for operations on VECTYPE operands

Signed-off-by: Artyom Tarasenko <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: 94beb661bd90bcb477eed6d3b07aced988c40163
      
https://github.com/qemu/qemu/commit/94beb661bd90bcb477eed6d3b07aced988c40163
  Author: Peter Crosthwaite <address@hidden>
  Date:   2015-06-26 (Fri, 26 Jun 2015)

  Changed paths:
    M memory_mapping.c

  Log Message:
  -----------
  memory_mapping: Rework cpu related includes

This makes it more consistent with all other core code files, which
either just rely on qemu-common.h inclusion or precede cpu.h with
qemu-common.h.

cpu-all.h should not be included in addition to cpu.h. Remove it.

Signed-off-by: Peter Crosthwaite <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: 6e0b07306d1793e8402dd218d2e38a7377b5fc27
      
https://github.com/qemu/qemu/commit/6e0b07306d1793e8402dd218d2e38a7377b5fc27
  Author: Peter Crosthwaite <address@hidden>
  Date:   2015-06-26 (Fri, 26 Jun 2015)

  Changed paths:
    M include/exec/cpu-defs.h
    M tcg/tcg.h

  Log Message:
  -----------
  cpu-defs: Move CPU_TEMP_BUF_NLONGS to tcg

The usages of this define are pure TCG and there is no architecture
specific variation of the value. Localise it to the TCG engine to
remove another architecture agnostic piece from cpu-defs.h.

This follows on from a28177820a868eafda8fab007561cc19f41941f4 where
temp_buf was moved out of the CPU_COMMON obsoleting the need for
the super early definition.

Reviewed-by: Richard Henderson <address@hidden>
Signed-off-by: Peter Crosthwaite <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: 9e0dc48c9f05505b53cb28f860456a0648e56ddf
      
https://github.com/qemu/qemu/commit/9e0dc48c9f05505b53cb28f860456a0648e56ddf
  Author: Peter Crosthwaite <address@hidden>
  Date:   2015-06-26 (Fri, 26 Jun 2015)

  Changed paths:
    M include/exec/cpu-all.h
    M include/exec/cpu-defs.h

  Log Message:
  -----------
  include/exec: Move standard exceptions to cpu-all.h

These exception indicies are generic and don't have any reliance on the
per-arch cpu.h defs. Move them to cpu-all.h so they can be used by core
code that does not have access to cpu-defs.h.

Reviewed-by: Richard Henderson <address@hidden>
Signed-off-by: Peter Crosthwaite <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: e1b89321bafea9fb33d87852fc91fee579d17dfe
      
https://github.com/qemu/qemu/commit/e1b89321bafea9fb33d87852fc91fee579d17dfe
  Author: Peter Crosthwaite <address@hidden>
  Date:   2015-06-26 (Fri, 26 Jun 2015)

  Changed paths:
    M cpu-exec.c
    M include/exec/exec-all.h
    A include/exec/tb-hash.h
    M translate-all.c

  Log Message:
  -----------
  include/exec: Move tb hash functions out

This is one of very few things in exec-all with a genuine CPU
architecture dependency. Move these hashing helpers to a new
header to trim exec-all.h down to a near architecture-agnostic
header.

The defs are only used by cpu-exec and translate-all which are both
arch-obj's so the new tb-hash.h has no core code usage.

Reviewed-by: Richard Henderson <address@hidden>
Signed-off-by: Peter Crosthwaite <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: 41da4bd6420afd1209c408974920f63ff9c658e1
      
https://github.com/qemu/qemu/commit/41da4bd6420afd1209c408974920f63ff9c658e1
  Author: Peter Crosthwaite <address@hidden>
  Date:   2015-06-26 (Fri, 26 Jun 2015)

  Changed paths:
    M include/exec/cpu-defs.h
    M include/exec/tb-hash.h

  Log Message:
  -----------
  cpu-defs: Move out TB_JMP defines

These are not Architecture specific in any way so move them out of
cpu-defs.h. tb-hash.h is an appropriate place as a leading user and
their strong relationship to TB hashing and caching.

Reviewed-by: Richard Henderson <address@hidden>
Signed-off-by: Peter Crosthwaite <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: bdf026317daa3b9dfa281f29e96fbb6fd48394c8
      
https://github.com/qemu/qemu/commit/bdf026317daa3b9dfa281f29e96fbb6fd48394c8
  Author: 马文霜 <address@hidden>
  Date:   2015-07-01 (Wed, 01 Jul 2015)

  Changed paths:
    M kvm-all.c

  Log Message:
  -----------
  Fix irq route entries exceeding KVM_MAX_IRQ_ROUTES

Last month, we experienced several guests crash(6cores-8cores), qemu logs
display the following messages:

qemu-system-x86_64: /build/qemu-2.1.2/kvm-all.c:976:
kvm_irqchip_commit_routes: Assertion `ret == 0' failed.

After analysis and verification, we can confirm it's irq-balance
daemon(in guest) leads to the assertion failure. Start a 8 core guest with
two disks, execute the following scripts will reproduce the BUG quickly:

irq_affinity.sh
========================================================================

vda_irq_num=25
vdb_irq_num=27
while [ 1 ]
do
    for irq in {1,2,4,8,10,20,40,80}
  do
      echo $irq > /proc/irq/$vda_irq_num/smp_affinity
      echo $irq > /proc/irq/$vdb_irq_num/smp_affinity
      dd if=/dev/vda of=/dev/zero bs=4K count=100 iflag=direct
      dd if=/dev/vdb of=/dev/zero bs=4K count=100 iflag=direct
  done
done
========================================================================

QEMU setup static irq route entries in kvm_pc_setup_irq_routing(), PIC and
IOAPIC share the first 15 GSI numbers, take up 23 GSI numbers, but take up
38 irq route entries. When change irq smp_affinity in guest, a dynamic route
entry may be setup, the current logic is: if allocate GSI number succeeds,
a new route entry can be added. The available dynamic GSI numbers is
1021(KVM_MAX_IRQ_ROUTES-23), but available irq route entries is only
986(KVM_MAX_IRQ_ROUTES-38), GSI numbers greater than route entries.
irq-balance's behavior will eventually leads to total irq route entries
exceed KVM_MAX_IRQ_ROUTES, ioctl(KVM_SET_GSI_ROUTING) fail and
kvm_irqchip_commit_routes() trigger assertion failure.

This patch fix the BUG.

Signed-off-by: Wenshuang Ma <address@hidden>
Cc: address@hidden
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: 2e7f7a3c86f884a77296a137b7c730a4d580c5c9
      
https://github.com/qemu/qemu/commit/2e7f7a3c86f884a77296a137b7c730a4d580c5c9
  Author: Paolo Bonzini <address@hidden>
  Date:   2015-07-01 (Wed, 01 Jul 2015)

  Changed paths:
    M cpus.c

  Log Message:
  -----------
  main-loop: use qemu_mutex_lock_iothread consistently

The next patch will require the BQL to be always taken with
qemu_mutex_lock_iothread(), while right now this isn't the case.

Outside TCG mode this is not a problem.  In TCG mode, we need to be
careful and avoid the "prod out of compiled code" step if already
in a VCPU thread.  This is easily done with a check on current_cpu,
i.e. qemu_in_vcpu_thread().

Hopefully, multithreaded TCG will get rid of the whole logic to kick
VCPUs whenever an I/O event occurs!

Cc: Frederic Konrad <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: afbe70535ff1a8a7a32910cc15ebecc0ba92e7da
      
https://github.com/qemu/qemu/commit/afbe70535ff1a8a7a32910cc15ebecc0ba92e7da
  Author: Paolo Bonzini <address@hidden>
  Date:   2015-07-01 (Wed, 01 Jul 2015)

  Changed paths:
    M cpus.c
    M include/qemu/main-loop.h
    M stubs/iothread-lock.c

  Log Message:
  -----------
  main-loop: introduce qemu_mutex_iothread_locked

This function will be used to avoid recursive locking of the iothread lock
whenever address_space_rw/ld*/st* are called with the BQL held, which is
almost always the case.

Tracking whether the iothread is owned is very cheap (just use a TLS
variable) but requires some care because now the lock must always be
taken with qemu_mutex_lock_iothread().  Previously this wasn't the case.
Outside TCG mode this is not a problem.  In TCG mode, we need to be
careful and avoid the "prod out of compiled code" step if already
in a VCPU thread.  This is easily done with a check on current_cpu,
i.e. qemu_in_vcpu_thread().

Hopefully, multithreaded TCG will get rid of the whole logic to kick
VCPUs whenever an I/O event occurs!

Cc: Frederic Konrad <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Fam Zheng <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: 196ea13104f802c508e57180b2a0d2b3418989a3
      
https://github.com/qemu/qemu/commit/196ea13104f802c508e57180b2a0d2b3418989a3
  Author: Jan Kiszka <address@hidden>
  Date:   2015-07-01 (Wed, 01 Jul 2015)

  Changed paths:
    M include/exec/memory.h
    M memory.c

  Log Message:
  -----------
  memory: Add global-locking property to memory regions

This introduces the memory region property "global_locking". It is true
by default. By setting it to false, a device model can request BQL-free
dispatching of region accesses to its r/w handlers. The actual BQL
break-up will be provided in a separate patch.

Signed-off-by: Jan Kiszka <address@hidden>
Cc: Frederic Konrad <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Message-Id: <address@hidden>


  Commit: 125b3806668106667dd2ae049593852859e12b63
      
https://github.com/qemu/qemu/commit/125b3806668106667dd2ae049593852859e12b63
  Author: Paolo Bonzini <address@hidden>
  Date:   2015-07-01 (Wed, 01 Jul 2015)

  Changed paths:
    M exec.c
    M memory.c

  Log Message:
  -----------
  exec: pull qemu_flush_coalesced_mmio_buffer() into address_space_rw/ld*/st*

As memory_region_read/write_accessor will now be run also without BQL held,
we need to move coalesced MMIO flushing earlier in the dispatch process.

Cc: Frederic Konrad <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: 4840f10eff37eebc609fcc933ab985dc66df95c6
      
https://github.com/qemu/qemu/commit/4840f10eff37eebc609fcc933ab985dc66df95c6
  Author: Jan Kiszka <address@hidden>
  Date:   2015-07-01 (Wed, 01 Jul 2015)

  Changed paths:
    M exec.c

  Log Message:
  -----------
  memory: let address_space_rw/ld*/st* run outside the BQL

The MMIO case is further broken up in two cases: if the caller does not
hold the BQL on invocation, the unlocked one takes or avoids BQL depending
on the locking strategy of the target memory region and its coalesced
MMIO handling.  In this case, the caller should not hold _any_ lock
(a friendly suggestion which is disregarded by virtio-scsi-dataplane).

Signed-off-by: Jan Kiszka <address@hidden>
Cc: Frederic Konrad <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: 4b8523ee896750c37b4fa224a40d34703cbdf4c6
      
https://github.com/qemu/qemu/commit/4b8523ee896750c37b4fa224a40d34703cbdf4c6
  Author: Jan Kiszka <address@hidden>
  Date:   2015-07-01 (Wed, 01 Jul 2015)

  Changed paths:
    M kvm-all.c
    M target-i386/kvm.c
    M target-mips/kvm.c
    M target-ppc/kvm.c
    M target-s390x/kvm.c

  Log Message:
  -----------
  kvm: First step to push iothread lock out of inner run loop

This opens the path to get rid of the iothread lock on vmexits in KVM
mode. On x86, the in-kernel irqchips has to be used because we otherwise
need to synchronize APIC and other per-cpu state accesses that could be
changed concurrently.

Regarding pre/post-run callbacks, s390x and ARM should be fine without
specific locking as the callbacks are empty. MIPS and POWER require
locking for the pre-run callback.

For the handle_exit callback, it is non-empty in x86, POWER and s390.
Some POWER cases could do without the locking, but it is left in
place for now.

Signed-off-by: Jan Kiszka <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Message-Id: <address@hidden>


  Commit: 80b7d2efb63c225797345c152cdd3392b9fe7b72
      
https://github.com/qemu/qemu/commit/80b7d2efb63c225797345c152cdd3392b9fe7b72
  Author: Jan Kiszka <address@hidden>
  Date:   2015-07-01 (Wed, 01 Jul 2015)

  Changed paths:
    M kvm-all.c

  Log Message:
  -----------
  kvm: Switch to unlocked PIO

Do not take the BQL before dispatching PIO requests of KVM VCPUs.
Instead, address_space_rw will do it if necessary. This enables
completely BQL-free PIO handling in KVM mode for upcoming devices with
fine-grained locking.

Signed-off-by: Jan Kiszka <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Message-Id: <address@hidden>


  Commit: 7070e085d490c396f9237c8f10bf8b6e69cd0066
      
https://github.com/qemu/qemu/commit/7070e085d490c396f9237c8f10bf8b6e69cd0066
  Author: Paolo Bonzini <address@hidden>
  Date:   2015-07-01 (Wed, 01 Jul 2015)

  Changed paths:
    M hw/acpi/core.c

  Log Message:
  -----------
  acpi: mark PMTIMER as unlocked

Accessing QEMU_CLOCK_VIRTUAL is thread-safe.

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


  Commit: de7ea885c5394c1fba7443cbf33bd2745d32e6c2
      
https://github.com/qemu/qemu/commit/de7ea885c5394c1fba7443cbf33bd2745d32e6c2
  Author: Paolo Bonzini <address@hidden>
  Date:   2015-07-01 (Wed, 01 Jul 2015)

  Changed paths:
    M kvm-all.c

  Log Message:
  -----------
  kvm: Switch to unlocked MMIO

Do not take the BQL before dispatching MMIO requests of KVM VCPUs.
Instead, address_space_rw will do it if necessary. This enables completely
BQL-free MMIO handling in KVM mode for upcoming devices with fine-grained
locking.

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


  Commit: fba0a593b2809ecdda68650952cf3d3332ac1990
      
https://github.com/qemu/qemu/commit/fba0a593b2809ecdda68650952cf3d3332ac1990
  Author: Peter Maydell <address@hidden>
  Date:   2015-07-06 (Mon, 06 Jul 2015)

  Changed paths:
    M include/exec/cpu-common.h
    M include/exec/memory.h
    M include/hw/arm/arm.h
    M include/qemu-common.h
    A include/qemu/fprintf-fn.h
    M target-s390x/mmu_helper.c

  Log Message:
  -----------
  Stop including qemu-common.h in memory.h

Including qemu-common.h from other header files is generally a bad
idea, because it means it's very easy to end up with a circular
dependency. For instance, if we wanted to include memory.h from
qom/cpu.h we'd end up with this loop:
 memory.h -> qemu-common.h -> cpu.h -> cpu-qom.h -> qom/cpu.h -> memory.h

Remove the include from memory.h. This requires us to fix up a few
other files which were inadvertently getting declarations indirectly
through memory.h.

The biggest change is splitting the fprintf_function typedef out
into its own header so other headers can get at it without having
to include qemu-common.h.

Signed-off-by: Peter Maydell <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: b242e0e0e2969c044a318e56f7988bbd84de1f63
      
https://github.com/qemu/qemu/commit/b242e0e0e2969c044a318e56f7988bbd84de1f63
  Author: Paolo Bonzini <address@hidden>
  Date:   2015-07-06 (Mon, 06 Jul 2015)

  Changed paths:
    M exec.c

  Log Message:
  -----------
  exec: skip MMIO regions correctly in cpu_physical_memory_write_rom_internal

Loading the BIOS in the mac99 machine is interesting, because there is a
PROM in the middle of the BIOS region (from 16K to 32K).  Before memory
region accesses were clamped, when QEMU was asked to load a BIOS from
0xfff00000 to 0xffffffff it would put even those 16K from the BIOS file
into the region.  This is weird because those 16K were not actually
visible between 0xfff04000 and 0xfff07fff.  However, it worked.

After clamping was added, this also worked.  In this case, the
cpu_physical_memory_write_rom_internal function split the write in
three parts: the first 16K were copied, the PROM area (second 16K) were
ignored, then the rest was copied.

Problems then started with commit 965eb2f (exec: do not clamp accesses
to MMIO regions, 2015-06-17).  Clamping accesses is not done for MMIO
regions because they can overlap wildly, and MMIO registers can be
expected to perform full-width accesses based only on their address
(with no respect for adjacent registers that could decode to completely
different MemoryRegions).  However, this lack of clamping also applied
to the PROM area!  cpu_physical_memory_write_rom_internal thus failed
to copy the third range above, i.e. only copied the first 16K of the BIOS.

In effect, address_space_translate is expecting _something else_ to do
the clamping for MMIO regions if the incoming length is large.  This
"something else" is memory_access_size in the case of address_space_rw,
so use the same logic in cpu_physical_memory_write_rom_internal.

Reported-by: Alexander Graf <address@hidden>
Reviewed-by: Laurent Vivier <address@hidden>
Tested-by: Laurent Vivier <address@hidden>
Fixes: 965eb2f
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: 7edd8e4660beb301d527257f8e04ebec0f841cb0
      
https://github.com/qemu/qemu/commit/7edd8e4660beb301d527257f8e04ebec0f841cb0
  Author: Peter Maydell <address@hidden>
  Date:   2015-07-06 (Mon, 06 Jul 2015)

  Changed paths:
    M cpu-exec.c
    M cpus.c
    M exec.c
    M hw/acpi/core.c
    M include/exec/cpu-all.h
    M include/exec/cpu-common.h
    M include/exec/cpu-defs.h
    M include/exec/exec-all.h
    M include/exec/memory.h
    A include/exec/tb-hash.h
    M include/hw/arm/arm.h
    M include/qemu-common.h
    A include/qemu/fprintf-fn.h
    M include/qemu/main-loop.h
    M kvm-all.c
    M memory.c
    M memory_mapping.c
    M stubs/iothread-lock.c
    M target-i386/kvm.c
    M target-mips/kvm.c
    M target-ppc/kvm.c
    M target-s390x/kvm.c
    M target-s390x/mmu_helper.c
    M tcg/tcg.h
    M translate-all.c
    M util/cutils.c

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

* more of Peter Crosthwaite's multiarch preparation patches
* unlocked MMIO support in KVM
* support for compilation with ICC

# gpg: Signature made Mon Jul  6 13:59:20 2015 BST using RSA key ID 78C7AE83
# gpg: Good signature from "Paolo Bonzini <address@hidden>"
# gpg:                 aka "Paolo Bonzini <address@hidden>"
# 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:
  exec: skip MMIO regions correctly in cpu_physical_memory_write_rom_internal
  Stop including qemu-common.h in memory.h
  kvm: Switch to unlocked MMIO
  acpi: mark PMTIMER as unlocked
  kvm: Switch to unlocked PIO
  kvm: First step to push iothread lock out of inner run loop
  memory: let address_space_rw/ld*/st* run outside the BQL
  exec: pull qemu_flush_coalesced_mmio_buffer() into address_space_rw/ld*/st*
  memory: Add global-locking property to memory regions
  main-loop: introduce qemu_mutex_iothread_locked
  main-loop: use qemu_mutex_lock_iothread consistently
  Fix irq route entries exceeding KVM_MAX_IRQ_ROUTES
  cpu-defs: Move out TB_JMP defines
  include/exec: Move tb hash functions out
  include/exec: Move standard exceptions to cpu-all.h
  cpu-defs: Move CPU_TEMP_BUF_NLONGS to tcg
  memory_mapping: Rework cpu related includes
  cutils: allow compilation with icc
  qemu-common: add VEC_OR macro

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


Compare: https://github.com/qemu/qemu/compare/3fa18bc9a55e...7edd8e4660be