This avoids a segfault like the following for at least some 4.8 versions
of gcc when configured with --static if avx2 instructions are also
enabled:
Program received signal SIGSEGV, Segmentation fault.
buffer_find_nonzero_offset_ifunc () at ./util/cutils.c:333
333 {
(gdb) bt
#0 buffer_find_nonzero_offset_ifunc () at ./util/cutils.c:333
#1 0x0000000000939c58 in __libc_start_main ()
#2 0x0000000000419337 in _start ()
Paolo Bonzini [Wed, 20 Jul 2016 19:36:49 +0000 (21:36 +0200)]
optionrom: fix detection of -Wa,-32
The cc-option macro runs $(CC) in -S mode (generate assembly) to avoid a
pointless run of the assembler. However, this does not work when you want
to detect support for cc->as option passthrough. clang ignores -Wa unless
-c is provided, and exits successfully even if the -Wa,-32 option is not
supported.
Peter Maydell [Fri, 29 Jul 2016 11:37:08 +0000 (12:37 +0100)]
Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-2.7-20160729' into staging
ppc patch queue 2016-07-29
Here are the current pending ppc and spapr related patches for
qemu-2.7. Given the freeze status, these are all bugfixes, with two
exceptions:
* There's some final rework of the vcpu hotplug model. Specifically
we add spapr specific code on the generic basis Igor established
to make cpu_index stable for pseries-2.7 and later machine types.
- This allows us to remove the limitation that cpu cores had to
be inserted in linear order, and removed in LIFO order.
- This is worth merging this late in 2.7 because it will avoid
considerable future grief with management layers needing to
discover whether out-of-order hotplug is possible, amongst
other things.
- For now we do add a constraint that the initial cpu cannot be
unplugged.
* We add two extra testcases to make check, for postcopy and
drive_del on ppc64.
- Not strictly bugfixes, but safe, because they don't affect the
actual code, and increase test coverage.
# gpg: Signature made Fri 29 Jul 2016 05:50:02 BST
# gpg: using RSA key 0x6C38CACA20D9B392
# gpg: Good signature from "David Gibson <[email protected]>"
# gpg: aka "David Gibson (Red Hat) <[email protected]>"
# gpg: aka "David Gibson (ozlabs.org) <[email protected]>"
# 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: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392
* remotes/dgibson/tags/ppc-for-2.7-20160729:
tests: add drive_del-test to ppc/ppc64
spapr: Prevent boot CPU core removal
ppc: Fix fault PC reporting for lve*/stve* VMX instructions
test: port postcopy test to ppc64
Revert "spapr: Ensure CPU cores are added contiguously and removed in LIFO order"
spapr: init CPUState->cpu_index with index relative to core-id
Peter Maydell [Fri, 29 Jul 2016 10:57:01 +0000 (11:57 +0100)]
Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging
pc, pci, virtio: cleanups, fixes
a bunch of bugfixes and a couple of cleanups
making these easier and/or making debugging easier
Signed-off-by: Michael S. Tsirkin <[email protected]>
# gpg: Signature made Fri 29 Jul 2016 04:11:01 BST
# gpg: using RSA key 0x281F0DB8D28D5469
# gpg: Good signature from "Michael S. Tsirkin <[email protected]>"
# gpg: aka "Michael S. Tsirkin <[email protected]>"
# Primary key fingerprint: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67
# Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469
* remotes/mst/tags/for_upstream: (41 commits)
mptsas: Fix a migration compatible issue
vhost: do not update last avail idx on get_vring_base() failure
vhost: add vhost_net_set_backend()
vhost-user: add error report in vhost_user_write()
tests: fix vhost-user-test leak
tests: plug some leaks in virtio-net-test
vhost-user: wait until backend init is completed
char: add and use tcp_chr_wait_connected
char: add chr_wait_connected callback
vhost: add assert() to check runtime behaviour
vhost-net: vhost_migration_done is vhost-user specific
Revert "vhost-net: do not crash if backend is not present"
vhost-user: add get_vhost_net() assertions
vhost-user: keep vhost_net after a disconnection
vhost-user: check vhost_user_{read,write}() return value
vhost-user: check qemu_chr_fe_set_msgfds() return value
vhost-user: call set_msgfds unconditionally
qemu-char: fix qemu_chr_fe_set_msgfds() crash when disconnected
vhost: use error_report() instead of fprintf(stderr,...)
vhost: add missing VHOST_OPS_DEBUG
...
Boot CPU is assumed to be always present in QEMU code. So
until that assumptions are gone, deny removal request.
In another words, QEMU won't support boot CPU core hot-unplug.
Signed-off-by: Bharata B Rao <[email protected]>
[dwg: Tweaked error message for clarity] Signed-off-by: David Gibson <[email protected]>
ppc: Fix fault PC reporting for lve*/stve* VMX instructions
We forgot to do gen_update_nip() for these like we do with other
helpers. Fix this, but in a more efficient way by passing the RA
to the accessors instead so the overhead is only taken on faults.
As userfaultfd syscall is available on powerpc, migration
postcopy can be used.
This patch adds the support needed to test this on powerpc,
instead of using a bootsector to run code to modify memory,
we use a FORTH script in "boot-command" property.
As spapr machine doesn't support "-prom-env" argument
(the nvram is initialized by SLOF and not by QEMU),
"boot-command" is provided to SLOF via a file mapped nvram
(with "-drive file=...,if=pflash")
Igor Mammedov [Thu, 21 Jul 2016 15:54:37 +0000 (17:54 +0200)]
spapr: init CPUState->cpu_index with index relative to core-id
It will enshure that cpu_index for a given cpu stays the same
regardless of the order cpus has been created/deleted and so
it would be possible to migrate QEMU instance with out of order
created CPU.
John Snow [Thu, 28 Jul 2016 21:34:19 +0000 (17:34 -0400)]
ide: fix halted IO segfault at reset
If one attempts to perform a system_reset after a failed IO request
that causes the VM to enter a paused state, QEMU will segfault trying
to free up the pending IO requests.
These requests have already been completed and freed, though, so all
we need to do is NULL them before we enter the paused state.
Existing AHCI tests verify that halted requests are still resumed
successfully after a STOP event.
Not all vhost-user backends support ops->vhost_net_set_backend(). It is
a nicer to provide an assert/error than to crash trying to
call. Furthermore, it improves a bit the code by hiding vhost_ops
details.
The chardev waits for an initial connection before starting qemu, and
vhost-user should wait for the backend negotiation to be completed
before starting qemu too.
vhost-user is started in the net_vhost_user_event callback, which is
synchronously called after the socket is connected. Use a
VhostUserState.started flag to indicate vhost-user init completed
successfully and qemu can be started.
vhost-net: vhost_migration_done is vhost-user specific
Either the callback is mandatory to implement, in which case an assert()
is more appropriate, or it's not and we can't tell much whether the
function should fail or not (given it's name, I guess it should silently
success by default). Instead, make the implementation mandatory and
vhost-user specific to be more clear about its usage.
Add a few assertions to be more explicit about the runtime behaviour
after the previous patch: get_vhost_net() is non-null after
net_vhost_user_init().
vhost-user: check vhost_user_{read,write}() return value
The vhost-user code is quite inconsistent with error handling. Instead
of ignoring some return values of read/write and silently going on with
invalid state (invalid read for example), break the code flow when the
error happened.
vhost: fix calling vhost_dev_cleanup() after vhost_dev_init()
vhost_net_init() calls vhost_dev_init() and in case of failure, calls
vhost_dev_cleanup() directly. However, the structure is already
partially cleaned on error. Calling vhost_dev_cleanup() again will call
vhost_virtqueue_cleanup() on already clean queues, and causing potential
double-close. Instead, adjust dev->nvqs and simplify vhost_dev_init()
code to not call vhost_virtqueue_cleanup() but vhost_dev_cleanup()
instead.
vhost-net: always call vhost_dev_cleanup() on failure
vhost_dev_init(), calling vhost backend initialization, should be
cleaned up after failure too. Call vhost_dev_cleanup() in all failure
cases. First, it needs to zero-alloc the struct to avoid the initial
garbage.
It is called on multiple code path, so make it safe to call several
times (note: I don't remember a reproducer here, but a function called
'cleanup' should probably be idempotent in my book)
vhost: fix cleanup on not fully initialized device
If vhost_dev_init() failed, caller may still call vhost_dev_cleanup()
later. However, vhost_dev_cleanup() tries to remove the device from the
list even if it wasn't yet added, which may lead to crashes. Similarly
for the memory listener.
Make sure the log was released on cleanup, or it will leak (the
alternative is to call vhost_log_put() unconditionally, but it may hide
some dev state issues).
vhost: don't assume opaque is a fd, use backend cleanup
vhost-dev opaque isn't necessarily an fd, it can be a chardev when using
vhost-user. Goto fail, so vhost_backend_cleanup() is called to handle
backend cleanup appropriately.
vhost_set_backend_type() should never fail, use an assert().
In some cases, qemu_chr_fe_read_all() on HUP event doesn't raise
CHR_EVENT_CLOSED because the read/recv function returns -1 on
disconnected peers (for example with tch_chr_recv, an ECONNRESET errno
overwritten as EIO).
It is simpler to explicitely disconnect on HUP, rising CHR_EVENT_CLOSED
if it wasn't disconnected already.
virtio back end uses set of buffers to facilitate I/O operations.
An infinite loop unfolds in virtqueue_pop() if a buffer was
of zero size. Add check to avoid it.
In build_crs(), the calculation and merging of the ranges already happens
in 64-bit, but the entry boundaries are silently truncated to 32-bit in the
call to aml_dword_memory(). Fix it by handling the 64-bit MMIO ranges separately.
This fixes 64-bit BARs behind PXBs.
hw/acpi: fix a DSDT table issue when a pxb is present.
PXBs do not support hotplug so they don't have a PCNT function.
Since the PXB's PCI root-bus is a child bus of bus 0, the
build_dsdt code will add a call to the corresponding PCNT function.
Fix this by skipping the PCNT call for the above case.
While at it skip also PCIe child buses.
We changed link status register in pci express endpoint capability
over time. Specifically,
commit b2101eae63ea57b571cee4a9075a4287d24ba4a4 ("pcie: Set the "link
active" in the link status register") set data link layer link active
bit in this register without adding compatibility to old machine types.
When migrating from qemu 2.3 and older this affects xhci devices which
under machine type 2.0 and older have a pci express endpoint capability
even if they are on a pci bus.
Add compatibility flags to make this bit value match what it was under
2.3.
Additionally, to avoid breaking migration from qemu 2.3 and up,
suppress checking link status during migration: this seems sane
since hardware can change link status at any time.
Reported-by: Gerd Hoffmann <[email protected]> Fixes: b2101eae63ea57b571cee4a9075a4287d24ba4a4
("pcie: Set the "link active" in the link status register") Cc: [email protected] Cc: Benjamin Herrenschmidt <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]>
Leon Alrae [Thu, 28 Jul 2016 08:28:23 +0000 (09:28 +0100)]
target-mips: fix EntryHi.EHINV being cleared on TLB exception
While implementing TLB invalidation feature we forgot to modify
part of code responsible for updating EntryHi during TLB exception.
Consequently EntryHi.EHINV is unexpectedly cleared on the exception.
Paul Burton [Fri, 22 Jul 2016 09:55:40 +0000 (10:55 +0100)]
hw/mips_malta: Fix YAMON API print routine
The print routine provided as part of the in-built bootloader had a bug
in that it attempted to use a jump instruction as part of a loop, but
the target has its upper bits zeroed leading to control flow
transferring to 0xb0000814 rather than the intended 0xbfc00814. Fix this
by using a branch instruction instead, which seems more fit for purpose.
A simple way to test this is to build a Linux kernel with EVA enabled &
attempt to boot it in QEMU. It will attempt to print a message
indicating the configuration mismatch but QEMU would previously
incorrectly jump & wind up printing a continuous stream of the letter E.
Peter Maydell [Wed, 27 Jul 2016 17:18:21 +0000 (18:18 +0100)]
Merge remote-tracking branch 'remotes/ehabkost/tags/x86-pull-request' into staging
x86 and machine queue, 2016-07-27
Highlights:
* Fixes to allow CPU hotplug/unplug in any order;
* Exit QEMU on invalid global properties.
# gpg: Signature made Wed 27 Jul 2016 15:28:53 BST
# gpg: using RSA key 0x2807936F984DC5A6
# gpg: Good signature from "Eduardo Habkost <[email protected]>"
# Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF D1AA 2807 936F 984D C5A6
* remotes/ehabkost/tags/x86-pull-request:
vl: exit if a bad property value is passed to -global
qdev: ignore GlobalProperty.errp for hotplugged devices
machine: Add comment to abort path in machine_set_kernel_irqchip
Revert "pc: Enforce adding CPUs contiguously and removing them in opposite order"
pc: Init CPUState->cpu_index with index in possible_cpus[]
qdev: Fix object reference leak in case device.realize() fails
exec: Set cpu_index only if it's not been explictly set
exec: Don't use cpu_index to detect if cpu_exec_init()'s been called
exec: Reduce CONFIG_USER_ONLY ifdeffenery
* remotes/cody/tags/block-pull-request:
mirror: double performance of the bulk stage if the disc is full
block/gluster: fix doc in the qapi schema and member name
Greg Kurz [Thu, 21 Jul 2016 22:00:57 +0000 (00:00 +0200)]
vl: exit if a bad property value is passed to -global
When passing '-global driver=host-powerpc64-cpu,property=compat,value=foo'
on the command line, without this patch, we get the following warning per
device (which means many lines if the guests has many cpus):
qemu-system-ppc64: Warning: can't apply global host-powerpc64-cpu.compat=foo:
Invalid compatibility mode "foo"
... and QEMU continues execution, ignoring the property.
With this patch, we get a single line:
qemu-system-ppc64: can't apply global host-powerpc64-cpu.compat=foo:
Invalid compatibility mode "foo"
... and QEMU exits.
The previous behavior is kept for hotplugged devices since we don't want
QEMU to exit when doing device_add.
Greg Kurz [Wed, 13 Jul 2016 18:11:45 +0000 (20:11 +0200)]
machine: Add comment to abort path in machine_set_kernel_irqchip
We're not supposed to abort when the user passes a bogus value.
Since the checking is done in visit_type_OnOffSplit(), the call
to abort() is legitimate. Let's add a comment to make it
explicit.
Stefan Hajnoczi [Tue, 19 Jul 2016 12:07:13 +0000 (13:07 +0100)]
virtio: error out if guest exceeds virtqueue size
A broken or malicious guest can submit more requests than the virtqueue
size permits, causing unbounded memory allocation in QEMU.
The guest can submit requests without bothering to wait for completion
and is therefore not bound by virtqueue size. This requires reusing
vring descriptors in more than one request, which is not allowed by the
VIRTIO 1.0 specification.
In "3.2.1 Supplying Buffers to The Device", the VIRTIO 1.0 specification
says:
1. The driver places the buffer into free descriptor(s) in the
descriptor table, chaining as necessary
and
Note that the above code does not take precautions against the
available ring buffer wrapping around: this is not possible since the
ring buffer is the same size as the descriptor table, so step (1) will
prevent such a condition.
This implies that placing more buffers into the virtqueue than the
descriptor table size is not allowed.
QEMU is missing the check to prevent this case. Processing a request
allocates a VirtQueueElement leading to unbounded memory allocation
controlled by the guest.
Exit with an error if the guest provides more requests than the
virtqueue size permits. This bounds memory allocation and makes the
buggy guest visible to the user.
This patch fixes CVE-2016-5403 and was reported by Zhenhao Hong from 360
Marvel Team, China.
mirror: double performance of the bulk stage if the disc is full
Mirror can do up to 16 in-flight requests, but actually on full copy
(the whole source disk is non-zero) in-flight is always 1. This happens
as the request is not limited in size: the data occupies maximum available
capacity of s->buf.
The patch limits the size of the request to some artificial constant
(1 Mb here), which is not that big or small. This effectively enables
back parallelism in mirror code as it was designed.
The result is important: the time to migrate 10 Gb disk is reduced from
~350 sec to 170 sec.
Since commit:
pc: init CPUState->cpu_index with index in possible_cpus[]
cpu_index is stable regardless of the order cpus were created
and QEMU instance stays migratable always so limitation added
by 4da7faaeb could be safely removed.
Igor Mammedov [Mon, 25 Jul 2016 09:59:23 +0000 (11:59 +0200)]
pc: Init CPUState->cpu_index with index in possible_cpus[]
It will enshure that cpu_index for a given cpu stays the same
regardless of the order cpus has been created/deleted.
No compat code is needed as for initial cpus index in
possible_cpus[] matches cpu_index that's been auto-allocated
in cpu_exec_init().
Tha same applies for hotplug with cpu-add command if cpus are
added sequentially in increasing order as 'id' matches cpu_index.
If cpu-add had been used for creating out-of-order cpus,
that created unmigratable instance since it were not possible
to start target with the same cpu_index using old way
of migrating instance with hotplugged cpus:
* source QEMU with CLI (-smp 1,maxcpus=3 and cpu-add id=2)
following set of cpu_index is allocated [0, 1] with
apics set [0, 2] respectivelly
* target QEMU is started with CLI -smp 2,maxcpus=3
resulting in set of cpu_index [0, 1] but with
set of apics [0, 1] wich doesn't match source.
So we don't need compat code in this case as it's never worked
and newelly added device_add support would use stable cpu_index
set by machine to begin with, so it won't have above limitation
and source QEMU could be migrated to destination regardless
of the order cpus were created.
Igor Mammedov [Mon, 25 Jul 2016 09:59:22 +0000 (11:59 +0200)]
qdev: Fix object reference leak in case device.realize() fails
If device doesn't have parent assined before its realize
is called, device_set_realized() will implicitly set parent
to '/machine/unattached'.
However device_set_realized() may fail after that point at
several other points leaving not realized object dangling
in '/machine/unattached' and as result caller of
Igor Mammedov [Mon, 25 Jul 2016 09:59:21 +0000 (11:59 +0200)]
exec: Set cpu_index only if it's not been explictly set
It keeps the legacy behavior for all users that doesn't care
about stable cpu_index value, but would allow boards that
would support device_add/device_del to set stable cpu_index
that won't depend on order in which cpus are created/destroyed.
While at that simplify cpu_get_free_index() as cpu_index
generated by USER_ONLY and softmmu variants is the same
since none of the users support cpu-remove so far, except
of not yet released spapr/x86 device_add/delr, which
will be altered by follow up patches to set stable
cpu_index manually.
Igor Mammedov [Mon, 25 Jul 2016 09:59:20 +0000 (11:59 +0200)]
exec: Don't use cpu_index to detect if cpu_exec_init()'s been called
Instead use QTAIL's tqe_prev field to detect if cpu's been
placed in list by cpu_exec_init() which is always set if
QTAIL element is in list.
Fixes SIGSEGV on failure path in case cpu_index is assigned
by board and cpu.relalize() fails before cpu_exec_init() is called.
In follow up patches, cpu_index will be assigned by boards that
support cpu hot(un)plug and need stable cpu_index that doesn't
depend on order cpus are created/removed.
* remotes/maxreitz/tags/pull-block-2016-07-26:
iotest: fix python based IO tests
block: export LUKS specific data to qemu-img info
crypto: add support for querying parameters for block encryption
AioContext: correct comments
qcow2: do not allocate extra memory
scripts: refactor the VM class in iotests for reuse
was not properly tested and included a number of broken
bits.
- The 'event_match' method was not moved into qemu.py
- The 'self._args' list parameter in QEMUMachine needs
to be copied otherwise modifications will affect the
global 'qemu_opts' variable in iotests.py
- The QEMUQtestMachine class methods had inverted
parameter order for the super() calls
- The QEMUQtestMachine class forgot to add
'-machine accel=qtest'
- The QEMUQtestMachine class constructor needs to set
a default 'name' value before using it as it may
be None
- The QEMUQtestMachine class constructor needs to use
named parameters when calling the super constructor
as it is leaving out some positional parameters.
- The 'qemu_prog' variable should be a string not a
list in iotests.py
- The VM classs constructor needs to use named
parameters when calling the super constructor
as it is leaving out some positional parameters.
- The path to the socket-scm-helper needs to be
passed into the QEMUMachine class
The qemu-img info command has the ability to expose format
specific metadata about volumes. Wire up this facility for
the LUKS driver to report on cipher configuration and key
slot usage.
One somewhat undesirable artifact is that the data fields are
printed out in (apparently) random order. This will be addressed
later by changing the way the block layer pretty-prints the
image specific data.
crypto: add support for querying parameters for block encryption
When creating new block encryption volumes, we accept a list of
parameters to control the formatting process. It is useful to
be able to query what those parameters were for existing block
devices. Add a qcrypto_block_get_info() method which returns a
QCryptoBlockInfo instance to report this data.
There are no needs to allocate more than one cluster, as we set
avail_out for deflate to one cluster.
Zlib docs (http://www.zlib.net/manual.html) says:
"deflate compresses as much data as possible, and stops when the input
buffer becomes empty or the output buffer becomes full."
So, deflate will not write more than avail_out to output buffer. If
there is not enough space in output buffer for compressed data (it may
be larger than input data) deflate just returns Z_OK. (if all data is
compressed and written to output buffer deflate returns Z_STREAM_END).
Peter Maydell [Tue, 26 Jul 2016 10:53:47 +0000 (11:53 +0100)]
Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-2.7-20160726' into staging
ppc patch queue 2016-07-26
Here's the current batch of ppc and spapr related patches intended for
qemu-2.7. Given the late stage in 2.7 development, these are all
bugfixes with one exception:
The "spapr: disintricate core-id from DT semantics" changes the way
ids are assigned in the new core-based hotplug infrastructure. This
isn't strictly a bugfix, but we've determined that the current way of
assigning core-ids will cause considerable grief with future plans for
cpu hotplug. Therefore it's better to fix this now, late in 2.7,
before we have a released version with the problematic numbering.
# gpg: Signature made Tue 26 Jul 2016 04:04:57 BST
# gpg: using RSA key 0x6C38CACA20D9B392
# gpg: Good signature from "David Gibson <[email protected]>"
# gpg: aka "David Gibson (Red Hat) <[email protected]>"
# gpg: aka "David Gibson (ozlabs.org) <[email protected]>"
# 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: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392
* remotes/dgibson/tags/ppc-for-2.7-20160726:
spapr: disintricate core-id from DT semantics
target-ppc: add PPC_MFTB flag to e500mc and e5500
spapr: fix spapr-nvram migration
hw/ppc/spapr: Make sure to close the htab_fd when migration is canceled
ppc: Huge page detection mechanism fixes - Episode III
* remotes/mdroth/tags/qga-pull-2016-07-25-tag:
configure: mark qemu-ga VSS includes as system headers
tests: use static qga config file
build-sys: link tests/data
Michael Roth [Tue, 28 Jun 2016 22:31:49 +0000 (17:31 -0500)]
configure: mark qemu-ga VSS includes as system headers
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.
Greg Kurz [Fri, 22 Jul 2016 11:10:36 +0000 (13:10 +0200)]
spapr: disintricate core-id from DT semantics
The goal of this patch is to have a stable core-id which does not depend
on any DT related semantics, which involve non-obvious computations on
modern PowerPC server cpus.
With this patch, the DT core id is computed on-demand as:
(core-id / smp_threads) * smt
where smt is the number of threads per core in the host.
This formula should be consolidated in a helper since it is needed in
several places.
Other uses for core-id includes: compute a stable cpu_index (which
allows random order hotplug/unplug without breaking migration) and
NUMA.
Thomas Huth [Thu, 21 Jul 2016 09:21:34 +0000 (11:21 +0200)]
hw/ppc/spapr: Make sure to close the htab_fd when migration is canceled
When canceling a migration process, we currently do not close the
HTAB migration file descriptor since htab_save_complete() is never
called in that case. So we leave the migration process with a
dangling htab_fd value around, and this causes any further migration
attempts to fail. To fix this issue, simply make sure that the
htab_fd is closed during the migration cleanup stage. And since the
cleanup() function is also called when migration succeeds, we can
also remove the call to close_htab_fd() from the htab_save_complete()
function.
Thomas Huth [Mon, 18 Jul 2016 13:19:04 +0000 (15:19 +0200)]
ppc: Huge page detection mechanism fixes - Episode III
After already fixing two issues with the huge page detection mechanism
(see commit 159d2e39a860 and 86b50f2e1bef), Greg Kurz noticed another
case that caused the guest to crash where QEMU announces huge pages
though they should not be available for the guest:
That means if there is a global mem-path option, we still have
to look at the memory-backend objects that have been specified
additionally and return their minimum page size if that value
is smaller than the page size of the main memory.
Peter Maydell [Tue, 12 Jul 2016 12:50:59 +0000 (13:50 +0100)]
target-sh4: Use glib allocator in movcal helper
Coverity spots that helper_movcal() calls malloc() but doesn't
check for failure. Fix this by switching to the glib allocation
functions, which abort on allocation failure.
Peter Maydell [Fri, 22 Jul 2016 09:51:31 +0000 (10:51 +0100)]
Merge remote-tracking branch 'remotes/amit-migration/tags/migration-for-2.7-6' into staging
Migration:
- Fix a postcopy bug
- Add a testsuite for measuring migration performance
# gpg: Signature made Fri 22 Jul 2016 08:56:44 BST
# gpg: using RSA key 0xEB0B4DFC657EF670
# gpg: Good signature from "Amit Shah <[email protected]>"
# gpg: aka "Amit Shah <[email protected]>"
# gpg: aka "Amit Shah <[email protected]>"
# Primary key fingerprint: 48CA 3722 5FE7 F4A8 B337 2735 1E9A 3B5F 8540 83B6
# Subkey fingerprint: CC63 D332 AB8F 4617 4529 6534 EB0B 4DFC 657E F670
* remotes/amit-migration/tags/migration-for-2.7-6:
tests: introduce a framework for testing migration performance
scripts: ensure monitor socket has SO_REUSEADDR set
scripts: set timeout when waiting for qemu monitor connection
scripts: refactor the VM class in iotests for reuse
scripts: add a 'debug' parameter to QEMUMonitorProtocol
scripts: add __init__.py file to scripts/qmp/
migration: set state to post-migrate on failure
tests: introduce a framework for testing migration performance
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
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.
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:
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
scripts: ensure monitor socket has SO_REUSEADDR set
If tests use a TCP based monitor socket, the connection will
go into a TIMED_WAIT state when the test exits. This will
randomly prevent the test from being re-run without a certain
time period. Set the SO_REUSEADDR flag on the socket to ensure
we can immediately re-run the tests
scripts: set timeout when waiting for qemu monitor connection
If QEMU fails to launch for some reason, the QEMUMonitorProtocol
class accept() method will wait forever in a socket accept call.
Set a timeout of 15 seconds so that we fail more gracefully
instead of hanging the test script forever
scripts: refactor the VM class in iotests for reuse
The iotests module has a python class for controlling QEMU
processes. Pull the generic functionality out of this file
and create a scripts/qemu.py module containing a QEMUMachine
class. Put the QTest integration support into a subclass
QEMUQtestMachine.
projects / qemu.git / log