Per supported platforms doc[1], the various min glib on relevant distros is:

  RHEL-7: 2.50.3
  Debian (Stretch): 2.50.3
  Debian (Jessie): 2.42.1
  OpenBSD (Ports): 2.54.3
  FreeBSD (Ports): 2.50.3
  OpenSUSE Leap 15: 2.54.3
  SLE12-SP2: 2.48.2
  Ubuntu (Xenial): 2.48.0
  macOS (Homebrew): 2.56.0

This suggests that a minimum glib of 2.42 is a reasonable target.

The GLibC compile farm, however, uses Ubuntu 14.04 (Trusty) which only
has glib 2.40.0, and this is needed for testing during merge. Thus an
exception is made to the documented platform support policy to allow for
all three current LTS releases to be supported.

Docker jobs that not longer satisfy this new min version are removed.

[1] https://qemu.weilnetz.de/doc/qemu-doc.html#Supported-build-platformsReviewed-by: NThomas Huth <thuth@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

strchrnul is a GNU extension and thus unavailable on a number of targets.
In the review for a commit removing strchrnul from 9p, I was asked to
create a qemu_strchrnul helper to factor out this functionality.
Do so, and use it in a number of other places in the code base that inlined
the replacement pattern in a place where strchrnul could be used.
Signed-off-by: NKeno Fischer <keno@juliacomputing.com>
Acked-by: NGreg Kurz <groug@kaod.org>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NGreg Kurz <groug@kaod.org>

Reviewed-by: NEmilio G. Cota <cota@braap.org>
Signed-off-by: NPeter Xu <peterx@redhat.com>
Message-Id: <20180425025459.5258-5-peterx@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

We have had some tracing tools for mutex but it's not easy to use them
for e.g. dead locks.  Let's provide "--enable-debug-mutex" parameter
when configure to allow QemuMutex to store the last owner that took
specific lock.  It will be easy to use this tool to debug deadlocks
since we can directly know who took the lock then as long as we can have
a debugger attached to the process.
Reviewed-by: NEmilio G. Cota <cota@braap.org>
Signed-off-by: NPeter Xu <peterx@redhat.com>
Message-Id: <20180425025459.5258-4-peterx@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

We can build tests for the host system with the compiler that we have
selected.
Signed-off-by: NAlex Bennée <alex.bennee@linaro.org>
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>

As an individual compiler may be able to support several targets with
the appropriate flags we need to expose this to the user as well.
Signed-off-by: NAlex Bennée <alex.bennee@linaro.org>
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>

Also dont assume x86_64 compiler can build i386 binaries.
Signed-off-by: NAlex Bennée <alex.bennee@linaro.org>
Tested-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>

This allows us to specify cross compilers for our guests. This is
useful for building test images/programs. Currently we re-run the
compile test for each target. I couldn't think of a way to cache the
value for a given arch without getting messier configure code.

The cross compiler for the guest is visible to each target as
CROSS_CC_GUEST in config-target.mak. This is quoted to handle the case
of --cc="ccache gcc".
Signed-off-by: NAlex Bennée <alex.bennee@linaro.org>
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>

Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Message-id: 20180525153609.13187-1-marcandre.lureau@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Currently to run Avocado acceptance tests in an out-of-tree
build directory, we need to use the full path to the test:

  build_dir$ avocado run /full/path/to/sources/qemu/tests/acceptance/boot_linux_console.py

This patch adds a symlink in the build tree to simplify the
tests invocation, allowing the same command than in in-tree builds:

  build_dir$ avocado run tests/acceptance/boot_linux_console.py
Signed-off-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20180612173437.14462-1-f4bug@amsat.org>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>

All of the supported build platforms documented in qemu-doc.texi
should already support Python 2.7.

Removing support for Python 2.6 will allow us to remove some
compatibility modules we carry in the QEMU tree:

* scripts/argparse.py
* scripts/ordereddict.py

Python 2.6 is also not receiving bug fixes upstream and is not
supported by pylint, which makes it harder to keep the code
compatible with both Python 2 and Python 3.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Message-Id: <20180608143026.20167-1-ehabkost@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Reviewed-by: NCleber Rosa <crosa@redhat.com>
Reviewed-by: NJohn Snow <jsnow@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>

To be more accurate on its purpose and make code that looks for a certain
target out of this variable more readable.
Signed-off-by: NFam Zheng <famz@redhat.com>
Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
Tested-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Signed-off-by: NAlex Bennée <alex.bennee@linaro.org>

This tests for a working docker installation without sudo and sets up
config-host.mak accordingly. This will be useful from cross compiling
things in the future.
Signed-off-by: NAlex Bennée <alex.bennee@linaro.org>
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>

With copy_file_range(2), we can implement the bdrv_co_copy_range
semantics.
Signed-off-by: NFam Zheng <famz@redhat.com>
Message-id: 20180601092648.24614-6-famz@redhat.com
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>

We're currently linking against import libraries of the WHP DLLs.

By dynamically loading the libraries, we ensure that QEMU will work
on previous Windows versions, where the WHP DLLs will be missing
(assuming that WHP is not requested).

Also, we're simplifying the build process, as we no longer require
the import libraries.
Signed-off-by: NAlessandro Pilotti <apilotti@cloudbasesolutions.com>
Signed-off-by: NJustin Terry (VM) <juterry@microsoft.com>
Signed-off-by: NLucian Petrut <lpetrut@cloudbasesolutions.com>
Message-Id: <1526405722-10887-2-git-send-email-lpetrut@cloudbasesolutions.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Xen 4.11 has a new API to directly map guest resources. Among the resources
that can be mapped using this API are ioreq pages.

This patch modifies QEMU to attempt to use the new API should it exist,
falling back to the previous mechanism if it is unavailable.
Signed-off-by: NPaul Durrant <paul.durrant@citrix.com>
Reviewed-by: NAnthony PERARD <anthony.perard@citrix.com>
Signed-off-by: NStefano Stabellini <sstabellini@kernel.org>

Setup MicroBlaze builds for 64bit addressing.
No functional change since the translator does not yet
emit 64bit addresses.
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Signed-off-by: NEdgar E. Iglesias <edgar.iglesias@xilinx.com>

Signed-off-by: NAnthony PERARD <anthony.perard@citrix.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NStefano Stabellini <sstabellini@kernel.org>

The configure script outputs "yes" regardless which libfdt is used:

  ./configure
  [...]
  fdt support       yes

Sometimes you can have both system and local git version available,
change the configure script to display which library got selected:

  debian8$ dpkg-query --showformat='${Version}\n' --show libfdt-dev
  1.4.0+dfsg-1

  debian8$ ./configure
  [...]
  fdt support       git
Signed-off-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20180415230522.24404-3-f4bug@amsat.org>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

QEMU requires libfdt version >= 1.4.2.
If the host has an older libfdt installed, the configure script will use
a (git cloned) local version.

Example with Debian 8:
    $ dpkg-query --showformat='${Version}\n' --show libfdt-dev
    1.4.0+dfsg-1
    $ ./configure
    [...]
    fdt support       yes          # from git submodule 'dtc'

If this case occurs, the linker will have 2 different libfdt available in
the library search path. The default behavior is to search the system path
first, then the local path.

Even if the configure script noticed the libfdt is too old and clone a more
recent locally, when linking the system library is selected first, and the
link process eventually fails:

      LINK    mips64el-softmmu/qemu-system-mips64el
    ../hw/core/loader-fit.o: In function `load_fit':
    /root/src/github.com/philmd/qemu/hw/core/loader-fit.c:278: undefined reference to `fdt_first_subnode'
    /root/src/github.com/philmd/qemu/hw/core/loader-fit.c:286: undefined reference to `fdt_next_subnode'
    /root/src/github.com/philmd/qemu/hw/core/loader-fit.c:277: undefined reference to `fdt_first_subnode'
    collect2: error: ld returned 1 exit status
    Makefile:201: recipe for target 'qemu-system-mips64el' failed
    make[1]: *** [qemu-system-mips64el] Error 1

QEMU already uses a kludge to enforce local CFLAGS before system ones for
libpixman and libfdt, add a similar kludge for the LDFLAGS to enforce using
the local libfdt.
Signed-off-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20180415230522.24404-2-f4bug@amsat.org>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NThomas Huth <thuth@redhat.com>

When compiling on a machine without libfdt installed the configure script
should try to get libfdt from the git or should die because otherwise
CONFIG_LIBFDT is not set and the build process end in an error in the link
phase.. eg:

hw/riscv/virt.o: In function `riscv_virt_board_init':
qemu/src/hw/riscv/virt.c:317: undefined reference to `qemu_fdt_setprop_cell'
qemu/src/hw/riscv/virt.c:319: undefined reference to `qemu_fdt_setprop_cell'
qemu/src/hw/riscv/virt.c:345: undefined reference to `qemu_fdt_dumpdtb'
collect2: error: ld returned 1 exit status
make[1]: *** [qemu-system-riscv64] Error 1
make: *** [subdir-riscv64-softmmu] Error 2

Cc: qemu-stable@nongnu.org
Reviewed-by: NBastian Koppelmann <kbastian@mail.uni-paderborn.de>
Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: NMichael Clark <mjc@sifive.com>
Signed-off-by: NKONRAD Frederic <frederic.konrad@adacore.com>
Signed-off-by: NMichael Clark <mjc@sifive.com>

Message-Id: <1525360636-18229-4-git-send-email-frederic.konrad@adacore.com>

Extend the list of recognized, but ignored options from rpms %configure
macro. This fixes build on hosts running SUSE Linux.

Cc: qemu-stable@nongnu.org
Signed-off-by: NOlaf Hering <olaf@aepfle.de>
Message-Id: <20180418075045.27393-1-olaf@aepfle.de>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

When trying to build with latest libcacard-2.5.1, I hit the
following error:

In file included from hw/usb/ccid-card-passthru.c:12:0:
/usr/include/cacard/vscard_common.h:26:2: error: #warning "Only <libcacard.h> can be included directly" [-Werror=cpp]
 #warning "Only <libcacard.h> can be included directly"

While it was fixed in libcacard upstream (so that individual
files can be included directly), it doesn't make much sense.
Let's switch to including the main libcacard.h and also require
at least libcacard-2.5.1 which introduced it. It's available
since late 2015.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 3c36db1dc0702763ebb7966cc27428ed67d43804.1522751624.git.mprivozn@redhat.com

[ kraxel: fix include path ]
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

This makes it much easier to find a particular thing in config.log.

We have to use the ${BASH_LINENO[*]} syntax which is a syntax error in
other shells, so test what shell we are running and use eval.

The extra output is only printed if configure is run with bash.  On
systems where /bin/sh is not bash, it is necessary to say bash
./configure to get the extra debug info in the log.
Suggested-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NIan Jackson <Ian.Jackson@eu.citrix.com>
CC: Kent R. Spillner <kspillner@acm.org>
CC: Janosch Frank <frankja@linux.vnet.ibm.com>
CC: Thomas Huth <thuth@redhat.com>
CC: Peter Maydell <peter.maydell@linaro.org>
CC: Paolo Bonzini <pbonzini@redhat.com>
Tested-by: NThomas Huth <thuth@redhat.com>

Xen unstable (to be in 4.11) has two new dmops, relocate_memory and
pin_memory_cacheattr. Use these to set up the VGA memory, replacing the
previous calls to libxc. This allows the VGA console to work properly
when QEMU is running restricted (-xen-domid-restrict).

Wrapper functions are provided to allow QEMU to work with older versions
of Xen.

Tweak the error handling while making this change:
* Report pin_memory_cacheattr errors.
* Report errors even when DEBUG_HVM is not set. This is useful for
trying to understand why VGA is not working, since otherwise it just
fails silently.
* Fix the return values when an error occurs. The functions now
consistently return -1 and set errno.

CC: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: NRoss Lagerwall <ross.lagerwall@citrix.com>
Reviewed-by: NIan Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: NIan Jackson <ian.jackson@eu.citrix.com>
Acked-by: NAnthony PERARD <anthony.perard@citrix.com>

Xen libraries in 4.10 include a new xentoolcore library.  This
contains the xentoolcore_restrict_all function which we are about to
want to use.
Signed-off-by: NIan Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: NStefano Stabellini <sstabellini@kernel.org>

SDL has the same problem as GTK that we might get warnings on SDL ABI
version even if SDL is disabled.  Fix that by only probing SDL if SDL is
enabled.  Also this should let configure be a little bit faster since we
don't really need to probe SDL stuff when it's off.

CC: Paolo Bonzini <pbonzini@redhat.com>
CC: Gerd Hoffmann <kraxel@redhat.com>
CC: Peter Maydell <peter.maydell@linaro.org>
CC: Daniel P. Berrange <berrange@redhat.com>
CC: Fam Zheng <famz@redhat.com>
CC: "Philippe Mathieu-Daudé" <f4bug@amsat.org>
Signed-off-by: NPeter Xu <peterx@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Reviewed-by: NFam Zheng <famz@redhat.com>
Message-id: 20180410054034.20479-1-peterx@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

We don't need to detect GTK ABI if GTK is disabled in general.
Otherwise we could get this warning (when host is installed with GTK ABI
version 2) even when configure with "--disable-gtk":

    WARNING: Use of GTK 2.0 is deprecated and will be removed in
    WARNING: future releases. Please switch to using GTK 3.0

CC: Paolo Bonzini <pbonzini@redhat.com>
CC: Gerd Hoffmann <kraxel@redhat.com>
CC: Peter Maydell <peter.maydell@linaro.org>
CC: Fam Zheng <famz@redhat.com>
CC: "Philippe Mathieu-Daudé" <f4bug@amsat.org>
Signed-off-by: NPeter Xu <peterx@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Message-id: 20180409082323.29575-1-peterx@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

We forgot to mention --with-git, --libexecdir and --with-pkgversion
so far.
Signed-off-by: NThomas Huth <thuth@redhat.com>
Message-Id: <1522163370-18544-1-git-send-email-thuth@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

configure tries to detect if the compiler
supports 16-byte vector operations.

As stated in the comment of the detection
program, there is a problem with the system
compiler on GCC on Centos 7.

This program doesn't actually detect the problem
with GCC on RHEL7 on PPC64LE (Red Hat 4.8.5-28).

This patch updates the test to look more like
it is in QEMU helpers, and now detects the problem.

The error reported is:

  CC      ppc64-softmmu/accel/tcg/tcg-runtime-gvec.o
  ..//accel/tcg/tcg-runtime-gvec.c: In function ‘helper_gvec_shl8i’:
  ../accel/tcg/tcg-runtime-gvec.c:558:26: internal compiler error: in emit_move_insn, at expr.c:3495
           *(vec8 *)(d + i) = *(vec8 *)(a + i) << shift;
                            ^
Fixes: db432672 "tcg: Add generic vector expanders"
Signed-off-by: NLaurent Vivier <lvivier@redhat.com>
Reviewed-by: NMiroslav Rezanina <mrezanin@redhat.com>
Message-id: 20180328133152.24623-1-lvivier@redhat.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

This fixes a breaking change to WHvGetCapability to include the 'out'
WrittenSizeInBytes introduced in Windows Insider SDK 17110.

This specifies on return the safe length to read into the WHV_CAPABILITY
structure passed to the call.
Signed-off-by: NJustin Terry (VM) <juterry@microsoft.com>
Message-Id: <1521039163-138-2-git-send-email-juterry@microsoft.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Our rule right now is to use <> for external headers,
"" for internal ones. The idea was to avoid conflicts
between e.g. a system file named <trace.h> and an
internal one by the same name.

Unfortunately we use -I compiler flag so it does not
help: a system file doing #include <trace.h> will
still pick up ours first.

To fix, switch to -iquote which is supported by both
gcc and clang and only affects #include "" directives.

As a side effect, this catches any future uses of
 #include <> for internal headers.
Suggested-by: NStefan Weil <sw@weilnetz.de>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NMarcel Apfelbaum <marcel@redhat.com>
Signed-off-by: NMarcel Apfelbaum <marcel@redhat.com>

- emit TCG barriers for MEMW, EXTW, S32RI and L32AI;
- do atomic_cmpxchg_i32 for S32C1I.

Cc: Emilio G. Cota <cota@braap.org>
Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>

Actually enable the global memory barriers if supported by the OS.
Because only recent versions of Linux include the support, they
are disabled by default.  Note that it also has to be disabled
for QEMU to run under Wine.

Before this patch, rcutorture reports 85 ns/read for my machine,
after the patch it reports 12.5 ns/read.  On the other hand updates
go from 50 *micro*seconds to 20 *milli*seconds.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Since commit 67a1de0d there is no space anymore between the
version number and the parentheses when running configure with
--with-pkgversion=foo :

 $ qemu-system-s390x --version
 QEMU emulator version 2.11.50(foo)

But the space is included when building without that option
when building from a git checkout:

 $ qemu-system-s390x --version
 QEMU emulator version 2.11.50 (v2.11.0-1494-gbec9c64e-dirty)

The same confusion exists with the "query-version" QMP command.
Let's fix this by introducing a proper QEMU_FULL_VERSION definition
that includes the space and parentheses, while the QEMU_PKGVERSION
should just cleanly contain the package version string itself.
Note that this also changes the behavior of the "query-version" QMP
command (the space and parentheses are not included there anymore),
but that's supposed to be OK since the strings there are not meant
to be parsed by other tools.

Fixes: 67a1de0d
Buglink: https://bugs.launchpad.net/qemu/+bug/1673373Signed-off-by: NThomas Huth <thuth@redhat.com>
Message-Id: <1518692807-25859-1-git-send-email-thuth@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Message-id: 20180306074053.22856-8-kraxel@redhat.com

Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Message-id: 20180306074053.22856-7-kraxel@redhat.com

Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Message-id: 20180306074053.22856-6-kraxel@redhat.com

Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Message-id: 20180306074053.22856-5-kraxel@redhat.com

As we want qemu symbols be exported to modules we should use the
gmodule-export-2.0 pkg-config instead of gmodule-2.0.

Cc: Marc-André Lureau <marcandre.lureau@gmail.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Message-id: 20180308085301.8875-2-kraxel@redhat.com