Max Reitz [Tue, 2 Dec 2014 17:32:42 +0000 (18:32 +0100)]
block: Omit bdrv_find_format for essential drivers
We can always assume raw, file and qcow2 being available; so do not use
bdrv_find_format() to locate their BlockDriver objects but statically
reference the respective objects.
Cc: qemu-stable@nongnu.org Signed-off-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit ef8104378c4a0497be079e48ee5ac5a89c68f978) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Max Reitz [Tue, 2 Dec 2014 17:32:41 +0000 (18:32 +0100)]
block: Make essential BlockDriver objects public
There are some block drivers which are essential to QEMU and may not be
removed: These are raw, file and qcow2 (as the default non-raw format).
Make their BlockDriver objects public so they can be directly referenced
throughout the block layer without needing to call bdrv_find_format()
and having to deal with an error at runtime, while the real problem
occurred during linking (where raw, file or qcow2 were not linked into
qemu).
Cc: qemu-stable@nongnu.org Signed-off-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 5f535a941e52229d81e55603eb69b2bd449b937a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Jason Wang [Thu, 27 Nov 2014 10:04:03 +0000 (18:04 +0800)]
virtio-net: fix unmap leak
virtio_net_handle_ctrl() and other functions that process control vq
request call iov_discard_front() which will shorten the iov. This will
lead unmapping in virtqueue_push() leaks mapping.
Fixes this by keeping the original iov untouched and using a temp variable
in those functions.
Cc: Wen Congyang <wency@cn.fujitsu.com> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Cc: qemu-stable@nongnu.org Signed-off-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Reviewed-by: Fam Zheng <famz@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-id: 1417082643-23907-1-git-send-email-jasowang@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 771b6ed37e3aa188a7485560b949a41c6cf174dc) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Don Slutz [Mon, 17 Nov 2014 21:20:39 +0000 (16:20 -0500)]
hw/ide/core.c: Prevent SIGSEGV during migration
The other callers to blk_set_enable_write_cache() in this file
already check for s->blk == NULL.
Signed-off-by: Don Slutz <dslutz@verizon.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: 1416259239-13281-1-git-send-email-dslutz@verizon.com Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 6b896ab261942f441a16836e3fa3c83f3f4488b9)
Peter Maydell [Sun, 16 Nov 2014 19:44:21 +0000 (19:44 +0000)]
exec: Handle multipage ranges in invalidate_and_set_dirty()
The code in invalidate_and_set_dirty() needs to handle addr/length
combinations which cross guest physical page boundaries. This can happen,
for example, when disk I/O reads large blocks into guest RAM which previously
held code that we have cached translations for. Unfortunately we were only
checking the clean/dirty status of the first page in the range, and then
were calling a tb_invalidate function which only handles ranges that don't
cross page boundaries. Fix the function to deal with multipage ranges.
The symptoms of this bug were that guest code would misbehave (eg segfault),
in particular after a guest reboot but potentially any time the guest
reused a page of its physical RAM for new code.
Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 1416167061-13203-1-git-send-email-peter.maydell@linaro.org
(cherry picked from commit f874bf905ff2f8dcc17acbfc61e49a92a6f4d04b) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
zhanghailiang [Fri, 14 Nov 2014 02:18:08 +0000 (10:18 +0800)]
libcacard: fix resource leak
In function connect_to_qemu(), getaddrinfo() will allocate memory
that is stored into server, it should be freed by using freeaddrinfo()
before connect_to_qemu() return.
Cc: qemu-stable@nongnu.org Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 5bbebf622897a59db5da4c468e737bfec4d71280) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Paolo Bonzini [Fri, 7 Nov 2014 13:00:02 +0000 (14:00 +0100)]
virtio-scsi: work around bug in old BIOSes
Old BIOSes left some padding by mistake after the req_size/resp_size.
New QEMU does not like it, thinking it is a bidirectional command.
As a workaround, we can check if the ANY_LAYOUT bit is set; if not, we
always consider the first buffer as the virtio-scsi request/response,
because, back when QEMU did not support ANY_LAYOUT, it expected the
payload to start at the second element of the iovec.
This can show up during migration.
Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 55783a5521a3b1f93ee6a072e414a27c6cfa15f0) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Alexander Graf [Fri, 7 Nov 2014 21:12:48 +0000 (22:12 +0100)]
kvm: Fix memory slot page alignment logic
Memory slots have to be page aligned to get entered into KVM. There
is existing logic that tries to ensure that we pad memory slots that
are not page aligned to the biggest region that would still fit in the
alignment requirements.
Unfortunately, that logic is broken. It tries to calculate the start
offset based on the region size.
Fix up the logic to do the thing it was intended to do and document it
properly in the comment above it.
With this patch applied, I can successfully run an e500 guest with more
than 3GB RAM (at which point RAM starts overlapping subpage memory regions).
Cc: qemu-stable@nongnu.org Signed-off-by: Alexander Graf <agraf@suse.de>
(cherry picked from commit f2a64032a14c642d0ddc9a7a846fc3d737deede5) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Max Filippov [Fri, 7 Nov 2014 18:11:07 +0000 (21:11 +0300)]
target-xtensa: add missing window check for entry
Entry opcode needs to check if moving to new register frame would cause
register window overflow. Entry used in function prologue never
overflows because preceding windowed call* opcode writes return address
to the target register window frame, causing overflow exceptions at the
point of call. But when a sequence of entry opcodes is used for register
window spilling there may not be a call or other opcode that would cause
window check between entries and they would not raise overflow exception
themselves resulting in data corruption.
Cc: qemu-stable@nongnu.org Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
(cherry picked from commit 1b3e71f8ee17ced609213d9b41758110f3c026e9) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
and the HBA will fail to work properly.
Reason is the emulation is not setting the 'DMA transfer done'
status correctly.
Signed-off-by: Hannes Reinecke <hare@suse.de> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit c3543fb5fe4520f03dd4fef04fab7745eeca1c96) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Peter Maydell [Wed, 22 Oct 2014 17:41:07 +0000 (18:41 +0100)]
hw/ppc/spapr_pci.c: Avoid functions not in glib 2.12 (g_hash_table_iter_*)
The g_hash_table_iter_* functions for iterating through a hash table
are not present in glib 2.12, which is our current minimum requirement.
Rewrite the code to use g_hash_table_foreach() instead.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Alexander Graf <agraf@suse.de>
(cherry picked from commit f8833a37c0c6b22ddd57b45e48cfb0f97dbd5af4) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Zhang Haoyu [Tue, 21 Oct 2014 08:38:01 +0000 (16:38 +0800)]
snapshot: add bdrv_drain_all() to bdrv_snapshot_delete() to avoid concurrency problem
If there are still pending i/o while deleting snapshot,
because deleting snapshot is done in non-coroutine context, and
the pending i/o read/write (bdrv_co_do_rw) is done in coroutine context,
so it's possible to cause concurrency problem between above two operations.
Add bdrv_drain_all() to bdrv_snapshot_delete() to avoid this problem.
Signed-off-by: Zhang Haoyu <zhanghy@sangfor.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 201410211637596311287@sangfor.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit 3432a1929ee18e08787ce35476abd74f2c93a17c) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Max Filippov [Sun, 19 Oct 2014 04:39:10 +0000 (08:39 +0400)]
hw/xtensa/xtfpga: treat uImage load address as virtual
U-boot for xtensa always treats uImage load address as virtual address.
This is important when booting uImage on xtensa core with MMUv2, because
MMUv2 has fixed non-identity virtual-to-physical mapping after reset.
Always do virtual-to-physical translation of uImage load address and
load uImage at the translated address. This fixes booting uImage kernels
on dc232b and other MMUv2 cores.
Cc: qemu-stable@nongnu.org Reported-by: Waldemar Brodkorb <mail@waldemar-brodkorb.de> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
(cherry picked from commit 6d2e4530532ca1dbb5e68bdcca12e10931bc6503) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Max Filippov [Sun, 19 Oct 2014 03:42:22 +0000 (07:42 +0400)]
hw/core/loader: implement address translation in uimage loader
Such address translation is needed when load address recorded in uImage
is a virtual address. When the actual load address is requested, return
untranslated address: user that needs the translated address can always
apply translation function to it and those that need it untranslated
don't need to do the inverse translation.
Add translation function pointer and its parameter to uimage_load
prototype. Update all existing users.
No user-visible functional changes.
Cc: qemu-stable@nongnu.org Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Reviewed-by: Alexander Graf <agraf@suse.de>
(cherry picked from commit 25bda50a0c7241dcb247483af2b7f961632020cc) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Aurelien Jarno [Mon, 27 Oct 2014 14:53:35 +0000 (15:53 +0100)]
tcg/mips: fix store softmmu slow path
Commit 9d8bf2d1 moved the softmmu slow path out of line and introduce a
regression at the same time by always calling tcg_out_tlb_load with
is_load=1. This makes impossible to run any significant code under
qemu-system-mips*.
Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: qemu-stable@nongnu.org Reviewed-by: Richard Henderson <rth@twiddle.net> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
(cherry picked from commit 0a2923f8488498000eec54871456aa64a4391da4) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Ting Wang [Mon, 27 Oct 2014 08:51:41 +0000 (16:51 +0800)]
virtio-scsi: sense in virtio_scsi_command_complete
If req->resp.cmd.status is not GOOD, the address of sense for
qemu_iovec_from_buf should be modified from &req->resp to sense.
Cc: qemu-stable@nongnu.org Signed-off-by: Ting Wang <kathy.wangting@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit b7890c40e557f4733b6fcd1eb79af79b70dc8c05) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Petr Matousek [Mon, 27 Oct 2014 11:41:44 +0000 (12:41 +0100)]
vnc: sanitize bits_per_pixel from the client
bits_per_pixel that are less than 8 could result in accessing
non-initialized buffers later in the code due to the expectation
that bytes_per_pixel value that is used to initialize these buffers is
never zero.
To fix this check that bits_per_pixel from the client is one of the
values that the rfb protocol specification allows.
This is CVE-2014-7815.
Signed-off-by: Petr Matousek <pmatouse@redhat.com>
[ kraxel: apply codestyle fix ]
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit e6908bfe8e07f2b452e78e677da1b45b1c0f6829) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Jan Kiszka [Mon, 27 Oct 2014 14:05:10 +0000 (14:05 +0000)]
Make qemu_shutdown_requested signal-safe
qemu_shutdown_requested may be interrupted by qemu_system_killed. If the
latter sets shutdown_requested after qemu_shutdown_requested has read it
but before it was cleared, the shutdown event is lost. Fix this by using
atomic_xchg.
This provides a different fix for the problem which commit 15124e142
attempts to deal with. That commit breaks use of ^C to drop into gdb,
and so this approach is better (and 15124e142 can be reverted).
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Gonglei <arei.gonglei@huawei.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
[PMM: commit message tweak] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 817ef04db2cfa2df04daffd6917f4ea7605f6403) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Ray Strode [Sun, 19 Oct 2014 02:12:49 +0000 (22:12 -0400)]
libcacard: don't free sign buffer while sign op is pending
commit 57f97834efe0c208ffadc9d2959f3d3d55580e52 cleaned up
the cac_applet_pki_process_apdu function to have a single
exit point. Unfortunately, that commit introduced a bug
where the sign buffer can get free'd and nullified while
it's still being used.
This commit corrects the bug by introducing a boolean to
track whether or not the sign buffer should be freed in
the function exit path.
Signed-off-by: Ray Strode <rstrode@redhat.com> Reviewed-by: Alon Levy <alon@pobox.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit 81b49e8f892a977f3821f3416ea51aa641d63ac4) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Max Reitz [Thu, 16 Oct 2014 13:25:56 +0000 (15:25 +0200)]
qcow2: Do not overflow when writing an L1 sector
While writing an L1 table sector, qcow2_write_l1_entry() copies the
respective range from s->l1_table to the local "buf" array. The size of
s->l1_table does not have to be a multiple of L1_ENTRIES_PER_SECTOR;
thus, limit the index which is used for copying all entries to the L1
size.
Cc: qemu-stable@nongnu.org Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Peter Lieven <pl@kamp.de> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit a1391444fe1cfef14976458f3293a2c6945e725c) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Gerd Hoffmann [Mon, 6 Oct 2014 09:58:22 +0000 (11:58 +0200)]
vmware-vga: use vmsvga_verify_rect in vmsvga_update_rect
Switch vmsvga_update_rect over to use vmsvga_verify_rect. Slight change
in behavior: We don't try to automatically fixup rectangles any more.
In case we find invalid update requests we'll do a full-screen update
instead.
Cc: qemu-stable@nongnu.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Don Koch <dkoch@verizon.com>
(cherry picked from commit 1735fe1edba9cc86bc0f26937ed5a62d3cb47c9c) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Gerd Hoffmann [Mon, 6 Oct 2014 09:42:34 +0000 (11:42 +0200)]
vmware-vga: CVE-2014-3689: turn off hw accel
Quick & easy stopgap for CVE-2014-3689: We just compile out the
hardware acceleration functions which lack sanity checks. Thankfully
we have capability bits for them (SVGA_CAP_RECT_COPY and
SVGA_CAP_RECT_FILL), so guests should deal just fine, in theory.
Subsequent patches will add the missing checks and re-enable the
hardware acceleration emulation.
Cc: qemu-stable@nongnu.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Don Koch <dkoch@verizon.com>
(cherry picked from commit 83afa38eb20ca27e30683edc7729880e091387fc) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Jan Kiszka [Wed, 30 Jul 2014 07:01:59 +0000 (09:01 +0200)]
pc: Fix disabling of vapic for compat PC models
We used to be able to address both the QEMU and the KVM APIC via "apic".
This doesn't work anymore. So we need to use their parent class to turn
off the vapic on machines that should not expose them.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit df1fd4b541b3ae0dc44843741363d00080775294) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
virtio-9p: fix virtio-9p child refcount in transports
object_initialize() leaves the object with a refcount of 1.
object_property_add_child() adds its own reference which is
dropped again when the property is deleted.
The upshot of this is that we always have a refcount >= 1. Upon
unplug the virtio-9p child is not finalized!
Drop our reference after the child property has been added to the
parent.
Signed-off-by: Gonglei <arei.gonglei@huawei.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 8f3d60e568f53cb3ccdedd917f8e49cdb304973b) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
virtio-9p: use aliases instead of duplicate qdev properties
virtio-9p-pci all duplicate the qdev properties of their
V9fsState child. This approach does not work well with
string or pointer properties since we must be careful
about leaking or double-freeing them.
Use the QOM alias property to forward property accesses to the
V9fsState child. This way no duplication is necessary.
Signed-off-by: Gonglei <arei.gonglei@huawei.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 48833071d955406ebeddc365a8df8b5cb12b035f) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
virtio-balloon: fix virtio-balloon child refcount in transports
object_initialize() leaves the object with a refcount of 1.
object_property_add_child() adds its own reference which is dropped
again when the property is deleted.
The upshot of this is that we always have a refcount >= 1. Upon hot
unplug the virtio-balloon child is not finalized!
Drop our reference after the child property has been added to the
parent.
Signed-off-by: Gonglei <arei.gonglei@huawei.com> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 91ba21208839643603e7f7fa5864723c3f371ebe) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
virtio-rng: fix virtio-rng child refcount in transports
object_initialize() leaves the object with a refcount of 1.
object_property_add_child() adds its own reference which is dropped
again when the property is deleted.
The upshot of this is that we always have a refcount >= 1. Upon hot
unplug the virtio-rng child is not finalized!
Drop our reference after the child property has been added to the
parent.
Signed-off-by: Gonglei <arei.gonglei@huawei.com> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 352fa88dfb2e9c72fa2a1506acb39f349d4befbf) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
virtio-rng: use aliases instead of duplicate qdev properties
virtio-rng-{pci, s390, ccw} all duplicate the
qdev properties of their VirtIORNG child.
This approach does not work well with string or pointer
properties since we must be careful about leaking or
double-freeing them.
Use the QOM alias property to forward property accesses to the
VirtIORNG child. This way no duplication is necessary.
Signed-off-by: Gonglei <arei.gonglei@huawei.com> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 8ee486ae339f0e5236f4a9ab988fc963edcc73b5) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
virtio-serial: fix virtio-serial child refcount in transports
object_initialize() leaves the object with a refcount of 1.
object_property_add_child() adds its own reference which is dropped
again when the property is deleted.
The upshot of this is that we always have a refcount >= 1. Upon hot
unplug the virtio-serial child is not finalized!
Drop our reference after the child property has been added to the
parent.
Signed-off-by: Gonglei <arei.gonglei@huawei.com> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit e77ca8b92af8a5213897331d676089e8919f383d) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
virtio-serial: use aliases instead of duplicate qdev properties
virtio-serial-{pci, s390, ccw} all duplicate the
qdev properties of their VirtIOSerial child.
This approach does not work well with string or pointer
properties since we must be careful about leaking or
double-freeing them.
Use the QOM alias property to forward property accesses to the
VirtIOSerial child. This way no duplication is necessary.
Signed-off-by: Gonglei <arei.gonglei@huawei.com> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 4f456d8025c7259c66b2b2bcec99d5c6c94d99be) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
virtio/vhost-scsi: fix virtio-scsi/vhost-scsi child refcount in transports
object_initialize() leaves the object with a refcount of 1.
object_property_add_child() adds its own reference which is dropped
again when the property is deleted.
The upshot of this is that we always have a refcount >= 1. Upon hot
unplug the virtio-scsi/vhost-scsi child is not finalized!
Drop our reference after the child property has been added to the
parent.
Signed-off-by: Gonglei <arei.gonglei@huawei.com> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 1312f12bcc8911ed99b67227fb9d1607295f71ed) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
virtio/vhost-scsi: use aliases instead of duplicate qdev properties
{virtio, vhost}-scsi-{pci, s390, ccw} all duplicate the
qdev properties of their VirtIOSCSI/VHostSCSI child.
This approach does not work well with string or pointer
properties since we must be careful about leaking or
double-freeing them.
Use the QOM alias property to forward property accesses to the
VirtIOSCSI/VHostSCSI child. This way no duplication is necessary.
Signed-off-by: Gonglei <arei.gonglei@huawei.com> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit c39343fd811a22c921fc08e9e6ca62c8e7539264) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
virtio-net: fix virtio-net child refcount in transports
object_initialize() leaves the object with a refcount of 1.
object_property_add_child() adds its own reference which is dropped
again when the property is deleted.
The upshot of this is that we always have a refcount >= 1. Upon hot
unplug the virtio-net child is not finalized!
Drop our reference after the child property has been added to the
parent.
Signed-off-by: Gonglei <arei.gonglei@huawei.com> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 6a0c6b59788627541faf70864464f1e155dc18d7) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
virtio-net: use aliases instead of duplicate qdev properties
virtio-net-pci, virtio-net-s390, and virtio-net-ccw all duplicate the
qdev properties of their VirtIONet child. This approach does not work
well with string or pointer properties since we must be careful about
leaking or double-freeing them.
Use the QOM alias property to forward property accesses to the
VirtIONet child. This way no duplication is necessary.
Signed-off-by: Gonglei <arei.gonglei@huawei.com> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 7779edfeb1822ff5f554a4c1f3e9798789a9352c) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Paolo Bonzini [Wed, 17 Sep 2014 10:40:07 +0000 (12:40 +0200)]
vhost-scsi: use virtio_ldl_p
This helps for cross-endian configurations.
Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 7ce0425575745a40e94e75426607e0bec17899fa) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
QEMU currently allows the number of VCPUs to not be a multiple of the
number of threads per socket, but the smbios socket count calculation
introduced by commit c97294ec1b9e36887e119589d456557d72ab37b5 doesn't
take that into account, triggering an assertion. e.g.:
Socket count calculation doesn't belong to smbios.c and should
eventually be moved to the main SMP topology configuration code. But
while we don't move the code, at least make it correct by rounding up
the division.
Cc: Gabriel Somlo <somlo@cmu.edu> Cc: qemu-stable@nongnu.org Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-By: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 7dfddd7f884b6dd2abf230d8fa6c7c83aab4f5ec) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Michael Roth [Thu, 18 Sep 2014 22:59:33 +0000 (17:59 -0500)]
tests: avoid running duplicate qom-tests
Since 3687d532 we've been unconditionally adding qom-test to our qtests
for every arch. However, some archs inherit their tests from Makefile
variables for other archs, such as i386/x86_64,
microblaze/microblazeel, and xtensa/xtensaeb. Since these are evaluated
in a lazy manner, we ultimately end up adding qom-test twice.
In the case x86_64, where we have a large number of machine types that
we rerun qom-test for, this has lead to a fairly noticeable increase
in the overall run-time of `make check` (78s vs. 42s on my machine).
Similar speed-ups are visible for other such archs, but not nearly as
significant.
Fix this by only adding qom-test to an arch's test list if it's not
already present.
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Andreas Färber <afaerber@suse.de> Cc: qemu-stable@nongnu.org Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(cherry picked from commit 2b8419cb4911731db6c883fa7b0428ad4a355d9d) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
pc-dimm: Don't check dimm->node when there is non-NUMA config
It should not break memory hotplug feature if there is non-NUMA option.
This patch would also allow to use pc-dimm as replacement for initial memory
for non-NUMA configs.
Note: After this patch, the memory hotplug can work normally for Linux guest OS
when there is non-NUMA option and NUMA option. But not support Windows guest OS
to hotplug memory with no-NUMA config, actully, it's Windows limitation.
Reviewed-By: Igor Mammedov <imammedo@redhat.com> Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit fc50ff0666315be5120c70ad00cd0b0097484b84) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Andreas Färber [Mon, 15 Sep 2014 16:40:08 +0000 (18:40 +0200)]
ivshmem: Fix fd leak on error
Reported-by: Stefan Hajnoczi <stefanha@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Andreas Färber <afaerber@suse.de> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 3a31cff11203bf62ebafa6d74b1fcf2aba345eed) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Fix OOB access via malformed incoming_posn parameters
and check that requested memory is actually alloc'ed.
Signed-off-by: Sebastian Krahmer <krahmer@suse.de>
[AF: Rebased, cleanups, avoid fd leak] Cc: qemu-stable@nongnu.org Signed-off-by: Andreas Färber <afaerber@suse.de> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 34bc07c5282a631c2663ae1ded0a186f46f64612) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Stefan Hajnoczi [Mon, 15 Sep 2014 16:40:06 +0000 (18:40 +0200)]
ivshmem: validate incoming_posn value from server
Check incoming_posn to avoid out-of-bounds array accesses if the ivshmem
server on the host sends invalid values.
Cc: Cam Macdonell <cam@cs.ualberta.ca> Reported-by: Sebastian Krahmer <krahmer@suse.de> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
[AF: Tighten upper bound check for posn in close_guest_eventfds()] Cc: qemu-stable@nongnu.org Signed-off-by: Andreas Färber <afaerber@suse.de> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 363ba1c72fed4425e7917afc36722584aaeaad8a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Stefan Hajnoczi [Mon, 15 Sep 2014 16:40:05 +0000 (18:40 +0200)]
ivshmem: Check ivshmem_read() size argument
The third argument to the fd_read() callback implemented by
ivshmem_read() is the number of bytes, not a flags field. Fix this and
check we received enough bytes before accessing the buffer pointer.
Cc: Cam Macdonell <cam@cs.ualberta.ca> Reported-by: Sebastian Krahmer <krahmer@suse.de> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
[AF: Handle partial reads via FIFO] Reported-by: Peter Maydell <peter.maydell@linaro.org> Cc: qemu-stable@nongnu.org Signed-off-by: Andreas Färber <afaerber@suse.de> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit a2e9011b4164894594bf0b2a2a59e9c55c58c17b) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Header length check should happen only if backend is kernel. For user
backend there is no reason to reset this bit.
vhost-user code does not define .has_vnet_hdr_len so
VIRTIO_NET_F_MRG_RXBUF cannot be negotiated even if both sides
support it.
Signed-off-by: Damjan Marion <damarion@cisco.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit d8e80ae37a7acfea416ad9abbe76b453a73d9cc0) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
virtio-balloon: fix integer overflow in memory stats feature
When a QMP client changes the polling interval time by setting
the guest-stats-polling-interval property, the interval value
is stored and manipulated as an int64_t variable.
However, the balloon_stats_change_timer() function, which is
used to set the actual timer with the interval value, takes
an int instead, causing an overflow for big interval values.
This commit fix this bug by changing balloon_stats_change_timer()
to take an int64_t and also it limits the polling interval value
to UINT_MAX to avoid other kinds of overflow.
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com>
(cherry picked from commit 1f9296b51a26650916a2c4191268bb64057bdc5f) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit cdaa86a54 ("Add G_IO_HUP handler for socket chardev") exposed a bug in
the way the HMP monitor handles its command buffer. When a client closes the
connection to the monitor, tcp_chr_read() will detect the G_IO_HUP condition
and call tcp_chr_disconnect() to close the server-side connection too. Due to
the fact that monitor reads 1 byte at a time (for each tcp_chr_read()), the
monitor readline state / buffers might contain junk (i.e. a half-finished
command). Thus, without calling readline_restart() on mon->rs in
CHR_EVENT_OPEN, future HMP commands will fail.
Michael Roth [Thu, 18 Sep 2014 20:36:42 +0000 (15:36 -0500)]
tests: add QMP input visitor test for unions with no discriminator
This is more of an exercise of the dealloc visitor, where it may
erroneously use an uninitialized discriminator field as indication
that union fields corresponding to that discriminator field/type are
present, which can lead to attempts to free random chunks of heap
memory.
Cc: qemu-stable@nongnu.org Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
(cherry picked from commit cb55111b4e425fa3279302fa7306b9a3d5164ff4) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Michael Roth [Thu, 18 Sep 2014 20:36:40 +0000 (15:36 -0500)]
qapi: add visit_start_union and visit_end_union
In some cases an input visitor might bail out on filling out a
struct for various reasons, such as missing fields when running
in strict mode. In the case of a QAPI Union type, this may lead
to cases where the .kind field which encodes the union type
is uninitialized. Subsequently, other visitors, such as the
dealloc visitor, may use this .kind value as if it were
initialized, leading to assumptions about the union type which
in this case may lead to segfaults. For example, freeing an
integer value.
However, we can generally rely on the fact that the always-present
.data void * field that we generate for these union types will
always be NULL in cases where .kind is uninitialized (at least,
there shouldn't be a reason where we'd do this purposefully).
So pass this information on to Visitor implementation via these
optional start_union/end_union interfaces so this information
can be used to guard against the situation above. We will make
use of this information in a subsequent patch for the dealloc
visitor.
Cc: qemu-stable@nongnu.org Reported-by: Fam Zheng <famz@redhat.com> Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
(cherry picked from commit cee2dedb85b97e4976c83bea84064c3921b8b7ac) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Pavel Dovgalyuk [Wed, 10 Sep 2014 14:34:14 +0000 (18:34 +0400)]
gdbstub: init mon_chr through qemu_chr_alloc
This patch initializes monitor for gdbstub with the qemu_chr_alloc function
instead of just allocating the memory. Initialization function call
is required, because it also creates chr_write_lock mutex, which is used
when writing to this character device.
Signed-off-by: Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 462efe9e530e22b1b60aaf01716e1423cd94302c) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Peter Maydell [Fri, 12 Sep 2014 13:06:50 +0000 (14:06 +0100)]
hw/arm/virt: fix pl011 and pl031 irq flags
The pl011 and pl031 devices both use level triggered interrupts,
but the device tree we construct was incorrectly telling the
kernel to configure the GIC to treat them as edge triggered.
This meant that output from the pl011 would hang after a while.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 1410274423-9461-1-git-send-email-peter.maydell@linaro.org Acked-by: Christoffer Dall <christoffer.dall@linaro.org> Cc: qemu-stable@nongnu.org
(cherry picked from commit 0be969a2d974971628fc4ed95834d22ecf0fd497) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Greg Kurz [Wed, 27 Aug 2014 16:17:12 +0000 (18:17 +0200)]
spapr_pci: map the MSI window in each PHB
On sPAPR, virtio devices are connected to the PCI bus and use MSI-X.
Commit cc943c36faa192cd4b32af8fe5edb31894017d35 has modified MSI-X
so that writes are made using the bus master address space and follow
the IOMMU path.
Unfortunately, the IOMMU address space address space does not have an
MSI window: the notification is silently dropped in unassigned_mem_write
instead of reaching the guest... The most visible effect is that all
virtio devices are non-functional on sPAPR since then. :(
This patch does the following:
1) map the MSI window into the IOMMU address space for each PHB
- since each PHB instantiates its own IOMMU address space, we
can safely map the window at a fixed address (SPAPR_PCI_MSI_WINDOW)
- no real need to keep the MSI window setup in a separate function,
the spapr_pci_msi_init() code moves to spapr_phb_realize().
2) kill the global MSI window as it is not needed in the end
Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com> Signed-off-by: Alexander Graf <agraf@suse.de>
(cherry picked from commit 8c46f7ec85a4dd9663489b2fa2b425cd7b3653e1) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
commit cc943c36faa192cd4b32af8fe5edb31894017d35
pci: Use bus master address space for delivering MSI/MSI-X messages
breaks virtio-net for rhel6.[56] x86 guests because they don't
enable bus mastering for virtio PCI devices. For the same reason,
rhel6.[56] ppc64 guests cannot boot on a virtio-blk disk anymore.
Old guests forgot to enable bus mastering, enable it automatically on
DRIVER (guests use some devices before DRIVER_OK).
Reported-by: Greg Kurz <gkurz@linux.vnet.ibm.com> Reviewed-by: Greg Kurz <gkurz@linux.vnet.ibm.com> Tested-by: Greg Kurz <gkurz@linux.vnet.ibm.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit e43c0b2ea5574efb0bedebf6a7d05916eefeba52) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Jan Kiszka [Sun, 27 Jul 2014 07:08:29 +0000 (09:08 +0200)]
pci: Use bus master address space for delivering MSI/MSI-X messages
The spec says (and real HW confirms this) that, if the bus master bit
is 0, the device will not generate any PCI accesses. MSI and MSI-X
messages fall among these, so we should use the corresponding address
space to deliver them. This will prevent delivery if bus master support
is disabled.
Cc: qemu-stable@nongnu.org Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit cc943c36faa192cd4b32af8fe5edb31894017d35) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Alexander Graf [Fri, 5 Sep 2014 13:52:45 +0000 (10:52 -0300)]
kvmclock: Ensure time in migration never goes backward
When we migrate we ask the kernel about its current belief on what the guest
time would be. However, I've seen cases where the kvmclock guest structure
indicates a time more recent than the kvm returned time.
To make sure we never go backwards, calculate what the guest would have seen as time at the point of migration and use that value instead of the kernel returned one when it's more recent.
This bases the view of the kvmclock after migration on the
same foundation in host as well as guest.
Signed-off-by: Alexander Graf <agraf@suse.de> Cc: qemu-stable@nongnu.org Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 9a48bcd1b82494671c111109b0eefdb882581499) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Add back the PCIe config capabilities on XHCI cards in non-PCIe slots,
but only for machine types before 2.1.
This fixes a migration incompatibility in the XHCI PCI devices
caused by: 058fdcf52cdbf57b67e7 - xhci: add endpoint cap on express bus only
Note that in fixing it for compatibility with older QEMUs, it breaks
compatibility with existing QEMU 2.1's on older machine types.
The status before this patch was (if it used an XHCI adapter):
machine type | source qemu
any pre-2.1 - FAIL
any 2.1... - PASS
With this patch:
machine type | source qemu
any pre-2.1 - PASS
pre-2.1 2.1... - FAIL
2.1 2.1... - PASS
A test to trigger it is to add '-device nec-usb-xhci,id=xhci,addr=0x12'
to the command line.
Cc: qemu-stable@nongnu.org Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit e6043e92c2812a56b8f6cf35d5512067c746ce21) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
qdev: Add cleanup logic in device_set_realized() to avoid resource leak
At present, this function doesn't have partial cleanup implemented,
which will cause resource leaks in some scenarios.
Example:
1. Assume that "dc->realize(dev, &local_err)" executes successful
and local_err == NULL;
2. device hotplug in hotplug_handler_plug() executes but fails
(it is prone to occur). Then local_err != NULL;
3. error_propagate(errp, local_err) and return. But the resources
which have been allocated in dc->realize() will be leaked.
Simple backtrace:
dc->realize()
|->device_realize
|->pci_qdev_init()
|->do_pci_register_device()
|->etc.
Add fuller cleanup logic which assures that function can
goto appropriate error label as local_err population is
detected at each relevant point.
Signed-off-by: Gonglei <arei.gonglei@huawei.com> Reviewed-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com> Cc: qemu-stable@nongnu.org Signed-off-by: Andreas Färber <afaerber@suse.de>
(cherry picked from commit 1d45a705fc007a13f20d18473290082eae6d1725) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
qdev: Use NULL instead of local_err for qbus_child unrealize
Forcefully unrealize all children regardless of errors in earlier
iterations (if any). We should keep going with cleanup operation
rather than report an error immediately. Therefore store the first
child unrealization failure and propagate it at the end. We also
forcefully unregister vmsd and unrealize actual object, too.
Signed-off-by: Gonglei <arei.gonglei@huawei.com> Reviewed-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com> Cc: qemu-stable@nongnu.org Signed-off-by: Andreas Färber <afaerber@suse.de>
(cherry picked from commit cd4520adcab70dbac8db3fe4d41836dca63715a4) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Petr Matousek [Thu, 18 Sep 2014 06:35:37 +0000 (08:35 +0200)]
slirp: udp: fix NULL pointer dereference because of uninitialized socket
When guest sends udp packet with source port and source addr 0,
uninitialized socket is picked up when looking for matching and already
created udp sockets, and later passed to sosendto() where NULL pointer
dereference is hit during so->slirp->vnetwork_mask.s_addr access.
Fix this by checking that the socket is not just a socket stub.
This is CVE-2014-3640.
Signed-off-by: Petr Matousek <pmatouse@redhat.com> Reported-by: Xavier Mehrenberger <xavier.mehrenberger@airbus.com> Reported-by: Stephane Duverger <stephane.duverger@eads.net> Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Message-id: 20140918063537.GX9321@dhcp-25-225.brq.redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 01f7cecf0037997cb0e58ec0d56bf9b5a6f7cb2a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Since QEMU 2.1, we are allocating more space for ACPI tables, so no
space is left after initrd for the BIOS to allocate memory.
Besides ACPI tables, there are a few other uses of high memory in
SeaBIOS: SMBIOS tables and USB drivers use it in particular. These uses
allocate a very small amount of memory. Malloc metadata also lives
there. So we need _some_ extra padding there to avoid initrd breakage,
but not much.
John Snow found a case where RHEL5 was broken by the recent change to
ACPI_TABLE_SIZE; in his case 4KB of extra padding are fine, but just to
be safe I am adding 32KB, which is roughly the same amount of padding
that was left by QEMU 2.0 and earlier.
Move initrd to leave some space for the BIOS.
Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reported-by: John Snow <jsnow@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 438f92ee9f6a4f78f8adcc399809e252b6da72a2) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
This reverts commit a1bc7b827e422e1ff065640d8ec5347c4aadfcd8.
virtio: don't call device on !vm_running
It turns out that virtio net assumes that vm_running
is updated before device status callback in many places,
so this change leads to asserts.
Previous commit fixes the root issue that motivated a1bc7b827e422e1ff065640d8ec5347c4aadfcd8 differently,
so there's no longer a need for this change.
In the future, we might be able to drop checking vm_running
completely, and check vm state directly.
Reported-by: Dietmar Maurer <dietmar@proxmox.com> Cc: qemu-stable@nongnu.org Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 9e8e8c48653471fa5fed447e388fdef57d4f6998) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
On vm stop, vm_running state set to stopped
before device is notified, so callbacks can get envoked with
vm_running = false; and this is not an error.
Cc: qemu-stable@nongnu.org Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 131c5221fe25a9547c4a388a3d26ff7fd14843e5) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Cc: qemu-stable@nongnu.org Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit abb4d5f2e2830b7a6dc4ddcc612dfab15e3a320d) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Eduardo Habkost [Wed, 6 Aug 2014 18:18:21 +0000 (15:18 -0300)]
hw/machine: Free old values of string properties
Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel.a@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Amos Kong <akong@redhat.com> Cc: qemu-stable@nongnu.org
(cherry picked from commit 556068eed04b7f11187aabd89b981552d8d0c30e) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Eduardo Habkost [Wed, 20 Aug 2014 20:30:12 +0000 (17:30 -0300)]
target-i386: Support migratable=no properly
When the "migratable" property was implemented, the behavior was tested
by changing the default on the code, but actually using the option on
the command-line (e.g. "-cpu host,migratable=false") doesn't work as
expected. This is a regression for a common use case of "-cpu host",
which is to enable features that are supported by the host CPU + kernel
before feature-specific code is added to QEMU.
Fix this by initializing the feature words for "-cpu host" on
x86_cpu_parse_featurestr(), right after parsing the CPU options.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com> Cc: qemu-stable@nongnu.org Signed-off-by: Andreas Färber <afaerber@suse.de>
(cherry picked from commit 4d1b279b0675a8b483a5f101212d1dedfb1a3cec) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Pavel Dovgaluk [Thu, 31 Jul 2014 05:41:17 +0000 (09:41 +0400)]
exec: Save CPUState::exception_index field
This patch adds a subsection with exception_index field to the VMState for
correct saving the CPU state.
Without this patch, simulator could miss the pending exception in the saved
virtual machine state.
Signed-off-by: Pavel Dovgalyuk <pavel.dovgaluk@ispras.ru> Cc: qemu-stable@nongnu.org Signed-off-by: Andreas Färber <afaerber@suse.de>
(cherry picked from commit 6c3bff0ed8a40921464b9a07aa0fe079e860c978) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Sebastian Tanase [Mon, 28 Jul 2014 11:39:14 +0000 (13:39 +0200)]
pty: Fix byte loss bug when connecting to pty
When trying to print data to the pty, we first check if it is connected.
If not, we try to reconnect, but we drop the pending data even if we
have successfully reconnected; this makes us lose the first byte of the very
first transmission.
This small fix addresses the issue by checking once more if the pty is connected
after having tried to reconnect.
Signed-off-by: Sebastian Tanase <sebastian.tanase@openwide.fr> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit cf7330c759345de2efe9c0df7921189ac5ff11d3) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Related spice-only bug. We have a fixed 16 MB buffer here, being
presented to the spice-server as qxl video memory in case spice is
used with a non-qxl card. It's also used with qxl in vga mode.
When using display resolutions requiring more than 16 MB of memory we
are going to overflow that buffer. In theory the guest can write,
indirectly via spice-server. The spice-server clears the memory after
setting a new video mode though, triggering a segfault in the overflow
case, so qemu crashes before the guest has a chance to do something
evil.
Fix that by switching to dynamic allocation for the buffer.
Gerd Hoffmann [Tue, 26 Aug 2014 13:35:23 +0000 (15:35 +0200)]
vbe: rework sanity checks
Plug a bunch of holes in the bochs dispi interface parameter checking.
Add a function doing verification on all registers. Call that
unconditionally on every register write. That way we should catch
everything, even changing one register affecting the valid range of
another register.
Some of the holes have been added by commit e9c6149f6ae6873f14a12eea554925b6aa4c4dec. Before that commit the
maximum possible framebuffer (VBE_DISPI_MAX_XRES * VBE_DISPI_MAX_YRES *
32 bpp) has been smaller than the qemu vga memory (8MB) and the checking
for VBE_DISPI_MAX_XRES + VBE_DISPI_MAX_YRES + VBE_DISPI_MAX_BPP was ok.
Some of the holes have been there forever, such as
VBE_DISPI_INDEX_X_OFFSET and VBE_DISPI_INDEX_Y_OFFSET register writes
lacking any verification.
Security impact:
(1) Guest can make the ui (gtk/vnc/...) use memory rages outside the vga
frame buffer as source -> host memory leak. Memory isn't leaked to
the guest but to the vnc client though.
(2) Qemu will segfault in case the memory range happens to include
unmapped areas -> Guest can DoS itself.
The guest can not modify host memory, so I don't think this can be used
by the guest to escape.
Gerd Hoffmann [Tue, 26 Aug 2014 12:16:30 +0000 (14:16 +0200)]
vbe: make bochs dispi interface return the correct memory size with qxl
VgaState->vram_size is the size of the pci bar. In case of qxl not the
whole pci bar can be used as vga framebuffer. Add a new variable
vbe_size to handle that case. By default (if unset) it equals
vram_size, but qxl can set vbe_size to something else.
This makes sure VBE_DISPI_INDEX_VIDEO_MEMORY_64K returns correct results
and sanity checks are done with the correct size too.
Cc: qemu-stable@nongnu.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
(cherry picked from commit 54a85d462447c1cb8a1638578a7fd086350b4d2d) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
virtio-net: purge outstanding packets when starting vhost
whenever we start vhost, virtio could have outstanding packets
queued, when they complete later we'll modify the ring
while vhost is processing it.
To prevent this, purge outstanding packets on vhost start.
Cc: qemu-stable@nongnu.org Cc: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit 086abc1ccd0fa5103345adda819e6c6436949579) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
This completes all packets, ensuring that callbacks
will not run when VM is stopped.
Cc: qemu-stable@nongnu.org Cc: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit ca77d85e1dbf929ae677a0bac96e9b3edd1704da) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
devices rely on packet callbacks eventually running,
but we violate this rule whenever we purge the queue.
To fix, invoke callbacks on all packets on purge.
Set length to 0, this way callers can detect that
this happened and re-queue if necessary.
Cc: qemu-stable@nongnu.org Cc: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit 07d8084624b3f5cbde7777849147a6a3a862e90a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
On vm stop, virtio changes vm_running state
too soon, so callbacks can get envoked with
vm_running = false;
Cc: qemu-stable@nongnu.org Cc: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit 269bd822e7f5ab80048b05fb7076236ed66ffbce) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
zhanghailiang [Tue, 26 Aug 2014 08:06:17 +0000 (16:06 +0800)]
net: Forbid dealing with packets when VM is not running
For all NICs(except virtio-net) emulated by qemu,
Such as e1000, rtl8139, pcnet and ne2k_pci,
Qemu can still receive packets when VM is not running.
If this happened in *migration's* last PAUSE VM stage, but
before the end of the migration, the new receiving packets will possibly dirty
parts of RAM which has been cached in *iovec*(will be sent asynchronously) and
dirty parts of new RAM which will be missed.
This will lead serious network fault in VM.
To avoid this, we forbid receiving packets in generic net code when
VM is not running.
Bug reproduction steps:
(1) Start a VM which configured at least one NIC
(2) In VM, open several Terminal and do *Ping IP -i 0.1*
(3) Migrate the VM repeatedly between two Hosts
And the *PING* command in VM will very likely fail with message:
'Destination HOST Unreachable', the NIC in VM will stay unavailable unless you
run 'service network restart'
Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com> Reviewed-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit e1d64c084b2cc7e907b4e64026d8c8dba59116f8) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
zhanghailiang [Fri, 29 Aug 2014 03:52:51 +0000 (11:52 +0800)]
acpi-build: Set FORCE_APIC_CLUSTER_MODEL bit for FADT flags
If we start Windows 2008 R2 DataCenter with number of cpu less than 8,
The system will use APIC Flat Logical destination mode as default configuration,
Which has an upper limit of 8 CPUs.
The fault is that VM can not show all processors within Task Manager if
we hot-add cpus when the number of cpus in VM extends the limit of 8.
If we use cluster destination model, the problem will be solved.
Note:
This flag was introduced later than ACPI v1.0 specification while QEMU
generates v1.0 tables only, but...
linux kernel ignores this flag, so patch has no influence on it.
Tested with Win[XPsp3|Srv2003EE|Srv2008DC|Srv2008R2|Srv2012R2], there
isn't BSODs and guests boot just fine. In cases guest doesn't support
cpu-hotplug, cpu becomes visible after reboot and in case the guest
supports cpu-hotplug, it works as expected with this patch.
Cc: qemu-stable@nongnu.org Signed-off-by: huangzhichao <huangzhichao@huawei.com> Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-By: Igor Mammedov <imammedo@redhat.com>
(cherry picked from commit 07b81ed937b37e4c1974626c38e2f192ce08f8f5) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
As vhost core can use backend_features during init, clear it earlier to
avoid using uninitialized memory.
This use would be harmless since vhost scsi ignores the result
anyway, but initializing earlier will help prevent valgrind errors,
and make scsi and net behave similarly.
Cc: qemu-stable@nongnu.org Acked-by: Paolo Bonzini <pbonzini@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 3a1655fc53a2d0375dc0b8cd358405c2cae288e3) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Jason Wang [Wed, 3 Sep 2014 06:25:30 +0000 (14:25 +0800)]
vhost_net: init acked_features to backend_features
commit 2e6d46d77ed328d34a94688da8371bcbe243479b (vhost: add
vhost_get_features and vhost_ack_features) removes the step that
initializes the acked_features to backend_features.
As this field is now uninitialized, vhost initialization will sometimes
fail.
To fix, initialize acked_features on each ack.
Tested-by: Andrey Korolyov <andrey@xdel.ru> Cc: Nikolay Nikolaev <n.nikolaev@virtualopensystems.com> Cc: qemu-stable@nongnu.org Signed-off-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit b49ae9138d5cadb47fb868297fbcdac8292fb666) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Jason Wang [Tue, 19 Aug 2014 04:56:29 +0000 (12:56 +0800)]
vhost_net: start/stop guest notifiers properly
commit a9f98bb5ebe6fb1869321dcc58e72041ae626ad8 "vhost: multiqueue
support" changed the order of stopping the device. Previously
vhost_dev_stop would disable backend and only afterwards, unset guest
notifiers. We now unset guest notifiers while vhost is still
active. This can lose interrupts causing guest networking to fail. In
particular, this has been observed during migration.
To fix this, several other changes are needed:
- remove the hdev->started assertion in vhost.c since we may want to
start the guest notifiers before vhost starts and stop the guest
notifiers after vhost is stopped.
- introduce the vhost_net_set_vq_index() and call it before setting
guest notifiers. This is to guarantee vhost_net has the correct
virtqueue index when setting guest notifiers.
MST: fix up error handling.
Cc: qemu-stable@nongnu.org Cc: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Andrey Korolyov <andrey@xdel.ru> Reported-by: "Zhangjie (HZ)" <zhangjie14@huawei.com> Tested-by: William Dauchy <william@gandi.net> Signed-off-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit cd7d1d26b0a333bf2fca715e332690bbd738c097) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
pci: avoid losing config updates to MSI/MSIX cap regs
Since
commit 95d658002401e2e47a5404298ebe9508846e8a39
msi: Invoke msi/msix_write_config from PCI core
msix config writes are lost, the value written is always 0.
Fix pci_default_write_config to avoid this.
Cc: qemu-stable@nongnu.org Signed-off-by: Knut Omang <knut.omang@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit d7efb7e08e5edaac23b0dc824f72c3f353447c39) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
is incomplete: BH might execute within the same main loop iteration but
after vmstop, so in theory, we might trigger an assertion.
I was unable to reproduce this in practice,
but it seems clear enough that the potential is there, so worth fixing.
Cc: qemu-stable@nongnu.org Reported-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit e8bcf842001739765b8dcc1996d86a0ffd2054d5) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Gerd Hoffmann [Fri, 29 Aug 2014 07:27:52 +0000 (09:27 +0200)]
qxl-render: add more sanity checks
Damn, the dirty rectangle values are signed integers. So the checks
added by commit 788fbf042fc6d5aaeab56757e6dad622ac5f0c21 are not good
enough, we also have to make sure they are not negative.
[ Note: There must be something broken in spice-server so we get
negative values in the first place. Bug opened:
https://bugzilla.redhat.com/show_bug.cgi?id=1135372 ]
Cc: qemu-stable@nongnu.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
(cherry picked from commit 503b3b33feca818baa4459aba286e54a528e5567) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Peter Maydell [Fri, 29 Aug 2014 14:00:28 +0000 (15:00 +0100)]
target-arm: Correct Cortex-A57 ISAR5 and AA64ISAR0 ID register values
We implement the crypto extensions but were incorrectly reporting
ID register values for the Cortex-A57 which did not advertise
crypto. Use the correct values as described in the TRM.
With this fix Linux correctly detects presence of the crypto
features and advertises them in /proc/cpuinfo.
Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 1408718660-7295-1-git-send-email-peter.maydell@linaro.org Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit c379621451e64cad166a60f42e1d67f0438b8d1b) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Peter Maydell [Fri, 29 Aug 2014 14:00:28 +0000 (15:00 +0100)]
target-arm: Fix regression that disabled VFP for ARMv5 CPUs
Commit 2c7ffc414 added support for honouring the CPACR coprocessor
access control register bits which may disable access to VFP
and Neon instructions. However it failed to account for the
fact that the CPACR is only present starting from the ARMv6
architecture version, so it accidentally disabled VFP completely
for ARMv5 CPUs like the ARM926. Linux would detect this as
"no VFP present" and probably fall back to its own emulation,
but other guest OSes might crash or misbehave.
Reported-by: Jakub Jermar <jakub@jermar.eu> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 1408714940-7192-1-git-send-email-peter.maydell@linaro.org Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit ed1f13d607e2c64c66bea49d6f4edaf278d3d246) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Alex Williamson [Thu, 14 Aug 2014 21:39:39 +0000 (15:39 -0600)]
x86: Clear MTRRs on vCPU reset
The SDM specifies (June 2014 Vol3 11.11.5):
On a hardware reset, the P6 and more recent processors clear the
valid flags in variable-range MTRRs and clear the E flag in the
IA32_MTRR_DEF_TYPE MSR to disable all MTRRs. All other bits in the
MTRRs are undefined.
We currently do none of that, so whatever MTRR settings you had prior
to reset is what you have after reset. Usually this doesn't matter
because KVM often ignores the guest mappings and uses write-back
anyway. However, if you have an assigned device and an IOMMU that
allows NoSnoop for that device, KVM defers to the guest memory
mappings which are now stale after reset. The result is that OVMF
rebooting on such a configuration takes a full minute to LZMA
decompress the firmware volume, a process that is nearly instant on
the initial boot.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 9db2efd95e13330075bff027cd682a063d725332) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Alex Williamson [Thu, 14 Aug 2014 21:39:33 +0000 (15:39 -0600)]
x86: kvm: Add MTRR support for kvm_get|put_msrs()
The MTRR state in KVM currently runs completely independent of the
QEMU state in CPUX86State.mtrr_*. This means that on migration, the
target loses MTRR state from the source. Generally that's ok though
because KVM ignores it and maps everything as write-back anyway. The
exception to this rule is when we have an assigned device and an IOMMU
that doesn't promote NoSnoop transactions from that device to be cache
coherent. In that case KVM trusts the guest mapping of memory as
configured in the MTRR.
This patch updates kvm_get|put_msrs() so that we retrieve the actual
vCPU MTRR settings and therefore keep CPUX86State synchronized for
migration. kvm_put_msrs() is also used on vCPU reset and therefore
allows future modificaitons of MTRR state at reset to be realized.
Note that the entries array used by both functions was already
slightly undersized for holding every possible MSR, so this patch
increases it beyond the 28 new entries necessary for MTRR state.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit d1ae67f626c5ed5729e1d8212834291b409d26df) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Alex Williamson [Thu, 14 Aug 2014 21:39:27 +0000 (15:39 -0600)]
x86: Use common variable range MTRR counts
We currently define the number of variable range MTRR registers as 8
in the CPUX86State structure and vmstate, but use MSR_MTRRcap_VCNT
(also 8) to report to guests the number available. Change this to
use MSR_MTRRcap_VCNT consistently.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit d8b5c67b05420d966664664ff287af05b884bdd1) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
William Grant [Sun, 24 Aug 2014 05:13:48 +0000 (15:13 +1000)]
target-i386: Don't forbid NX bit on PAE PDEs and PTEs
Commit e8f6d00c30ed88910d0d985f4b2bf41654172ceb ("target-i386: raise
page fault for reserved physical address bits") added a check that the
NX bit is not set on PAE PDPEs, but it also added it to rsvd_mask for
the rest of the function. This caused any PDEs or PTEs with NX set to be
erroneously rejected, making PAE guests with NX support unusable.
Signed-off-by: William Grant <wgrant@ubuntu.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 1844e68ecabbdfdf0228774bcd5cf0f63ffc2e57) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
projects / thirdparty / qemu.git / log
