Don't truncate the multiplication and do a 64 bit one instead
because the result is stored in a 64 bit variable.
This fixes a similar coverity warning to commit 237a8650d6,
in a similar way, and is the other half of the fix for
coverity CID 1167561.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Acked-by: Michael Walle <michael@walle.cc>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
The patch_hypercalls() function sets up a 'patches'
variable and checks it at the end of the function, but
never modifies it in the middle. Remove this dead code,
which seems to have been present since the function was
added in commit e5ad936b0f in 2012.
(Spotted by Coverity: CID 1005581.)
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Acked-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
process_command returns a negative value in case of error. Make this
clear in the "if" statement and fix the strerror argument to flip it
to positive.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
options must be non-NULL here, because a NULL value is replaced with
qdict_new earlier in the function. Reported by Coverity.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Just check the errno value after fopen and follow it with fstat.
This shuts up Coverity's complaint about TOC/TOU violation.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
options must be non-NULL here, because it has been checked before.
Reported by Coverity.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
There is no need to have those functions as public API.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Remove the duplicated help message for 'kernel_irqchip'.
Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
The README lists the URLs for the wiki pages describing
how to build on Linux and Windows; add the equivalent
link for building on macOS.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Migration
1 My maintainer change
2 Jianjun's qtailq
3 Ashijeet's only-migratable
4 Zhanghailiang's re-active images
5 Pankaj's change name of migration thread
6 My PCI migration merge
7 Juan's debug to tracing
8 My tracing on save
# gpg: Signature made Tue 24 Jan 2017 18:39:35 GMT
# gpg: using RSA key 0x0516331EBC5BFDE7
# gpg: Good signature from "Dr. David Alan Gilbert (RH2) <dgilbert@redhat.com>"
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 45F5 C71B 4A0C B7FB 977A 9FA9 0516 331E BC5B FDE7
* remotes/dgilbert/tags/pull-migration-20170124b:
migration/tracing: Add tracing on save
migration: transform remaining DPRINTF into trace_
PCI/migration merge vmstate_pci_device and vmstate_pcie_device
migration: Change name of live migration thread
migration: re-active images while migration been canceled after inactive them
migration: Fail migration blocker for --only-migratable
migration: disallow migrate_add_blocker during migration
migration: Allow "device add" options to only add migratable devices
migration: Add a new option to enable only-migratable
block/vvfat: Remove the undesirable comment
migration: add error_report
tests/migration: Add test for QTAILQ migration
migration: migrate QTAILQ
migration: extend VMStateInfo
MAINTAINERS: Add myself as a migration submaintainer
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Add some tracing to vmstate_subsection_save and vmstate_save_state
to help in debugging when you're not sure if a conditional piece
of data is being saved.
In vmstate_subsection_save I renamed the inner vmsd to avoid the aliasing
and be able to print both names.
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20161212125838.14425-1-dgilbert@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
The vmstate_pci_device and vmstate_pcie_devices differ
just in the size of one buffer; combine the two using a _TEST
macro.
I think this is safe as long as everywhere which currently
uses either of these two uses the right type.
One thing that concerns me is that some places use pci_device_load/save
which does some irq mangling, but others just use the VMSTATE_PCI_DEVICE
macro - how are they getting the same irq mangling?
This passes a smoke test migrate of:
./x86_64-softmmu/qemu-system-x86_64 -M pc,accel=kvm -m 1024
./littlefed20.img -device e1000e -device virtio-net -device
e1000 -device virtio-rng -device megasas -device megasas-gen2 -device
ioh3420 -device nec-usb-xhci
to an unmodified qemu.
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20161214195829.18241-1-dgilbert@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
commit fe904ea824 fixed a case
which migration aborted QEMU because it didn't regain the control
of images while some errors happened.
Actually, there are another two cases can trigger the same error reports:
" bdrv_co_do_pwritev: Assertion `!(bs->open_flags & 0x0800)' failed",
Case 1, codes path:
migration_thread()
migration_completion()
bdrv_inactivate_all() ----------------> inactivate images
qemu_savevm_state_complete_precopy()
socket_writev_buffer() --------> error because destination fails
qemu_fflush() ----------------> set error on migration stream
-> qmp_migrate_cancel() ----------------> user cancelled migration concurrently
-> migrate_set_state() ------------------> set migrate CANCELLIN
migration_completion() -----------------> go on to fail_invalidate
if (s->state == MIGRATION_STATUS_ACTIVE) -> Jump this branch
Case 2, codes path:
migration_thread()
migration_completion()
bdrv_inactivate_all() ----------------> inactivate images
migreation_completion() finished
-> qmp_migrate_cancel() ---------------> user cancelled migration concurrently
qemu_mutex_lock_iothread();
qemu_bh_schedule (s->cleanup_bh);
As we can see from above, qmp_migrate_cancel can slip in whenever
migration_thread does not hold the global lock. If this happens after
bdrv_inactive_all() been called, the above error reports will appear.
To prevent this, we can call bdrv_invalidate_cache_all() in qmp_migrate_cancel()
directly if we find images become inactive.
Besides, bdrv_invalidate_cache_all() in migration_completion() doesn't have the
protection of big lock, fix it by add the missing qemu_mutex_lock_iothread();
Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com>
Message-Id: <1485244792-11248-1-git-send-email-zhang.zhanghailiang@huawei.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Introduce checks for the unmigratable flag in the VMStateDescription
structs of respective devices when user attempts to add them. If the
"--only-migratable" was specified, all unmigratable devices will
rightly fail to add. This feature is made compatible for both "-device"
and "-usbdevice" command line options and covers their hmp and qmp
counterparts as well.
Signed-off-by: Ashijeet Acharya <ashijeetacharya@gmail.com>
Message-Id: <1484566314-3987-4-git-send-email-ashijeetacharya@gmail.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Currently we cannot directly transfer a QTAILQ instance because of the
limitation in the migration code. Here we introduce an approach to
transfer such structures. We created VMStateInfo vmstate_info_qtailq
for QTAILQ. Similar VMStateInfo can be created for other data structures
such as list.
When a QTAILQ is migrated from source to target, it is appended to the
corresponding QTAILQ structure, which is assumed to have been properly
initialized.
This approach will be used to transfer pending_events and ccs_list in spapr
state.
We also create some macros in qemu/queue.h to access a QTAILQ using pointer
arithmetic. This ensures that we do not depend on the implementation
details about QTAILQ in the migration code.
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Jianjun Duan <duanj@linux.vnet.ibm.com>
Message-Id: <1484852453-12728-3-git-send-email-duanj@linux.vnet.ibm.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Two s390x fixes: One for the kvm.c build failure, and one for a bug
that might cause random guest crashes with zeroed out pages on host
kernels with working cmma (< 4.6 and likely >= 4.10).
# gpg: Signature made Tue 24 Jan 2017 15:00:50 GMT
# gpg: using RSA key 0xDECF6B93C6F02FAF
# gpg: Good signature from "Cornelia Huck <huckc@linux.vnet.ibm.com>"
# gpg: aka "Cornelia Huck <cornelia.huck@de.ibm.com>"
# Primary key fingerprint: C3D0 D66D C362 4FF6 A8C0 18CE DECF 6B93 C6F0 2FAF
* remotes/cohuck/tags/s390x-20170124:
s390x/kvm: fix cmma reset for KVM
s390x/kvm: include hw_accel.h instead of kvm.h
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
x86, machine, numa queue (2017-01-23)
# gpg: Signature made Mon 23 Jan 2017 23:26:59 GMT
# gpg: using RSA key 0x2807936F984DC5A6
# gpg: Good signature from "Eduardo Habkost <ehabkost@redhat.com>"
# Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF D1AA 2807 936F 984D C5A6
* remotes/ehabkost/tags/x86-and-machine-pull-request:
kvm: Allow invtsc migration if tsc-khz is set explicitly
kvm: Simplify invtsc check
hw/core/null-machine: Add the possibility to instantiate a CPU and RAM
qemu-options: Rename variables on the -numa "cpus" option
MAINTAINERS: Add an entry for hw/core/null-machine.c
machine: Make possible_cpu_arch_ids() return const pointer
pc: don't return cpu pointer from pc_new_cpu() as it's not needed anymore
pc: cleanup: move smbios_set_cpuid() into pc_build_smbios()
arch_init: Remove unnecessary default_config_files table
vl: Ensure the numa_post_machine_init func in the appropriate location
i386: Return migration-safe field on query-cpu-definitions
i386: Remove AMD feature flag aliases from Opteron models
x86: add AVX512_VPOPCNTDQ features
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
We must reset the CMMA states for normal memory (when not on mem path),
but the current code does the opposite. This was unnoticed for some time
as the kernel since 4.6 also had a bug which mostly disabled the paging
optimizations.
Fixes: 07059effd1 ("s390x/kvm: let the CPU model control CMM(A)")
Cc: qemu-stable@nongnu.org # v2.8
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Commit b394662 ("kvm: move cpu synchronization code") switched
to hw_accel.h instead of kvm.h, but missed s390x, resulting in
CC s390x-softmmu/target/s390x/kvm.o
/home/cohuck/git/qemu/target/s390x/kvm.c: In function ‘kvm_sclp_service_call’:
/home/cohuck/git/qemu/target/s390x/kvm.c:1034:5: error: implicit declaration of function ‘cpu_synchronize_state’ [-Werror=implicit-function-declaration]
cpu_synchronize_state(CPU(cpu));
^
/home/cohuck/git/qemu/target/s390x/kvm.c:1034:5: error: nested extern declaration of ‘cpu_synchronize_state’ [-Werror=nested-externs]
/home/cohuck/git/qemu/target/s390x/kvm.c: In function ‘sigp_initial_cpu_reset’:
/home/cohuck/git/qemu/target/s390x/kvm.c:1628:5: error: implicit declaration of function ‘cpu_synchronize_post_reset’ [-Werror=implicit-function-declaration]
cpu_synchronize_post_reset(cs);
^
/home/cohuck/git/qemu/target/s390x/kvm.c:1628:5: error: nested extern declaration of ‘cpu_synchronize_post_reset’ [-Werror=nested-externs]
/home/cohuck/git/qemu/target/s390x/kvm.c: In function ‘sigp_set_prefix’:
/home/cohuck/git/qemu/target/s390x/kvm.c:1665:5: error: implicit declaration of function ‘cpu_synchronize_post_init’ [-Werror=implicit-function-declaration]
cpu_synchronize_post_init(cs);
^
/home/cohuck/git/qemu/target/s390x/kvm.c:1665:5: error: nested extern declaration of ‘cpu_synchronize_post_init’ [-Werror=nested-externs]
cc1: all warnings being treated as errors
/home/cohuck/git/qemu/rules.mak:64: recipe for target 'target/s390x/kvm.o' failed
Fix this.
Fixes: b394662 ("kvm: move cpu synchronization code")
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Acked-by: Vincent Palatin <vpalatin@chromium.org>
When qemu-doc.txt was added as a new output format in
commit f8bab10b4c, it was not added to either the
list of files to remove in distclean or to the dependency
line that forces qemu-options.texi to be built before
attempting to build qemu-doc.*.
In particular, the missing dependency meant that on
some platforms (notably OSX hosts) we would try to
build qemu-doc.txt before qemu-options.texi had been
fully written out, and then makeinfo would complain
about missing cross-reference targets.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 1485266538-10119-1-git-send-email-peter.maydell@linaro.org
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
We can safely allow a VM to be migrated with invtsc enabled if
tsc-khz is set explicitly, because:
* QEMU already refuses to start if it can't set the TSC frequency
to the configured value.
* Management software is already required to keep device
configuration (including CPU configuration) the same on
migration source and destination.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20170108173234.25721-3-ehabkost@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Sometimes it is useful to have just a machine with CPU and RAM, without
any further hardware in it, e.g. if you just want to do some instruction
debugging for TCG with a remote GDB attached to QEMU, or run some embedded
code with the "-semihosting" QEMU parameter. qemu-system-m68k already
features a "dummy" machine, and xtensa a "sim" machine for exactly this
purpose.
All target architectures have nowadays also a "none" machine, which would
be a perfect match for this, too - but it currently does not allow to add
CPU and RAM yet. Thus let's add these possibilities in a generic way to the
"none" machine, too, so that we hopefully do not need additional "dummy"
machines in the future anymore (and maybe can also get rid of the already
existing "dummy"/"sim" machines one day).
Note that the default behaviour of the "none" machine is not changed, i.e.
no CPU and no RAM is instantiated by default. You have explicitely got to
specify the CPU model with "-cpu" and the amount of RAM with "-m" to get
these new features.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <1484743490-24721-1-git-send-email-thuth@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@xilinx.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Use @var{firstcpu} and @var{lastcpu} to make the metasyntatic
variables a bit clearer. While doing this, use @var only around
the metasyntatic variables, not including the square brackets and
hyphen.
The semantics of the "cpus" option will be clarified by rewriting
the whole -numa documentation in a follow-up patch.
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20170123180632.28942-2-ehabkost@redhat.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
The existing default_config_files table in arch_init.c has a
single entry, making it completely unnecessary. The whole code
can be replaced by a single qemu_read_config_file() call in vl.c.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20170117180051.11958-1-ehabkost@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
In the numa_post_machine_init(), we use CPU_FOREACH macro to set all
CPUs' namu_node. So, we should make sure that we call it after Qemu
has already initialied all the CPUs.
As we all know, the CPUs can be created by "-smp"(pc_new_cpu) or
"-device"(qdev_device_add) command. But, before the device init,
Qemu execute the numa_post_machine_init earlier. It makes the mapping
of NUMA nodes and CPUs incorrect.
The patch move the numa_post_machine_init func in the appropriate
location.
Signed-off-by: Dou Liyang <douly.fnst@cn.fujitsu.com>
Message-Id: <1484664152-24446-2-git-send-email-douly.fnst@cn.fujitsu.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>