Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 26 7月, 2016 2 次提交
    • M
      configure: mark qemu-ga VSS includes as system headers · 690604f6
      由 Michael Roth 提交于 
      As of e4650c81, we do w32 builds with -Werror enabled. Unfortunately
for cases where we enable VSS support in qemu-ga, we still have
warnings generated by VSS includes that ship as part of the Microsoft
VSS SDK.

We can selectively address a number of these warnings using

  #pragma GCC diagnostic ignored ...

but at least one of these:

  warning: ‘typedef’ was ignored in this declaration

resulting from declarations of the form:

  typedef struct Blah { ... };

does not provide a specific command-line/pragma option to disable
warnings of the sort.

To allow VSS builds to succeed, the next-best option is disabling
these warnings on a per-file basis. pragmas like #pragma GCC
system_header can be used to declare subsequent includes/declarations
as being exempt from normal warnings, but this must be done within
a header file.

Since we don't control the VSS SDK, we'd need to rely on a
intermediate header include to accomplish this, and
since different objects in the VSS link target rely on different
headers from the VSS SDK, this would become somewhat of a rat's nest
(though not totally unmanageable).

The next step up in granularity is just marking the entire VSS
SDK include path as system headers via -isystem. This is a bit more
heavy-handed, but since this SDK hasn't changed since 2005, there's
likely little to be gained from selectively disabling warnings
anyway, so we implement that approach here.

This fixes the -Werror failures in both the configure test and the
qga build due to shared reliance on $vss_win32_include. For the
same reason, this also enforces a new dependency on -isystem support
in the C/C++ compiler when building QGA with VSS enabled.

Cc: Thomas Huth <thuth@redhat.com>
Cc: Stefan Weil <sw@weilnetz.de>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NThomas Huth <thuth@redhat.com>
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
      690604f6
    • M
      build-sys: link tests/data · fe31017f
      由 Marc-André Lureau 提交于 
      Link a common tests data directory to the build directory.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
      fe31017f
  3. 22 7月, 2016 1 次提交
    • D
      tests: introduce a framework for testing migration performance · 409437e1
      由 Daniel P. Berrange 提交于 
      This introduces a moderately general purpose framework for
testing performance of migration.

The initial guest workload is provided by the included 'stress'
program, which is configured to spawn one thread per guest CPU
and run a maximally memory intensive workload. It will loop
over GB of memory, xor'ing each byte with data from a 4k array
of random bytes. This ensures heavy read and write load across
all of guest memory to stress the migration performance. While
running the 'stress' program will record how long it takes to
xor each GB of memory and print this data for later reporting.

The test engine will spawn a pair of QEMU processes, either on
the same host, or with the target on a remote host via ssh,
using the host kernel and a custom initrd built with 'stress'
as the /init binary. Kernel command line args are set to ensure
a fast kernel boot time (< 1 second) between launching QEMU and
the stress program starting execution.

None the less, the test engine will initially wait N seconds for
the guest workload to stablize, before starting the migration
operation. When migration is running, the engine will use pause,
post-copy, autoconverge, xbzrle compression and multithread
compression features, as well as downtime & bandwidth tuning
to encourage completion. If migration completes, the test engine
will wait N seconds again for the guest workooad to stablize on
the target host. If migration does not complete after a preset
number of iterations, it will be aborted.

While the QEMU process is running on the source host, the test
engine will sample the host CPU usage of QEMU as a whole, and
each vCPU thread. While migration is running, it will record
all the stats reported by 'query-migration'. Finally, it will
capture the output of the stress program running in the guest.

All the data produced from a single test execution is recorded
in a structured JSON file. A separate program is then able to
create interactive charts using the "plotly" python + javascript
libraries, showing the characteristics of the migration.

The data output provides visualization of the effect on guest
vCPU workloads from the migration process, the corresponding
vCPU utilization on the host, and the overall CPU hit from
QEMU on the host. This is correlated from statistics from the
migration process, such as downtime, vCPU throttling and iteration
number.

While the tests can be run individually with arbitrary parameters,
there is also a facility for producing batch reports for a number
of pre-defined scenarios / comparisons, in order to be able to
get standardized results across different hardware configurations
(eg TCP vs RDMA, or comparing different VCPU counts / memory
sizes, etc).

To use this, first you must build the initrd image

 $ make tests/migration/initrd-stress.img

To run a a one-shot test with all default parameters

 $ ./tests/migration/guestperf.py > result.json

This has many command line args for varying its behaviour.
For example, to increase the RAM size and CPU count and
bind it to specific host NUMA nodes

 $ ./tests/migration/guestperf.py \
       --mem 4 --cpus 2 \
       --src-mem-bind 0 --src-cpu-bind 0,1 \
       --dst-mem-bind 1 --dst-cpu-bind 2,3 \
       > result.json

Using mem + cpu binding is strongly recommended on NUMA
machines, otherwise the guest performance results will
vary wildly between runs of the test due to lucky/unlucky
NUMA placement, making sensible data analysis impossible.

To make it run across separate hosts:

 $ ./tests/migration/guestperf.py \
       --dst-host somehostname > result.json

To request that post-copy is enabled, with switchover
after 5 iterations

 $ ./tests/migration/guestperf.py \
       --post-copy --post-copy-iters 5 > result.json

Once a result.json file is created, a graph of the data
can be generated, showing guest workload performance per
thread and the migration iteration points:

 $ ./tests/migration/guestperf-plot.py --output result.html \
        --migration-iters --split-guest-cpu result.json

To further include host vCPU utilization and overall QEMU
utilization

 $ ./tests/migration/guestperf-plot.py --output result.html \
        --migration-iters --split-guest-cpu \
	--qemu-cpu --vcpu-cpu result.json

NB, the 'guestperf-plot.py' command requires that you have
the plotly python library installed. eg you must do

 $ pip install --user  plotly

Viewing the result.html file requires that you have the
plotly.min.js file in the same directory as the HTML
output. This js file is installed as part of the plotly
python library, so can be found in

  $HOME/.local/lib/python2.7/site-packages/plotly/offline/plotly.min.js

The guestperf-plot.py program can accept multiple json files
to plot, enabling results from different configurations to
be compared.

Finally, to run the entire standardized set of comparisons

  $ ./tests/migration/guestperf-batch.py \
       --dst-host somehost \
       --mem 4 --cpus 2 \
       --src-mem-bind 0 --src-cpu-bind 0,1 \
       --dst-mem-bind 1 --dst-cpu-bind 2,3
       --output tcp-somehost-4gb-2cpu

will store JSON files from all scenarios in the directory
named tcp-somehost-4gb-2cpu
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
Message-Id: <1469020993-29426-7-git-send-email-berrange@redhat.com>
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
      409437e1
  5. 11 7月, 2016 1 次提交
  7. 06 7月, 2016 1 次提交
    • R
      build: Use $(CCAS) for compiling .S files · 5f6f0e27
      由 Richard Henderson 提交于 
      We fail to pass to $(AS) all of the different flags that may be required
for a given set of CFLAGS.  Rather than figuring out the host-specific
mapping, it's better to allow the compiler driver to do that.

However, simply using $(CC) runs afoul of clang trying to build the
option roms.  C.f. 3dd46c78, wherein we changed from
using $(CC) to using $(AS) in the first place.

Work around this by passing -fno-integrated-as to clang, so that we use
the external assembler, and the clang driver still passes along all of
the options that the assembler might require.
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NRichard Henderson <rth@twiddle.net>
Message-Id: <1466703558-7723-1-git-send-email-rth@twiddle.net>
      5f6f0e27
  9. 04 7月, 2016 2 次提交
    • D
      crypto: allow default TLS priority to be chosen at build time · a1c5e949
      由 Daniel P. Berrange 提交于 
      Modern gnutls can use a global config file to control the
crypto priority settings for TLS connections. For example
the priority string "@SYSTEM" instructs gnutls to find the
priority setting named "SYSTEM" in the global config file.

Latest gnutls GIT codebase gained the ability to reference
multiple priority strings in the config file, with the first
one that is found to existing winning. This means it is now
possible to configure QEMU out of the box with a default
priority of "@QEMU,SYSTEM", which says to look for the
settings "QEMU" first, and if not found, use the "SYSTEM"
settings.

To make use of this facility, we introduce the ability to
set the QEMU default priority at build time via a new
configure argument.  It is anticipated that distro vendors
will set this when building QEMU to a suitable value for
use with distro crypto policy setup. eg current Fedora
would run

 ./configure --tls-priority=@SYSTEM

while future Fedora would run

 ./configure --tls-priority=@QEMU,SYSTEM
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      a1c5e949
    • D
      crypto: switch hash code to use nettle/gcrypt directly · 0c16c056
      由 Daniel P. Berrange 提交于 
      Currently the internal hash code is using the gnutls hash APIs.
GNUTLS in turn is wrapping either nettle or gcrypt. Not only
were the GNUTLS hash APIs not added until GNUTLS 2.9.10, but
they don't expose support for all the algorithms QEMU needs
to use with LUKS.

Address this by directly wrapping nettle/gcrypt in QEMU and
avoiding GNUTLS's extra layer of indirection. This gives us
support for hash functions on a much wider range of platforms
and opens up ability to support more hash functions. It also
avoids a GNUTLS bug which would not correctly handle hashing
of large data blocks if int != size_t.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      0c16c056
  11. 28 6月, 2016 2 次提交
  13. 26 6月, 2016 2 次提交
    • P
      configure: Don't allow user-only targets for unknown CPU architectures · affc88cc
      由 Peter Maydell 提交于 
      For the user-only targets, we need to know something about the host CPU
architecture even if we are using the TCI interpreter rather than TCG.
(In particular user-exec.c has code for handling signals that needs
to know about that host's context structures.)

Specifically forbid building the user-only targets on unknown CPU
architectures, rather than allowing them to configure but then fail
when building user-exec.c.

This change drops supports for two configurations which were theoretically
possible before:
 * linux-user targets on M68K hosts using TCI
 * linux-user targets on HPPA hosts using TCI

We don't think anybody is actually trying to use these in practice, though:
 * interpreted TCG on a slow host CPU would be unusably slow
 * the m68k user-exec.c support is missing is_write detection so guest
   code which writes to the same page it is executing from was broken
   (will include any guest program using signals)
 * HPPA TCG backend support was dropped two and a half years ago
   with no complaints
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NLaurent Vivier <laurent@vivier.eu>
Reviewed-by: NRichard Henderson <rth@twiddle.net>
Signed-off-by: NRiku Voipio <riku.voipio@linaro.org>
      affc88cc
    • P
      configure: Don't override ARCH=unknown if enabling TCI · 997f6ed3
      由 Peter Maydell 提交于 
      At the moment if configure finds an unknown CPU it will set
ARCH to 'unknown', and then later either bail out or set it
to 'tci' (depending on whether the user passed configure the
--enable-tcg-interpreter switch). This is unnecessarily
confusing, because we could be using TCI in two cases:
 * a known host architecture (in which case ARCH is set to
   the actual host architecture, like 'i386')
 * an unknown host architecture (in which case ARCH is
   set to 'tci')
so nothing can rely on ARCH=tci to mean "using TCI".
Remove the line setting ARCH, so we leave it as "unknown",
which is what the actual situation is.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NLaurent Vivier <laurent@vivier.eu>
Reviewed-by: NRichard Henderson <rth@twiddle.net>
Signed-off-by: NRiku Voipio <riku.voipio@linaro.org>
      997f6ed3
  15. 20 6月, 2016 1 次提交
  17. 17 6月, 2016 5 次提交
  19. 08 6月, 2016 1 次提交
  21. 07 6月, 2016 4 次提交
  23. 03 6月, 2016 1 次提交
  25. 23 5月, 2016 1 次提交
    • S
      configure: Allow builds with extra warnings · 5919e032
      由 Stefan Weil 提交于 
      The clang compiler supports a useful compiler option -Weverything,
and GCC also has other warnings not enabled by -Wall.

If glib header files trigger a warning, however, testing glib with
-Werror will always fail. A size mismatch is also detected without
-Werror, so simply remove it.

Cc: qemu-stable@nongnu.org
Signed-off-by: NStefan Weil <sw@weilnetz.de>
Message-Id: <1461879221-13338-1-git-send-email-sw@weilnetz.de>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      5919e032
  27. 18 5月, 2016 1 次提交
  29. 11 5月, 2016 6 次提交
  31. 02 5月, 2016 1 次提交
    • J
      configure: Check if struct fsxattr is available from linux header · 277abf15
      由 Jan Vesely 提交于 
      Fixes build failure with --enable-xfsctl and
new linux headers (>=4.5) and older xfsprogs(<4.5):
In file included from /usr/include/xfs/xfs.h:38:0,
                 from /var/tmp/portage/app-emulation/qemu-2.5.0-r1/work/qemu-2.5.0/block/raw-posix.c:97:
/usr/include/xfs/xfs_fs.h:42:8: error: redefinition of ‘struct fsxattr’
 struct fsxattr {
        ^
In file included from /var/tmp/portage/app-emulation/qemu-2.5.0-r1/work/qemu-2.5.0/block/raw-posix.c:60:0:
/usr/include/linux/fs.h:155:8: note: originally defined here
 struct fsxattr {

This is really a bug in the system headers, but we can work around it
by defining HAVE_FSXATTR in the QEMU headers if linux/fs.h provides
the struct, so that xfs_fs.h doesn't try to define it as well.

CC: qemu-trivial@nongnu.org
CC: Markus Armbruster <armbru@redhat.com>
CC: Peter Maydell <peter.maydell@linaro.org>
CC: Stefan Weil <sw@weilnetz.de>
Tested-by: NStefan Weil <sw@weilnetz.de>
Signed-off-by: NJan Vesely <jano.vesely@gmail.com>
[PMM: adjusted commit message, comments]
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      277abf15
  33. 20 4月, 2016 1 次提交
    • J
      block/gluster: prevent data loss after i/o error · d85fa9eb
      由 Jeff Cody 提交于 
      Upon receiving an I/O error after an fsync, by default gluster will
dump its cache.  However, QEMU will retry the fsync, which is especially
useful when encountering errors such as ENOSPC when using the werror=stop
option.  When using caching with gluster, however, the last written data
will be lost upon encountering ENOSPC.  Using the write-behind-cache
xlator option of 'resync-failed-syncs-after-fsync' should cause gluster
to retain the cached data after a failed fsync, so that ENOSPC and other
transient errors are recoverable.

Unfortunately, we have no way of knowing if the
'resync-failed-syncs-after-fsync' xlator option is supported, so for now
close the fd and set the BDS driver to NULL upon fsync error.
Signed-off-by: NJeff Cody <jcody@redhat.com>
      d85fa9eb
  35. 17 4月, 2016 1 次提交
  37. 30 3月, 2016 1 次提交
  39. 24 3月, 2016 1 次提交
  41. 23 3月, 2016 1 次提交
  43. 17 3月, 2016 2 次提交
    • D
      crypto: add support for PBKDF2 algorithm · 37788f25
      由 Daniel P. Berrange 提交于 
      The LUKS data format includes use of PBKDF2 (Password-Based
Key Derivation Function). The Nettle library can provide
an implementation of this, but we don't want code directly
depending on a specific crypto library backend. Introduce
a new include/crypto/pbkdf.h header which defines a QEMU
API for invoking PBKDK2. The initial implementations are
backed by nettle & gcrypt, which are commonly available
with distros shipping GNUTLS.

The test suite data is taken from the cryptsetup codebase
under the LGPLv2.1+ license. This merely aims to verify
that whatever backend we provide for this function in QEMU
will comply with the spec.
Reviewed-by: NFam Zheng <famz@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      37788f25
    • D
      crypto: add cryptographic random byte source · b917da4c
      由 Daniel P. Berrange 提交于 
      There are three backend impls provided. The preferred
is gnutls, which is backed by nettle in modern distros.
The gcrypt impl is provided for cases where QEMU build
against gnutls is disabled, but crypto is still desired.
No nettle impl is provided, since it is non-trivial to
use the nettle APIs for random numbers. Users of nettle
should ensure gnutls is enabled for QEMU.
Reviewed-by: NFam Zheng <famz@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      b917da4c
  45. 08 3月, 2016 1 次提交