ABM is not available on Sandy Bridge and older, and we want to make the
default CPU runnable in most hosts, so it won't be enabled by default in
KVM mode.
We should eventually have all features supported by TCG enabled by
default in TCG mode, but as we don't have a good mechanism today to
ensure we have different defaults in KVM and TCG mode, disable ABM in
the qemu64 CPU model entirely.
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
SSE4a is not available in any Intel CPU, and we want to make the default
CPU runnable in most hosts, so it doesn't make sense to enable it by
default in KVM mode.
We should eventually have all features supported by TCG enabled by
default in TCG mode, but as we don't have a good mechanism today to
ensure we have different defaults in KVM and TCG mode, disable SSE4a in
the qemu64 CPU model entirely.
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
The default CPU model (qemu64) have some issues today: it enables some
features (ABM and SSE4a) that are not present in many host CPUs. That
means many hosts (but not all of them) had those features silently
disabled in the default configuration in QEMU 2.4 and older.
With the new "check=on" default, this causes warnings to be printed in
the default configuration, because of the lack of SSE4A on all Intel
hosts, and the lack of ABM on Sandy Bridge and older hosts:
$ qemu-system-x86_64 -machine pc,accel=kvm
warning: host doesn't support requested feature: CPUID.80000001H:ECX.abm [bit 5]
warning: host doesn't support requested feature: CPUID.80000001H:ECX.sse4a [bit 6]
Those issues will be fixed in pc-*-2.5 and newer. But as we can't change
the guest ABI in pc-*-2.4, disable "check" mode by default in pc-*-2.4
and older so we don't print spurious warnings.
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Commit "4d77b1f vnc: fix bug: vnc server can't start when 'to' is
specified" was rebased incorrectly, fix it.
Reported-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Yang Hongyang <hongyang.yang@easystack.cn>
Message-id: 1446714738-22400-1-git-send-email-kraxel@redhat.com
Previously we return -EIO blindly when anything goes wrong. Add a helper
function to parse sense fields and try to make the return code more
meaningful.
This also fixes the default werror configuration (enospc) when we're
using qcow2 on an iscsi lun. The old -EIO not being treated as out of
space error failed to trigger vm stop.
Signed-off-by: Fam Zheng <famz@redhat.com>
Message-Id: <1446699609-11376-1-git-send-email-famz@redhat.com>
[libiscsi 1.9 compatibility - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This patch adds calls to replay functions into the icount setup block.
In record mode number of executed instructions is written to the log.
In replay mode number of istructions to execute is taken from the replay log.
When replayed instructions counter is expired qemu_notify_event()
function is called to wake up the iothread.
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Pavel Dovgalyuk <pavel.dovgaluk@ispras.ru>
Message-Id: <20150917162405.8676.31890.stgit@PASHA-ISP.def.inno>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This patch is required for deterministic replay to generate an exception
by trying executing an instruction without changing icount.
It adds new flag to TB for disabling icount while translating it.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Pavel Dovgalyuk <pavel.dovgaluk@ispras.ru>
Message-Id: <20150917162359.8676.77011.stgit@PASHA-ISP.def.inno>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This patch adds icount event to the replay subsystem. This event corresponds
to execution of several instructions and used to synchronize input events
in the replay phase.
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Pavel Dovgalyuk <pavel.dovgaluk@ispras.ru>
Message-Id: <20150917162354.8676.31351.stgit@PASHA-ISP.def.inno>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This mutex will protect read/write operations for replay log.
Using mutex is necessary because most of the events consist of
several fields stored in the log. The mutex will help to avoid races.
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Pavel Dovgalyuk <pavel.dovgaluk@ispras.ru>
Message-Id: <20150917162348.8676.8628.stgit@PASHA-ISP.def.inno>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This patch adds functions to perform read and write operations
with replay log.
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Pavel Dovgalyuk <pavel.dovgaluk@ispras.ru>
Message-Id: <20150917162342.8676.29445.stgit@PASHA-ISP.def.inno>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This patch adds global variables, defines, function declarations,
and function stubs for deterministic VM replay used by external modules.
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Pavel Dovgalyuk <pavel.dovgaluk@ispras.ru>
Message-Id: <20150917162337.8676.41538.stgit@PASHA-ISP.def.inno>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* fix file handle cleanup on w32
* use non-blocking mode for file handles on w32 to avoid
hangs on guest-file-read/guest-file-write to pipes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJWOl4wAAoJEDNTyc7xCLWEwoEH/3ODu7EZIhUpz471fwFNOKaQ
2E6DBnbyRKZ07/5bgVRH2Pvb3i+JZ51sqZzbxkV3OqN6tgYeTR32oBLtA4ZRrRo/
lEwpOUfkc+nLlqQNc7RittQVGIE5DHs/O4PUQWe5+H3TvkezAZZep+HcBLlE1ECZ
0HXg5fudO6LNJS2zRAw9bELEGYsixYu4+AfmsC6GamrWaU2pIFNE9wlKmRKCQh1N
D0uJBk1JtjWOsU3hpTDYkr/fFSvn6e1euaE8JYyAU+pj5VLnsU7Sb1t5ERkONswF
D/JfXG53r045cIiF2mCXPTWFScbp5kxRcyyRiX+LsAFTj2sZ84VLE6yFShYgnfA=
=+vjx
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/mdroth/tags/qga-pull-2015-11-04-tag' into staging
qemu-ga patch queue
* fix file handle cleanup on w32
* use non-blocking mode for file handles on w32 to avoid
hangs on guest-file-read/guest-file-write to pipes
# gpg: Signature made Wed 04 Nov 2015 19:36:16 GMT using RSA key ID F108B584
# gpg: Good signature from "Michael Roth <flukshun@gmail.com>"
# gpg: aka "Michael Roth <mdroth@utexas.edu>"
# gpg: aka "Michael Roth <mdroth@linux.vnet.ibm.com>"
* remotes/mdroth/tags/qga-pull-2015-11-04-tag:
qga: set file descriptor in qmp_guest_file_open non-blocking on Win32
qga: fixed CloseHandle in qmp_guest_file_open
qga: drop hand-made guest_file_toggle_flags helper
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This reverts commit de9d61e83d.
Now 'cpu_clean_all_dirty' is useless, we can revert the related code.
Conflicts:
include/sysemu/kvm.h
Signed-off-by: Liang Li <liang.z.li@intel.com>
Message-Id: <1446695464-27116-3-git-send-email-liang.z.li@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The commit 317b0a6d8 fixed an issue which caused by the outdated
env->tsc value, but the fix lead to 'cpu_synchronize_all_states()'
called twice during live migration. The 'cpu_synchronize_all_states()'
takes about 130us for a VM which has 4 vcpus, it's a bit expensive.
Synchronize the whole CPU context just for updating env->tsc is too
wasting, this patch use a new function to update the env->tsc.
Comparing to 'cpu_synchronize_all_states()', it only takes about 20us.
Signed-off-by: Liang Li <liang.z.li@intel.com>
Message-Id: <1446695464-27116-2-git-send-email-liang.z.li@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Some versions of clang may have difficulty compiling glibc headers when
-D_FORTIFY_SOURCE is used. For example, Clang++ 3.5.0-9.fc22 cannot
compile glibc's stdio headers when -D_FORTIFY_SOURCE=2 is used. This
manifests currently as build failures with clang and any arm target.
According to LLVM dev Richard Smith, clang does not target or support
FORTIFY_SOURCE + glibc, and it should not be relied on.
"It's still an unsupported combination, and while it might compile, some
of the checks are unlikely to work because they require a frontend
inliner to be useful"
See: http://lists.llvm.org/pipermail/cfe-dev/2015-November/045846.html
Conclusion: disable fortify-source if we appear to be using clang instead
of testing for compile success or failure, which may be incidental or not
indicative of proper support of the feature.
Signed-off-by: John Snow <jsnow@redhat.com>
Message-Id: <1446583422-10153-1-git-send-email-jsnow@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
the idea behind this patch is to allow the buffer to shrink, but
make this a seldom operation. The buffers average size is measured
exponentionally smoothed with am alpha of 1/128.
Signed-off-by: Peter Lieven <pl@kamp.de>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1446203414-4013-20-git-send-email-kraxel@redhat.com
Signed-off-by: Peter Lieven <pl@kamp.de>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1446203414-4013-19-git-send-email-kraxel@redhat.com
Signed-off-by: Peter Lieven <pl@kamp.de>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1446203414-4013-18-git-send-email-kraxel@redhat.com
If the vs->output buffer is empty it will be dropped
by the next qio_buffer_move_empty in vnc_jobs_consume_buffer
anyway. So reuse the allocated buffer from this buffer
in the worker thread where we otherwise would start with
an empty (unallocated buffer).
Signed-off-by: Peter Lieven <pl@kamp.de>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1446203414-4013-17-git-send-email-kraxel@redhat.com
[ added a comment describing the non-obvious optimization ]
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Peter Lieven <pl@kamp.de>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1446203414-4013-16-git-send-email-kraxel@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Peter Lieven <pl@kamp.de>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1446203414-4013-15-git-send-email-kraxel@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Peter Lieven <pl@kamp.de>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1446203414-4013-14-git-send-email-kraxel@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Peter Lieven <pl@kamp.de>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1446203414-4013-13-git-send-email-kraxel@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Peter Lieven <pl@kamp.de>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1446203414-4013-12-git-send-email-kraxel@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Peter Lieven <pl@kamp.de>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1446203414-4013-11-git-send-email-kraxel@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Peter Lieven <pl@kamp.de>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1446203414-4013-10-git-send-email-kraxel@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Peter Lieven <pl@kamp.de>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1446203414-4013-9-git-send-email-kraxel@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Peter Lieven <pl@kamp.de>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1446203414-4013-8-git-send-email-kraxel@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Peter Lieven <pl@kamp.de>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1446203414-4013-7-git-send-email-kraxel@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Peter Lieven <pl@kamp.de>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1446203414-4013-6-git-send-email-kraxel@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Peter Lieven <pl@kamp.de>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1446203414-4013-5-git-send-email-kraxel@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Peter Lieven <pl@kamp.de>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1446203414-4013-3-git-send-email-kraxel@redhat.com
This makes sure the number of reallocs is in O(log N).
Signed-off-by: Peter Lieven <pl@kamp.de>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-id: 1446203414-4013-2-git-send-email-kraxel@redhat.com
[ rebased to util/buffer.c ]
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This allows to explicitly specify file name to use with the backend. This
is important when using it together with ivshmem in order to make it backed
by hugetlbfs. By default filename is autogenerated using mkstemp(), and the
file is unlink()ed after creation, effectively making it anonymous. This is
not very useful with ivshmem because it ends up in a memory which cannot be
accessed by something else.
Distinction between directory and file name is done by stat() check. If an
existing directory is given, the code keeps old behavior. Otherwise it
creates or opens a file with the given pathname.
Signed-off-by: Pavel Fedin <p.fedin@samsung.com>
Tested-by: Igor Skalkin <i.skalkin@samsung.com>
Message-Id: <004301d11166$9672fe30$c358fa90$@samsung.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
If the user is using ccache during the configuration step,
it may interfere with some of the configuration tests,
particularly the "Is ccache interfering with macro analysis" step,
which is a bit of a poetic problem.
1) Disallow ccache from reading from the cache during configure,
but don't disable it entirely to allow us to see if it causes other
problems.
2) Force off CCACHE_CPP2 during the ccache test to get a deterministic
answer over whether or not we need to enable that feature later.
Signed-off-by: John Snow <jsnow@redhat.com>
Message-Id: <1446055000-29150-1-git-send-email-jsnow@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reloading of local variables after sigsetjmp is only needed for some
buggy compilers.
The code which should reload these variables causes compiler warnings
with gcc 4.7 when compiler optimizations are enabled:
cpu-exec.c:204:15: error:
variable ‘cpu’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Werror=clobbered]
cpu-exec.c:207:15: error:
variable ‘cc’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Werror=clobbered]
cpu-exec.c:202:28: error:
argument ‘env’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Werror=clobbered]
Now this code is only used for compilers which need it
(and gcc 4.5.x, x > 0 which does not need it but won't give warnings).
There were bug reports for clang and gcc 4.5.0, while gcc 4.5.1
was reported to work fine without the reload code. For clang it
is not clear which versions are affected, so simply keep the status quo
for all clang compilations. This can be improved later.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Message-Id: <1443266606-21400-1-git-send-email-sw@weilnetz.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This ensures that cpu_reload_memory_map() is called as soon as
tcg_cpu_address_space_init() is called, and before cpu->memory_dispatch
is used. qemu-system-s390x never changes the address spaces after
tcg_cpu_address_space_init() is called, and thus tcg_commit() is never
called. This causes a SIGSEGV.
Because memory_map_init() will now call mem_commit(), we have to
initialize io_mem_* before address_space_memory and friends.
Reported-by: Philipp Kern <pkern@debian.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Fixes: 0a1c71cec6
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Guest visible data shouldn't change with a simple QEMU upgrade, so use
qemu_hw_version() to ensure it won't change (as long as the machine
class being used has hw_version set).
Cc: Hannes Reinecke <hare@suse.de>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-block@nongnu.org
Reviewed-by: Hannes Reinecke <hare@suse.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <1446233769-7892-4-git-send-email-ehabkost@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This makes the purpose of the function clearer: it is not about the
version of QEMU that's running, but the version string exposed in the
emulated hardware.
Cc: Andrzej Zaborowski <balrogg@gmail.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: John Snow <jsnow@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <1446233769-7892-3-git-send-email-ehabkost@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
In 2012, QEMU had a bug where it exposed QEMU version information to the
guest, meaning a QEMU upgrade would expose different hardware to the
guest OS even if the same machine-type is being used.
The bug was fixed by commit 93bfef4c6e, on
all machines up to pc-1.0. But we kept introducing the same bug on all
newer machines since then. That means we are breaking guest ABI every
time QEMU was upgraded.
Fix this by setting the hw_version on all PC machines, making sure the
hardware won't change when upgrading QEMU.
Note that QEMU_VERSION was "1.0" in QEMU 1.0, but starting on QEMU
1.1.0, it started following the "x.y.0" pattern. We have to follow it,
to make sure we use the right QEMU_VERSION string from each QEMU
release.
The 2.5 machine classes could have hw_version unset, because the default
value for qemu_get_version() is QEMU_VERSION. But I decided to set it
explicitly to QEMU_VERSION so we don't forget to update it to "2.5.0"
after we release 2.5.0 and create a 2.6 machine class.
Reported-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <1446233769-7892-2-git-send-email-ehabkost@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
These messages are disabled by default; a perfect usecase for tracepoints,
which in fact already exist. Add the missing information to them and
stop using qemu_log_mask.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
In this mode, referring an invalid element of the source forces the
result to false (table 4-7, last column) but referring an invalid
element of the destination forces the result to true, so the outer
loop should still be run even if some elements of the destination
will be invalid. They will be avoided in the inner loop, which
correctly bounds "i" to validd, but they will still contribute to a
positive outcome of the search.
This fixes tst_strstr in glibc 2.17.
Reported-by: Florian Weimer <fweimer@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Set fd non-blocking to avoid common use cases (like reading from a
named pipe) from hanging the agent. This was missed in the original
code.
The patch introduces qemu_set_handle_nonoblocking, the local analog
of qemu_set_nonblock for HANDLES.
The usage of handles in qemu_set_non/block is impossible, because for
win32 there is a difference between file discriptors and file handles,
and all file ops are made via Win32 api.
Signed-off-by: Olga Krishtal <okrishtal@parallels.com>
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Michael Roth <mdroth@linux.vnet.ibm.com>
CC: Stefan Weil <sw@weilnetz.de>
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
CloseHandle use HANDLE as an argument, but not *HANDLE
Signed-off-by: Olga Krishtal <okrishtal@parallels.com>
Signed-off-by: Denis V. Lunev <den@openvz.org>
Reviewed-by: Stefan Weil <sw@weilnetz.de>
CC: Michael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
