Cornelia Huck [Wed, 18 Mar 2020 09:39:19 +0000 (10:39 +0100)]
compat: disable edid on correct virtio-gpu device
Commit bb15791166c1 ("compat: disable edid on virtio-gpu base
device") tried to disable 'edid' on the virtio-gpu base device.
However, that device is not 'virtio-gpu', but 'virtio-gpu-device'.
Fix it.
Fixes: bb15791166c1 ("compat: disable edid on virtio-gpu base device") Reported-by: Lukáš Doktor <ldoktor@redhat.com> Tested-by: Lukáš Doktor <ldoktor@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Message-id: 20200318093919.24942-1-cohuck@redhat.com Cc: qemu-stable@nongnu.org Signed-off-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit 02501fc39381c4dabaf6becdd12c2a4754c3847c) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Prior to 1143ec5ebf4 it was OK to qemu_iovec_from_buf() from aligned-up
buffer to original qiov, as qemu_iovec_from_buf() will stop at qiov end
anyway.
But after 1143ec5ebf4 we assume that bdrv_co_do_copy_on_readv works on
part of original qiov, defined by qiov_offset and bytes. So we must not
touch qiov behind qiov_offset+bytes bound. Fix it.
Cc: qemu-stable@nongnu.org # v4.2 Fixes: 1143ec5ebf4 Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: John Snow <jsnow@redhat.com>
Message-id: 20200312081949.5350-1-vsementsov@virtuozzo.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit 4ab78b19189a81038e744728ed949d09aa477550) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Vitaly Chikunov [Mon, 9 Mar 2020 20:45:57 +0000 (23:45 +0300)]
target/ppc: Fix rlwinm on ppc64
rlwinm cannot just AND with Mask if shift value is zero on ppc64 when
Mask Begin is greater than Mask End and high bits are set to 1.
Note that PowerISA 3.0B says that for `rlwinm' ROTL32 is used, and
ROTL32 is defined (in 3.3.14) so that rotated value should have two
copies of lower word of the source value.
This seems to be another incarnation of the fix from 820724d170
("target-ppc: Fix rlwimi, rlwinm, rlwnm again"), except I leave
optimization when Mask value is less than 32 bits.
Fixes: 7b4d326f47 ("target-ppc: Use the new deposit and extract ops") Cc: qemu-stable@nongnu.org Signed-off-by: Vitaly Chikunov <vt@altlinux.org>
Message-Id: <20200309204557.14836-1-vt@altlinux.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
(cherry picked from commit 94f040aaecf4e41cc68991b80204b1b6886bbdd0) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Assume we have two regions, A and B, and region B is in-flight now,
region A is not yet touched, but it is unallocated and should be
skipped.
Correspondingly, as progress we have
total = A + B
current = 0
If we reset unallocated region A and call progress_reset_callback,
it will calculate 0 bytes dirty in the bitmap and call
job_progress_set_remaining, which will set
total = current + 0 = 0 + 0 = 0
So, B bytes are actually removed from total accounting. When job
finishes we'll have
total = 0
current = B
, which doesn't sound good.
This is because we didn't considered in-flight bytes, actually when
calculating remaining, we should have set (in_flight + dirty_bytes)
as remaining, not only dirty_bytes.
To fix it, let's refactor progress calculation, moving it to block-copy
itself instead of fixing callback. And, of course, track in_flight
bytes count.
We still have to keep one callback, to maintain backup job bytes_read
calculation, but it will go on soon, when we turn the whole backup
process into one block_copy call.
Cc: qemu-stable@nongnu.org Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>
Message-Id: <20200311103004.7649-3-vsementsov@virtuozzo.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit d0ebeca14a585f352938062ef8ddde47fe4d39f9) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
On success path we return what inflate() returns instead of 0. And it
most probably works for Z_STREAM_END as it is positive, but is
definitely broken for Z_BUF_ERROR.
While being here, switch to errno return code, to be closer to
qcow2_compress API (and usual expectations).
Revert condition in if to be more positive. Drop dead initialization of
ret.
Cc: qemu-stable@nongnu.org # v4.0 Fixes: 341926ab83e2b Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20200302150930.16218-1-vsementsov@virtuozzo.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit e7266570f2cf7b3ca2a156c677ee0a59d563458b) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
scsi/qemu-pr-helper: Fix out-of-bounds access to trnptid_list[]
Compile error reported by gcc 10.0.1:
scsi/qemu-pr-helper.c: In function ‘multipath_pr_out’:
scsi/qemu-pr-helper.c:523:32: error: array subscript <unknown> is outside array bounds of ‘struct transportid *[0]’ [-Werror=array-bounds]
523 | paramp.trnptid_list[paramp.num_transportid++] = id;
| ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from scsi/qemu-pr-helper.c:36:
/usr/include/mpath_persist.h:168:22: note: while referencing ‘trnptid_list’
168 | struct transportid *trnptid_list[];
| ^~~~~~~~~~~~
scsi/qemu-pr-helper.c:424:35: note: defined here ‘paramp’
424 | struct prout_param_descriptor paramp;
| ^~~~~~
This highlights an actual implementation issue in function multipath_pr_out.
The variable paramp is declared with type `struct prout_param_descriptor`,
which is a struct terminated by an empty array in mpath_persist.h:
struct transportid *trnptid_list[];
That empty array was filled with code that looked like that:
Signed-off-by: Christophe de Dinechin <dinechin@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 4ce1e15fbc7266a108a7c77a3962644b3935346e) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Stefan Hajnoczi [Fri, 7 Feb 2020 10:46:19 +0000 (10:46 +0000)]
virtio: gracefully handle invalid region caches
The virtqueue code sets up MemoryRegionCaches to access the virtqueue
guest RAM data structures. The code currently assumes that
VRingMemoryRegionCaches is initialized before device emulation code
accesses the virtqueue. An assertion will fail in
vring_get_region_caches() when this is not true. Device fuzzing found a
case where this assumption is false (see below).
Virtqueue guest RAM addresses can also be changed from a vCPU thread
while an IOThread is accessing the virtqueue. This breaks the same
assumption but this time the caches could become invalid partway through
the virtqueue code. The code fetches the caches RCU pointer multiple
times so we will need to validate the pointer every time it is fetched.
Add checks each time we call vring_get_region_caches() and treat invalid
caches as a nop: memory stores are ignored and memory reads return 0.
#0 0x00007ffff5520625 in raise () at /lib64/libc.so.6
#1 0x00007ffff55098d9 in abort () at /lib64/libc.so.6
#2 0x00007ffff55097a9 in _nl_load_domain.cold () at /lib64/libc.so.6
#3 0x00007ffff5518a66 in annobin_assert.c_end () at /lib64/libc.so.6
#4 0x00005555559073da in vring_get_region_caches (vq=<optimized out>) at qemu/hw/virtio/virtio.c:286
#5 vring_get_region_caches (vq=<optimized out>) at qemu/hw/virtio/virtio.c:283
#6 0x000055555590818d in vring_used_flags_set_bit (mask=1, vq=0x5555575ceea0) at qemu/hw/virtio/virtio.c:398
#7 virtio_queue_split_set_notification (enable=0, vq=0x5555575ceea0) at qemu/hw/virtio/virtio.c:398
#8 virtio_queue_set_notification (vq=vq@entry=0x5555575ceea0, enable=enable@entry=0) at qemu/hw/virtio/virtio.c:451
#9 0x0000555555908512 in virtio_queue_set_notification (vq=vq@entry=0x5555575ceea0, enable=enable@entry=0) at qemu/hw/virtio/virtio.c:444
#10 0x00005555558c697a in virtio_blk_handle_vq (s=0x5555575c57e0, vq=0x5555575ceea0) at qemu/hw/block/virtio-blk.c:775
#11 0x0000555555907836 in virtio_queue_notify_aio_vq (vq=0x5555575ceea0) at qemu/hw/virtio/virtio.c:2244
#12 0x0000555555cb5dd7 in aio_dispatch_handlers (ctx=ctx@entry=0x55555671a420) at util/aio-posix.c:429
#13 0x0000555555cb67a8 in aio_dispatch (ctx=0x55555671a420) at util/aio-posix.c:460
#14 0x0000555555cb307e in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at util/async.c:260
#15 0x00007ffff7bbc510 in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
#16 0x0000555555cb5848 in glib_pollfds_poll () at util/main-loop.c:219
#17 os_host_main_loop_wait (timeout=<optimized out>) at util/main-loop.c:242
#18 main_loop_wait (nonblocking=<optimized out>) at util/main-loop.c:518
#19 0x00005555559b20c9 in main_loop () at vl.c:1683
#20 0x0000555555838115 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4441
Reported-by: Alexander Bulekov <alxndr@bu.edu> Cc: Michael Tsirkin <mst@redhat.com> Cc: Cornelia Huck <cohuck@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20200207104619.164892-1-stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit abdd16f4681cc4d6bf84990227b5c9b98e869ccd) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Max Reitz [Tue, 25 Feb 2020 14:31:30 +0000 (15:31 +0100)]
iotests/026: Test EIO on allocation in a data-file
Test what happens when writing data to an external data file, where the
write requires an L2 entry to be allocated, but the data write fails.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20200225143130.111267-4-mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 81311255f217859413c94f2cd9cebf2684bbda94) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Max Reitz [Tue, 25 Feb 2020 14:31:29 +0000 (15:31 +0100)]
iotests/026: Test EIO on preallocated zero cluster
Test what happens when writing data to a preallocated zero cluster, but
the data write fails.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20200225143130.111267-3-mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 31ab00f3747c00fdbb9027cea644b40dd1405480) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Max Reitz [Tue, 25 Feb 2020 14:31:28 +0000 (15:31 +0100)]
qcow2: Fix alloc_cluster_abort() for pre-existing clusters
handle_alloc() reuses preallocated zero clusters. If anything goes
wrong during the data write, we do not change their L2 entry, so we
must not let qcow2_alloc_cluster_abort() free them.
Fixes: 8b24cd141549b5b264baeddd4e72902cfb5de23b Cc: qemu-stable@nongnu.org Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20200225143130.111267-2-mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 3ede935fdbbd5f7b24b4724bbfb8938acb5956d8) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Kevin Wolf [Tue, 11 Feb 2020 09:49:00 +0000 (10:49 +0100)]
iotests: Test copy offloading with external data file
This adds a test for 'qemu-img convert' with copy offloading where the
target image has an external data file. If the test hosts supports it,
it tests both the case where copy offloading is supported and the case
where it isn't (otherwise we just test unsupported twice).
More specifically, the case with unsupported copy offloading tests
qcow2_alloc_cluster_abort() with external data files.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <20200211094900.17315-4-kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit a0cf8daf77548786ced84d773f06fc70571c5d38) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Kevin Wolf [Tue, 11 Feb 2020 09:48:59 +0000 (10:48 +0100)]
qcow2: Fix qcow2_alloc_cluster_abort() for external data file
For external data file, cluster allocations return an offset in the data
file and are not refcounted. In this case, there is nothing to do for
qcow2_alloc_cluster_abort(). Freeing the same offset in the qcow2 file
is wrong and causes crashes in the better case or image corruption in
the worse case.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <20200211094900.17315-3-kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit c3b6658c1a5a3fb24d6c27b2594cf86146f75b22) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Kevin Wolf [Tue, 11 Feb 2020 09:48:58 +0000 (10:48 +0100)]
qcow2: update_refcount(): Reset old_table_index after qcow2_cache_put()
In the case that update_refcount() frees a refcount block, it evicts it
from the metadata cache. Before doing so, however, it returns the
currently used refcount block to the cache because it might be the same.
Returning the refcount block early means that we need to reset
old_table_index so that we reload the refcount block in the next
iteration if it is actually still in use.
Fixes: f71c08ea8e60f035485a512fd2af8908567592f0 Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <20200211094900.17315-2-kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit dea9052ef1ba12c83f17d394c70d7d710ea1dec9) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Alex Bennée [Tue, 25 Feb 2020 17:49:08 +0000 (17:49 +0000)]
tcg: save vaddr temp for plugin usage
While do_gen_mem_cb does copy (via extu_tl_i64) vaddr into a new temp
this won't help if the vaddr temp gets clobbered by the actual
load/store op. To avoid this clobbering we explicitly copy vaddr
before the op to ensure it is live my the time we do the
instrumentation.
Suggested-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Emilio G. Cota <cota@braap.org> Cc: qemu-stable@nongnu.org
Message-Id: <20200225124710.14152-18-alex.bennee@linaro.org>
(cherry picked from commit fcc54ab5c7ca84ae72e8bf3781c33c9193a911aa) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Emilio G. Cota [Tue, 25 Feb 2020 12:47:02 +0000 (12:47 +0000)]
plugins/core: add missing break in cb_to_tcg_flags
Fixes: 54cb65d8588 Reported-by: Robert Henry <robhenry@microsoft.com> Signed-off-by: Emilio G. Cota <cota@braap.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20200105072940.32204-1-cota@braap.org> Cc: qemu-stable@nongnu.org
Message-Id: <20200225124710.14152-12-alex.bennee@linaro.org>
(cherry picked from commit dcc474c69e6a59044b9bb54624bd636cbfd98aa9) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
There is a special quiesce PSW that we check for "shutdown". Otherwise disabled
wait is detected as "crashed". Architecturally we must only check PSW bits
116-127. Fix this.
Cc: qemu-stable@nongnu.org Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Message-Id: <1582204582-22995-1-git-send-email-borntraeger@de.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Acked-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
(cherry picked from commit 8b51c0961cc13e55b26bb6665ec3a341abdc7658) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Finn Thain [Wed, 29 Jan 2020 09:27:49 +0000 (20:27 +1100)]
dp8393x: Don't stop reception upon RBE interrupt assertion
Section 3.4.7 of the datasheet explains that,
The RBE bit in the Interrupt Status register is set when the
SONIC finishes using the second to last receive buffer and reads
the last RRA descriptor. Actually, the SONIC is not truly out of
resources, but gives the system an early warning of an impending
out of resources condition.
RBE does not mean actual receive buffer exhaustion, and reception should
not be stopped. This is important because Linux will not check and clear
the RBE interrupt until it receives another packet. But that won't
happen if can_receive returns false. This bug causes the SONIC to become
deaf (until reset).
Fix this with a new flag to indicate actual receive buffer exhaustion.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Tested-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit c2279bd0a19b35057f2e4c3b4df9a915717d1142) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Finn Thain [Wed, 29 Jan 2020 09:27:49 +0000 (20:27 +1100)]
dp8393x: Don't reset Silicon Revision register
The jazzsonic driver in Linux uses the Silicon Revision register value
to probe the chip. The driver fails unless the SR register contains 4.
Unfortunately, reading this register in QEMU usually returns 0 because
the s->regs[] array gets wiped after a software reset.
Fixes: bd8f1ebce4 ("net/dp8393x: fix hardware reset") Suggested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 083e21bbdde7dbd326baf29d21f49fc3f5614496) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Finn Thain [Wed, 29 Jan 2020 09:27:49 +0000 (20:27 +1100)]
dp8393x: Always update RRA pointers and sequence numbers
These operations need to take place regardless of whether or not
rx descriptors have been used up (that is, EOL flag was observed).
The algorithm is now the same for a packet that was withheld as for
a packet that was not.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Tested-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 80b60673ea598869050c66d95d8339480e4cefd0) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Finn Thain [Wed, 29 Jan 2020 09:27:49 +0000 (20:27 +1100)]
dp8393x: Clear descriptor in_use field to release packet
When the SONIC receives a packet into the last available descriptor, it
retains ownership of that descriptor for as long as necessary.
Section 3.4.7 of the datasheet says,
When the system appends more descriptors, the SONIC releases ownership
of the descriptor after writing 0000h to the RXpkt.in_use field.
The packet can now be processed by the host, so raise a PKTRX interrupt,
just like the normal case.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Tested-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit d9fae13196a31716f45dcddcdd958fbb8e59b35a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Finn Thain [Wed, 29 Jan 2020 09:27:49 +0000 (20:27 +1100)]
dp8393x: Pad frames to word or long word boundary
The existing code has a bug where the Remaining Buffer Word Count (RBWC)
is calculated with a truncating division, which gives the wrong result
for odd-sized packets.
Section 1.4.1 of the datasheet says,
Once the end of the packet has been reached, the serializer will
fill out the last word (16-bit mode) or long word (32-bit mode)
if the last byte did not end on a word or long word boundary
respectively. The fill byte will be 0FFh.
Implement buffer padding so that buffer limits are correctly enforced.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Tested-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 350e7d9a77d3b9ac74d240e4b232db1ebe5c05bc)
*drop context dependencies from b7cbebf2b9d, 1ccda935d4f, and 19f70347731 Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Finn Thain [Wed, 29 Jan 2020 09:27:49 +0000 (20:27 +1100)]
dp8393x: Use long-word-aligned RRA pointers in 32-bit mode
Section 3.4.1 of the datasheet says,
The alignment of the RRA is confined to either word or long word
boundaries, depending upon the data width mode. In 16-bit mode,
the RRA must be aligned to a word boundary (A0 is always zero)
and in 32-bit mode, the RRA is aligned to a long word boundary
(A0 and A1 are always zero).
This constraint has been implemented for 16-bit mode; implement it
for 32-bit mode too.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Tested-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit ea2270279bc2e1635cb6e909e22e17e630198773) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Finn Thain [Wed, 29 Jan 2020 09:27:49 +0000 (20:27 +1100)]
dp8393x: Don't clobber packet checksum
A received packet consumes pkt_size bytes in the buffer and the frame
checksum that's appended to it consumes another 4 bytes. The Receive
Buffer Address register takes the former quantity into account but
not the latter. So the next packet written to the buffer overwrites
the frame checksum. Fix this.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit bae112b80c9c42cea21ee7623c283668c3451c2e)
*drop context dep. on 19f70347731 Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Finn Thain [Wed, 29 Jan 2020 09:27:49 +0000 (20:27 +1100)]
dp8393x: Implement packet size limit and RBAE interrupt
Add a bounds check to prevent a large packet from causing a buffer
overflow. This is defensive programming -- I haven't actually tried
sending an oversized packet or a jumbo ethernet frame.
The SONIC handles packets that are too big for the buffer by raising
the RBAE interrupt and dropping them. Linux uses that interrupt to
count dropped packets.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Tested-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit ada74315270d1dcabf4c9d4fece19df7ef5b9577) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Finn Thain [Wed, 29 Jan 2020 09:27:49 +0000 (20:27 +1100)]
dp8393x: Clear RRRA command register bit only when appropriate
It doesn't make sense to clear the command register bit unless the
command was actually issued.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit a3cce2825a0b12bb717a5106daaca245557cc9ae) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Finn Thain [Wed, 29 Jan 2020 09:27:49 +0000 (20:27 +1100)]
dp8393x: Update LLFA and CRDA registers from rx descriptor
Follow the algorithm given in the National Semiconductor DP83932C
datasheet in section 3.4.7:
At the next reception, the SONIC re-reads the last RXpkt.link field,
and updates its CRDA register to point to the next descriptor.
The chip is designed to allow the host to provide a new list of
descriptors in this way.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Tested-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 5b0c98fcb7ac006bd8efe0e0fecba52c43a9d028)
*drop context dep on 19f70347731 Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Finn Thain [Wed, 29 Jan 2020 09:27:49 +0000 (20:27 +1100)]
dp8393x: Have dp8393x_receive() return the packet size
This function re-uses its 'size' argument as a scratch variable.
Instead, declare a local 'size' variable for that purpose so that the
function result doesn't get messed up.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 9e3cd456d85ad45e72bdba99203302342ce29b3b) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Finn Thain [Wed, 29 Jan 2020 09:27:49 +0000 (20:27 +1100)]
dp8393x: Clean up endianness hacks
According to the datasheet, section 3.4.4, "in 32-bit mode ... the SONIC
always writes long words".
Therefore, use the same technique for the 'in_use' field that is used
everywhere else, and write the full long word.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Tested-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 46ffee9ad43185cbee4182c208bbd534814086ca)
Conflicts:
hw/net/dp8393x.c
*roll in local dependencies on b7cbebf2b9d
*drop functional dep. on 19f70347731 Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Finn Thain [Wed, 29 Jan 2020 09:27:49 +0000 (20:27 +1100)]
dp8393x: Always use 32-bit accesses
The DP83932 and DP83934 have 32 data lines. The datasheet says,
Data Bus: These bidirectional lines are used to transfer data on the
system bus. When the SONIC is a bus master, 16-bit data is transferred
on D15-D0 and 32-bit data is transferred on D31-D0. When the SONIC is
accessed as a slave, register data is driven onto lines D15-D0.
D31-D16 are held TRI-STATE if SONIC is in 16-bit mode. If SONIC is in
32-bit mode, they are driven, but invalid.
Always use 32-bit accesses both as bus master and bus slave.
Force the MSW to zero in bus master mode.
This gets the Linux 'jazzsonic' driver working, and avoids the need for
prior hacks to make the NetBSD 'sn' driver work.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Tested-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 3fe9a838ec3eae1374ced16b63bf56894b2ffbe6) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Finn Thain [Sun, 19 Jan 2020 22:59:21 +0000 (09:59 +1100)]
dp8393x: Mask EOL bit from descriptor addresses
The Least Significant bit of a descriptor address register is used as
an EOL flag. It has to be masked when the register value is to be used
as an actual address for copying memory around. But when the registers
are to be updated the EOL bit should not be masked.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Tested-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 88f632fbb1b3d31d5b6978d28f8735a6ed18b8f5)
Conflicts:
hw/net/dp8393x.c
*drop context dep. on 19f70347731 Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
qcow2_can_store_new_dirty_bitmap works wrong, as it considers only
bitmaps already stored in the qcow2 image and ignores persistent
BdrvDirtyBitmap objects.
So, let's instead count persistent BdrvDirtyBitmaps. We load all qcow2
bitmaps on open, so there should not be any bitmap in the image for
which we don't have BdrvDirtyBitmaps version. If it is - it's a kind of
corruption, and no reason to check for corruptions here (open() and
close() are better places for it).
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-id: 20191014115126.15360-2-vsementsov@virtuozzo.com Reviewed-by: Max Reitz <mreitz@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit a1db8733d28d615bc0daeada6c406a6dd5c5d5ef) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Peter Xu [Mon, 6 Jan 2020 20:34:45 +0000 (13:34 -0700)]
vfio/pci: Don't remove irqchip notifier if not registered
The kvm irqchip notifier is only registered if the device supports
INTx, however it's unconditionally removed. If the assigned device
does not support INTx, this will cause QEMU to crash when unplugging
the device from the system. Change it to conditionally remove the
notifier only if the notify hook is setup.
CC: Eduardo Habkost <ehabkost@redhat.com> CC: David Gibson <david@gibson.dropbear.id.au> CC: Alex Williamson <alex.williamson@redhat.com> Cc: qemu-stable@nongnu.org # v4.2 Reported-by: yanghliu@redhat.com Debugged-by: Eduardo Habkost <ehabkost@redhat.com> Fixes: c5478fea27ac ("vfio/pci: Respond to KVM irqchip change notifier")
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1782678 Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
(cherry picked from commit 0446f8121723b134ca1d1ed0b73e96d4a0a8689d) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Liu Yi L [Fri, 3 Jan 2020 13:28:06 +0000 (21:28 +0800)]
intel_iommu: add present bit check for pasid table entries
The present bit check for pasid entry (pe) and pasid directory
entry (pdire) were missed in previous commits as fpd bit check
doesn't require present bit as "Set". This patch adds the present
bit check for callers which wants to get a valid pe/pdire.
Cc: qemu-stable@nongnu.org Cc: Kevin Tian <kevin.tian@intel.com> Cc: Jacob Pan <jacob.jun.pan@linux.intel.com> Cc: Peter Xu <peterx@redhat.com> Cc: Yi Sun <yi.y.sun@linux.intel.com> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Liu Yi L <yi.l.liu@intel.com>
Message-Id: <1578058086-4288-3-git-send-email-yi.l.liu@intel.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 56fc1e6ac6bde95bc0369d358587f2234d4dddad) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Liu Yi L [Fri, 3 Jan 2020 13:28:05 +0000 (21:28 +0800)]
intel_iommu: a fix to vtd_find_as_from_bus_num()
Ensure the return value of vtd_find_as_from_bus_num() is NULL by
enforcing vtd_bus=NULL. This would help caller of vtd_find_as_from_bus_num()
to decide if any further operation on the returned vtd_bus.
Cc: qemu-stable@nongnu.org Cc: Kevin Tian <kevin.tian@intel.com> Cc: Jacob Pan <jacob.jun.pan@linux.intel.com> Cc: Peter Xu <peterx@redhat.com> Cc: Yi Sun <yi.y.sun@linux.intel.com> Signed-off-by: Liu Yi L <yi.l.liu@intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
Message-Id: <1578058086-4288-2-git-send-email-yi.l.liu@intel.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit a2e1cd41ccfe796529abfd1b6aeb1dd4393762a2) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Yuri Benditovich [Thu, 26 Dec 2019 04:36:49 +0000 (06:36 +0200)]
virtio-net: delete also control queue when TX/RX deleted
https://bugzilla.redhat.com/show_bug.cgi?id=1708480
If the control queue is not deleted together with TX/RX, it
later will be ignored in freeing cache resources and hot
unplug will not be completed.
Cc: qemu-stable@nongnu.org Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com>
Message-Id: <20191226043649.14481-3-yuri.benditovich@daynix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit d945d9f1731244ef341f74ede93120fc9de35913) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Yuri Benditovich [Thu, 26 Dec 2019 04:36:48 +0000 (06:36 +0200)]
virtio: reset region cache when on queue deletion
https://bugzilla.redhat.com/show_bug.cgi?id=1708480
Fix leak of region reference that prevents complete
device deletion on hot unplug.
Cc: qemu-stable@nongnu.org Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com>
Message-Id: <20191226043649.14481-2-yuri.benditovich@daynix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 421afd2fe8dd4603216cbf36081877c391f5a2a4) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Let's make sure calling this twice is harmless -
no known instances, but seems safer.
Suggested-by: Pan Nengyuan <pannengyuan@huawei.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 8cd353ea0fbf0e334e015d833f612799be642296)
*prereq for 421afd2fe8 Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
virtio: add ability to delete vq through a pointer
Devices tend to maintain vq pointers, allow deleting them trough a vq pointer.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com>
(cherry picked from commit 722f8c51d8af223751dfb1d02de40043e8ba067e)
*prereq for 421afd2fe8 Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Denis Plotnikov [Tue, 24 Dec 2019 08:14:46 +0000 (11:14 +0300)]
virtio-mmio: update queue size on guest write
Some guests read back queue size after writing it.
Always update the on size write otherwise they might be confused.
Cc: qemu-stable@nongnu.org Signed-off-by: Denis Plotnikov <dplotnikov@virtuozzo.com>
Message-Id: <20191224081446.17003-1-dplotnikov@virtuozzo.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 1049f4c62c4070618cc5defc9963c6a17ae7a5ae) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Some guests read back queue size after writing it.
Update the size immediatly upon write otherwise
they get confused.
In particular this is the case for seabios.
Reported-by: Roman Kagan <rkagan@virtuozzo.com> Suggested-by: Denis Plotnikov <dplotnikov@virtuozzo.com> Cc: qemu-stable@nongnu.org Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit d0c5f643383b9e84316f148affff368ac33d75b9) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Alexander Popov [Mon, 23 Dec 2019 17:51:16 +0000 (20:51 +0300)]
ide: Fix incorrect handling of some PRDTs in ide_dma_cb()
The commit a718978ed58a from July 2015 introduced the assertion which
implies that the size of successful DMA transfers handled in ide_dma_cb()
should be multiple of 512 (the size of a sector). But guest systems can
initiate DMA transfers that don't fit this requirement.
For fixing that let's check the number of bytes prepared for the transfer
by the prepare_buf() handler. The code in ide_dma_cb() must behave
according to the Programming Interface for Bus Master IDE Controller
(Revision 1.0 5/16/94):
1. If PRDs specified a smaller size than the IDE transfer
size, then the Interrupt and Active bits in the Controller
status register are not set (Error Condition).
2. If the size of the physical memory regions was equal to
the IDE device transfer size, the Interrupt bit in the
Controller status register is set to 1, Active bit is set to 0.
3. If PRDs specified a larger size than the IDE transfer size,
the Interrupt and Active bits in the Controller status register
are both set to 1.
Signed-off-by: Alexander Popov <alex.popov@linux.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Message-id: 20191223175117.508990-2-alex.popov@linux.com Signed-off-by: John Snow <jsnow@redhat.com>
(cherry picked from commit ed78352a59ea7acf7520d4d47a96b9911bae7fc3) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Alexander Popov [Mon, 23 Dec 2019 17:51:17 +0000 (20:51 +0300)]
tests/ide-test: Create a single unit-test covering more PRDT cases
Fuzzing the Linux kernel with syzkaller allowed to find how to crash qemu
using a special SCSI_IOCTL_SEND_COMMAND. It hits the assertion in
ide_dma_cb() introduced in the commit a718978ed58a in July 2015.
Currently this bug is not reproduced by the unit tests.
Let's improve the ide-test to cover more PRDT cases including one
that causes this particular qemu crash.
The test is developed according to the Programming Interface for
Bus Master IDE Controller (Revision 1.0 5/16/94).
Signed-off-by: Alexander Popov <alex.popov@linux.com>
Message-id: 20191223175117.508990-3-alex.popov@linux.com Signed-off-by: John Snow <jsnow@redhat.com>
(cherry picked from commit 59805ae92dfe4f67105e36b539d567caec4f8304) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
It was not clear whether this applied to the '-vga std' parameter or the
'-append' one. Fix the parsing regression and clarify the error.
Fixes: 133ef074bd ("hw/i386/pc: replace use of strtol with qemu_strtoui in x86_load_linux()") Cc: Sergio Lopez <slp@redhat.com> Signed-off-by: Peter Wu <peter@lekensteyn.nl>
Message-Id: <20191221162124.1159291-1-peter@lekensteyn.nl> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit a88c40f02ace88f09b2a85a64831b277b2ebc88c) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Niek Linnenbank [Fri, 20 Dec 2019 14:03:00 +0000 (14:03 +0000)]
arm/arm-powerctl: rebuild hflags after setting CP15 bits in arm_set_cpu_on()
After setting CP15 bits in arm_set_cpu_on() the cached hflags must
be rebuild to reflect the changed processor state. Without rebuilding,
the cached hflags would be inconsistent until the next call to
arm_rebuild_hflags(). When QEMU is compiled with debugging enabled
(--enable-debug), this problem is captured shortly after the first
call to arm_set_cpu_on() for CPUs running in ARM 32-bit non-secure mode:
Niek Linnenbank [Mon, 2 Dec 2019 21:09:43 +0000 (22:09 +0100)]
arm/arm-powerctl: set NSACR.{CP11, CP10} bits in arm_set_cpu_on()
This change ensures that the FPU can be accessed in Non-Secure mode
when the CPU core is reset using the arm_set_cpu_on() function call.
The NSACR.{CP11,CP10} bits define the exception level required to
access the FPU in Non-Secure mode. Without these bits set, the CPU
will give an undefined exception trap on the first FPU access for the
secondary cores under Linux.
This is necessary because in this power-control codepath QEMU
is effectively emulating a bit of EL3 firmware, and has to set
the CPU up as the EL3 firmware would.
Fixes: fc1120a7f5 Cc: qemu-stable@nongnu.org Signed-off-by: Niek Linnenbank <nieklinnenbank@gmail.com>
[PMM: added clarifying para to commit message] Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 0c7f8c43daf6556078e51de98aa13f069e505985) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Max Reitz [Thu, 19 Dec 2019 18:26:38 +0000 (19:26 +0100)]
backup-top: Begin drain earlier
When dropping backup-top, we need to drain the node before freeing the
BlockCopyState. Otherwise, requests may still be in flight and then the
assertion in shres_destroy() will fail.
(This becomes visible in intermittent failure of 056.)
Cc: qemu-stable@nongnu.org Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-id: 20191219182638.104621-1-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit 503ca1262bab2c11c533a4816d1ff4297d4f58a6) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Igor Mammedov [Thu, 12 Dec 2019 12:48:56 +0000 (13:48 +0100)]
numa: properly check if numa is supported
Commit aa57020774b, by mistake used MachineClass::numa_mem_supported
to check if NUMA is supported by machine and also as unrelated change
set it to true for sbsa-ref board.
Luckily change didn't break machines that support NUMA, as the field
is set to true for them.
But the field is not intended for checking if NUMA is supported and
will be flipped to false within this release for new machine types.
Fix it:
- by using previously used condition
!mc->cpu_index_to_instance_props || !mc->get_default_cpu_node_id
the first time and then use MachineState::numa_state down the road
to check if NUMA is supported
- dropping stray sbsa-ref chunk
Fixes: aa57020774b690a22be72453b8e91c9b5a68c516 Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <1576154936-178362-3-git-send-email-imammedo@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
(cherry picked from commit fcd3f2cc124600385dba46c69a80626985c15b50) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Kevin Wolf [Tue, 17 Dec 2019 14:06:38 +0000 (15:06 +0100)]
block: Activate recursively even for already active nodes
bdrv_invalidate_cache_all() assumes that all nodes in a given subtree
are either active or inactive when it starts. Therefore, as soon as it
arrives at an already active node, it stops.
However, this assumption is wrong. For example, it's possible to take a
snapshot of an inactive node, which results in an active overlay over an
inactive backing file. The active overlay is probably also the root node
of an inactive BlockBackend (blk->disable_perm == true).
In this case, bdrv_invalidate_cache_all() does not need to do anything
to activate the overlay node, but it still needs to recurse into the
children and the parents to make sure that after returning success,
really everything is activated.
Cc: qemu-stable@nongnu.org Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit 7bb4941ace471fc7dd6ded4749b95b9622baa6ed) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Alex Bennée [Thu, 12 Dec 2019 11:47:34 +0000 (11:47 +0000)]
target/arm: ensure we use current exception state after SCR update
A write to the SCR can change the effective EL by droppping the system
from secure to non-secure mode. However if we use a cached current_el
from before the change we'll rebuild the flags incorrectly. To fix
this we introduce the ARM_CP_NEWEL CP flag to indicate the new EL
should be used when recomputing the flags.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20191212114734.6962-1-alex.bennee@linaro.org Cc: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20191209143723.6368-1-alex.bennee@linaro.org> Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit f80741d107673f162e3b097fc76a1590036cc9d1) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Mention that this is a PCI device address & give the format it is
expected in. Also mention that it must be first unbound from any
host kernel driver.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit ecaf647f300d69271c245a67adca9c3a89d9463a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Eduardo Habkost [Thu, 5 Dec 2019 22:33:39 +0000 (19:33 -0300)]
i386: Resolve CPU models to v1 by default
When using `query-cpu-definitions` using `-machine none`,
QEMU is resolving all CPU models to their latest versions. The
actual CPU model version being used by another machine type (e.g.
`pc-q35-4.0`) might be different.
In theory, this was OK because the correct CPU model
version is returned when using the correct `-machine` argument.
Except that in practice, this breaks libvirt expectations:
libvirt always use `-machine none` when checking if a CPU model
is runnable, because runnability is not expected to be affected
when the machine type is changed.
For example, when running on a Haswell host without TSX,
Haswell-v4 is runnable, but Haswell-v1 is not. On those hosts,
`query-cpu-definitions` says Haswell is runnable if using
`-machine none`, but Haswell is actually not runnable using any
of the `pc-*` machine types (because they resolve Haswell to
Haswell-v1). In other words, we're breaking the "runnability
guarantee" we promised to not break for a few releases (see
qemu-deprecated.texi).
To address this issue, change the default CPU model version to v1
on all machine types, so we make `query-cpu-definitions` output
when using `-machine none` match the results when using `pc-*`.
This will change in the future (the plan is to always return the
latest CPU model version if using `-machine none`), but only
after giving libvirt the opportunity to adapt.
Pan Nengyuan [Thu, 5 Dec 2019 03:45:28 +0000 (11:45 +0800)]
block/nbd: fix memory leak in nbd_open()
In currently implementation there will be a memory leak when
nbd_client_connect() returns error status. Here is an easy way to
reproduce:
1. run qemu-iotests as follow and check the result with asan:
./check -raw 143
Following is the asan output backtrack:
Direct leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x7f629688a560 in calloc (/usr/lib64/libasan.so.3+0xc7560)
#1 0x7f6295e7e015 in g_malloc0 (/usr/lib64/libglib-2.0.so.0+0x50015)
#2 0x56281dab4642 in qobject_input_start_struct /mnt/sdb/qemu-4.2.0-rc0/qapi/qobject-input-visitor.c:295
#3 0x56281dab1a04 in visit_start_struct /mnt/sdb/qemu-4.2.0-rc0/qapi/qapi-visit-core.c:49
#4 0x56281dad1827 in visit_type_SocketAddress qapi/qapi-visit-sockets.c:386
#5 0x56281da8062f in nbd_config /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1716
#6 0x56281da8062f in nbd_process_options /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1829
#7 0x56281da8062f in nbd_open /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
Direct leak of 15 byte(s) in 1 object(s) allocated from:
#0 0x7f629688a3a0 in malloc (/usr/lib64/libasan.so.3+0xc73a0)
#1 0x7f6295e7dfbd in g_malloc (/usr/lib64/libglib-2.0.so.0+0x4ffbd)
#2 0x7f6295e96ace in g_strdup (/usr/lib64/libglib-2.0.so.0+0x68ace)
#3 0x56281da804ac in nbd_process_options /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1834
#4 0x56281da804ac in nbd_open /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
Indirect leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7f629688a3a0 in malloc (/usr/lib64/libasan.so.3+0xc73a0)
#1 0x7f6295e7dfbd in g_malloc (/usr/lib64/libglib-2.0.so.0+0x4ffbd)
#2 0x7f6295e96ace in g_strdup (/usr/lib64/libglib-2.0.so.0+0x68ace)
#3 0x56281dab41a3 in qobject_input_type_str_keyval /mnt/sdb/qemu-4.2.0-rc0/qapi/qobject-input-visitor.c:536
#4 0x56281dab2ee9 in visit_type_str /mnt/sdb/qemu-4.2.0-rc0/qapi/qapi-visit-core.c:297
#5 0x56281dad0fa1 in visit_type_UnixSocketAddress_members qapi/qapi-visit-sockets.c:141
#6 0x56281dad17b6 in visit_type_SocketAddress_members qapi/qapi-visit-sockets.c:366
#7 0x56281dad186a in visit_type_SocketAddress qapi/qapi-visit-sockets.c:393
#8 0x56281da8062f in nbd_config /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1716
#9 0x56281da8062f in nbd_process_options /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1829
#10 0x56281da8062f in nbd_open /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
Fixes: 8f071c9db506e03ab Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Cc: qemu-stable <qemu-stable@nongnu.org> Cc: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <1575517528-44312-3-git-send-email-pannengyuan@huawei.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Eric Blake <eblake@redhat.com>
(cherry picked from commit 8198cf5ef0ef98118b4176970d1cd998d93ec849) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Peter Maydell [Mon, 9 Dec 2019 16:06:51 +0000 (16:06 +0000)]
Merge remote-tracking branch 'remotes/ericb/tags/pull-nbd-2019-12-09' into staging
bitmap fix for 4.2-rc5
- Fix a regression that broke bitmap deletion without a transaction,
and causes a crash with transaction (only transaction is new to 4.2),
when a qcow2 file contains persistent bitmaps from prior shutdown
# gpg: Signature made Mon 09 Dec 2019 15:28:19 GMT
# gpg: using RSA key 71C2CC22B1C4602927D2F3AAA7A16B4A2527436A
# gpg: Good signature from "Eric Blake <eblake@redhat.com>" [full]
# gpg: aka "Eric Blake (Free Software Programmer) <ebb9@byu.net>" [full]
# gpg: aka "[jpeg image of size 6874]" [full]
# Primary key fingerprint: 71C2 CC22 B1C4 6029 27D2 F3AA A7A1 6B4A 2527 436A
* remotes/ericb/tags/pull-nbd-2019-12-09:
block/qcow2-bitmap: fix crash bug in qcow2_co_remove_persistent_dirty_bitmap
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
block/qcow2-bitmap: fix crash bug in qcow2_co_remove_persistent_dirty_bitmap
Here is double bug:
First, return error but not set errp. This may lead to:
qmp block-dirty-bitmap-remove may report success when actually failed
block-dirty-bitmap-remove used in a transaction will crash, as
qmp_transaction will think that it returned success and will call
block_dirty_bitmap_remove_commit which will crash, as state->bitmap is
NULL
Second (like in anecdote), this case is not an error at all. As it is
documented in the comment above bdrv_co_remove_persistent_dirty_bitmap
definition, absence of bitmap is not an error, and similar case handled
at start of qcow2_co_remove_persistent_dirty_bitmap, it returns 0 when
there is no bitmaps at all.
But when there are some bitmaps, but not the requested one, it return
error with errp unset.
Fix that.
Trigger:
1. create persistent bitmap A
2. shutdown vm (bitmap A is synced)
3. start vm
4. create persistent bitmap B
5. remove bitmap B - it fails (and crashes if in transaction)
Potential workaround (rather invasive to ask clients to implement it):
1. create persistent bitmap A
2. shutdown vm
3. start vm
4. create persistent bitmap B
5. remember, that we want to remove bitmap B after vm shutdown
...
some other operations
...
6. vm shutdown
7. start vm in stopped mode, and remove all bitmaps marked for removing
8. stop vm
Fixes: b56a1e31759b750 Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20191205193049.30666-1-vsementsov@virtuozzo.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com>
[eblake: commit message tweaks] Signed-off-by: Eric Blake <eblake@redhat.com>
Peter Maydell [Mon, 9 Dec 2019 11:07:34 +0000 (11:07 +0000)]
Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-4.2-20191209' into staging
ppc patch queue 2019-12-09
This is a last minute pull request for ppc-for-4.2. I know it's very
late in freeze, but this does fix a regression: a bad interaction
between the new qemu and SLOF device tree construction code means that
SLOF will crash if PCI to PCI bridges are included in the system.
This PR supersedes ppc-for-4.2-20191206. This one has only a more
minimal change to the firmware addressed only at fixing this bug and
not incorporating some other unrelated changes that happened in the
meantime.
Yang Zhong [Fri, 6 Dec 2019 07:11:11 +0000 (15:11 +0800)]
target/i386: disable VMX features if nested=0
If kvm does not support VMX feature by nested=0, the kvm_vmx_basic
can't get the right value from MSR_IA32_VMX_BASIC register, which
make qemu coredump when qemu do KVM_SET_MSRS.
The coredump info:
error: failed to set MSR 0x480 to 0x0
kvm_put_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed.
Signed-off-by: Yang Zhong <yang.zhong@intel.com>
Message-Id: <20191206071111.12128-1-yang.zhong@intel.com> Reported-by: Catherine Ho <catherine.hecx@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
hvf: correctly inject VMCS_INTR_T_HWINTR versus VMCS_INTR_T_SWINTR.
Previous implementation in hvf_inject_interrupts() would always inject
VMCS_INTR_T_SWINTR even when VMCS_INTR_T_HWINTR was required. Now
correctly determine when VMCS_INTR_T_HWINTR is appropriate versus
VMCS_INTR_T_SWINTR.
Make sure to clear ins_len and has_error_code when ins_len isn't
valid and error_code isn't set.
raw_aio_attach_aio_context() passes uninitialized Error *local_err by
reference to laio_init() via aio_setup_linux_aio(). When laio_init()
fails, it passes it on to error_setg_errno(), tripping error_setv()'s
assertion unless @local_err is null by dumb luck.
Fix by initializing @local_err properly.
Fixes: ed6e2161715c527330f936d44af4c547f25f687e Cc: Nishanth Aravamudan <naravamudan@digitalocean.com> Cc: Stefan Hajnoczi <stefanha@redhat.com> Cc: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20191130194240.10517-4-armbru@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Functions that take an Error ** parameter to pass an error to the
caller expect the parameter to point to null.
failover_replug_primary() violates this precondition in several
places:
* After qemu_opts_from_qdict() failed, *errp is no longer null.
Passing it to error_setg() is wrong, and will trip the assertion in
error_setv(). Messed up in commit 150ab54aa6 "net/virtio: fix
re-plugging of primary device". Simply drop the error_setg().
* Passing @errp to qemu_opt_set_bool(), hotplug_handler_pre_plug(),
and hotplug_handler_plug() is wrong. If one of the first two fails,
*errp is no longer null. Risks tripping the same assertion.
Moreover, continuing after such errors is unsafe. Messed up in
commit 9711cd0dfc "net/virtio: add failover support". Fix by
handling each error properly.
failover_replug_primary() crashes when passed a null @errp. Also
messed up in commit 9711cd0dfc. This bug can't bite as no caller
actually passes null. Fix it anyway.
Fixes: 9711cd0dfc3fa414f7f64935713c07134ae67971 Fixes: 150ab54aa6934583180f88a2bd540bc6fc4fbff3 Cc: Jens Freimann <jfreimann@redhat.com> Cc: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20191130194240.10517-3-armbru@redhat.com> Reviewed-by: Jens Freimann <jfreimann@redhat.com>
net/virtio: Drop useless n->primary_dev not null checks
virtio_net_handle_migration_primary() returns early when it can't
ensure n->primary_dev is non-null. Checking it again right after that
early return is redundant. Drop.
If n->primary_dev is null on entering failover_replug_primary(), @pdev
will become null, and pdev->partially_hotplugged will crash. Checking
n->primary_dev later is useless. It can't actually be null, because
its caller virtio_net_handle_migration_primary() ensures it isn't.
Drop the useless check.
Cc: Jens Freimann <jfreimann@redhat.com> Cc: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20191130194240.10517-2-armbru@redhat.com> Reviewed-by: Jens Freimann <jfreimann@redhat.com>
Alex Bennée [Wed, 27 Nov 2019 13:24:30 +0000 (13:24 +0000)]
.travis.yml: drop xcode9.4 from build matrix
It's broken so it's no longer helping. The latest Xcode is covered by
Cirrus.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20191127132430.3681-1-alex.bennee@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Claudio Imbrenda [Thu, 28 Nov 2019 12:33:57 +0000 (13:33 +0100)]
pc-bios/s390-ccw: fix sclp_get_loadparm_ascii
The existing s390 bios gets the LOADPARM information from the system using
an SCLP call that specifies a buffer length too small to contain all the
output.
The recent fixes in the SCLP code have exposed this bug, since now the
SCLP call will return an error (as per architecture) instead of
writing partially and completing successfully.
The solution is simply to specify the full page length as the SCCB
length instead of a smaller size.
Fixes: 832be0d8a3bb ("s390x: sclp: Report insufficient SCCB length") Fixes: 9a22473c70f3 ("pc-bios/s390-ccw: get LOADPARM stored in SCP Read Info") Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-Id: <1574944437-31182-1-git-send-email-imbrenda@linux.ibm.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Tested-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Tested-by: Marc Hartmayer <mhartmay@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
* remotes/bonzini/tags/for-upstream:
hvf: more accurately match SDM when setting CR0 and PDPTE registers
hvf: correctly handle REX prefix in relation to legacy prefixes
hvf: remove TSC synchronization code because it isn't fully complete
hvf: non-RAM, non-ROMD memory ranges are now correctly mapped in
target/i386: add two missing VMX features for Skylake and CascadeLake Server
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Peter Maydell [Tue, 26 Nov 2019 18:37:49 +0000 (18:37 +0000)]
Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20191126' into staging
target-arm queue:
* handle FTYPE flag correctly in v7M exception return
for v7M CPUs with an FPU (v8M CPUs were already correct)
* versal: Add the CRP as unimplemented
* Fix ISR_EL1 tracking when executing at EL2
* Honor HCR_EL2.TID3 trapping requirements
* remotes/pmaydell/tags/pull-target-arm-20191126:
target/arm: Honor HCR_EL2.TID3 trapping requirements
target/arm: Fix ISR_EL1 tracking when executing at EL2
hw/arm: versal: Add the CRP as unimplemented
target/arm: Fix handling of cortex-m FTYPE flag in EXCRET
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Peter Maydell [Tue, 26 Nov 2019 16:48:48 +0000 (16:48 +0000)]
Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-4.2-20191126' into staging
ppc patch queue for 2019-11-26
Here's the first 4.2 hard freeze pull request from me. This has:
* A fix for some testcases that cause errors on older host kernels
(e.g. RHEL7), with our new default configuration of VSMT mode
* Changes to make VFIO devices interact properly with change of irq
chip caused by PAPR feature negotiation. This is more involved
than I would like, but it's a problem in real use cases and I
can't see an easier way to handle it.
* Fix an error with ms6522 counters for the g3beige machine
* Fix a coverity warning
HCR_EL2.TID3 mandates that access from EL1 to a long list of id
registers traps to EL2, and QEMU has so far ignored this requirement.
This breaks (among other things) KVM guests that have PtrAuth enabled,
while the hypervisor doesn't want to expose the feature to its guest.
To achieve this, KVM traps the ID registers (ID_AA64ISAR1_EL1 in this
case), and masks out the unsupported feature.
QEMU not honoring the trap request means that the guest observes
that the feature is present in the HW, starts using it, and dies
a horrible death when KVM injects an UNDEF, because the feature
*really* isn't supported.
Do the right thing by trapping to EL2 if HCR_EL2.TID3 is set.
Note that this change does not include trapping of the MVFR
registers from AArch32 (they are accessed via the VMRS
instruction and need to be handled in a different way).
Reported-by: Will Deacon <will@kernel.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Tested-by: Will Deacon <will@kernel.org>
Message-id: 20191123115618.29230-1-maz@kernel.org
[PMM: added missing accessfn line for ID_AA4PFR2_EL1_RESERVED;
changed names of access functions to include _tid3] Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Marc Zyngier [Tue, 26 Nov 2019 13:55:36 +0000 (13:55 +0000)]
target/arm: Fix ISR_EL1 tracking when executing at EL2
The ARMv8 ARM states when executing at EL2, EL3 or Secure EL1,
ISR_EL1 shows the pending status of the physical IRQ, FIQ, or
SError interrupts.
Unfortunately, QEMU's implementation only considers the HCR_EL2
bits, and ignores the current exception level. This means a hypervisor
trying to look at its own interrupt state actually sees the guest
state, which is unexpected and breaks KVM as of Linux 5.3.
Instead, check for the running EL and return the physical bits
if not running in a virtualized context.
Fixes: 636540e9c40b Cc: qemu-stable@nongnu.org Reported-by: Quentin Perret <qperret@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
Message-id: 20191122135833.28953-1-maz@kernel.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Add the CRP as unimplemented thus avoiding bus errors when
guests access these registers.
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Luc Michel <luc.michel@greensocs.com>
Message-id: 20191115154734.26449-2-edgar.iglesias@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
target/arm: Fix handling of cortex-m FTYPE flag in EXCRET
According to the PushStack() pseudocode in the armv7m RM,
bit 4 of the LR should be set to NOT(CONTROL.PFCA) when
an FPU is present. Current implementation is doing it for
armv8, but not for armv7. This patch makes the existing
logic applicable to both code paths.
Signed-off-by: Jean-Hugues Deschenes <jean-hugues.deschenes@ossiaco.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Add optional pre-shutdown: shutdown/launch vm before migration. This
leads to storing persistent bitmap to the storage, which breaks
migration with dirty-bitmaps capability enabled and shared storage
until fixed by previous commit.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-id: 20191125125229.13531-3-vsementsov@virtuozzo.com Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
Fix bitmap migration with dirty-bitmaps capability enabled and shared
storage. We should ignore IN_USE bitmaps in the image on target, when
migrating bitmaps through migration channel, see new comment below.
Fixes: 74da6b943565c451 Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-id: 20191125125229.13531-2-vsementsov@virtuozzo.com Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
Peter Maydell [Tue, 26 Nov 2019 12:36:40 +0000 (12:36 +0000)]
Merge remote-tracking branch 'remotes/palmer/tags/riscv-for-master-4.2-rc3' into staging
RISC-V Patches for 4.2-rc3
This tag contains two patches that I'd like to target for 4.2-rc3:
* A fix to the DT entry for the SiFive test finisher.
* A fix to the spike board's HTIF interface.
This passes "make check" and boots OE for me.
# gpg: Signature made Mon 25 Nov 2019 20:51:13 GMT
# gpg: using RSA key 00CE76D1834960DFCE886DF8EF4CA1502CCBAB41
# gpg: issuer "palmer@dabbelt.com"
# gpg: Good signature from "Palmer Dabbelt <palmer@dabbelt.com>" [unknown]
# gpg: aka "Palmer Dabbelt <palmer@sifive.com>" [unknown]
# 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: 00CE 76D1 8349 60DF CE88 6DF8 EF4C A150 2CCB AB41
* remotes/palmer/tags/riscv-for-master-4.2-rc3:
hw/riscv: Add optional symbol callback ptr to riscv_load_kernel()
RISC-V: virt: This is a "sifive,test1" test finisher
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Alex Bennée [Thu, 21 Nov 2019 16:58:38 +0000 (16:58 +0000)]
tests/vm/ubuntu: update i386 image to 18.04
The current image is broken while running qtests but the bug go away
when built with a newer Ubuntu i386 image. I was unable to replicate
the crash on Debian Buster for i386 either so I'm concluding it is a
distro problem. Let's paper over that crack by updating our 32 bir
test image.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Alex Bennée [Wed, 20 Nov 2019 15:11:12 +0000 (15:11 +0000)]
tests/vm/centos: fix centos build target
To be able to run the docker tests centos has here we have to install
python3 as well as the basic tools.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Cameron Esfahani [Sun, 24 Nov 2019 20:05:25 +0000 (12:05 -0800)]
hvf: correctly handle REX prefix in relation to legacy prefixes
In real x86 processors, the REX prefix must come after legacy prefixes.
REX before legacy is ignored. Update the HVF emulation code to properly
handle this. Fix some spelling errors in constants. Fix some decoder
table initialization issues found by Coverity.
Cameron Esfahani [Sun, 24 Nov 2019 20:05:24 +0000 (12:05 -0800)]
hvf: remove TSC synchronization code because it isn't fully complete
The existing code in QEMU's HVF support to attempt to synchronize TSC
across multiple cores is not sufficient. TSC value on other cores
can go backwards. Until implementation is fixed, remove calls to
hv_vm_sync_tsc(). Pass through TSC to guest OS.
Cameron Esfahani [Sun, 24 Nov 2019 20:05:23 +0000 (12:05 -0800)]
hvf: non-RAM, non-ROMD memory ranges are now correctly mapped in
If an area is non-RAM and non-ROMD, then remove mappings so accesses
will trap and can be emulated. Change hvf_find_overlap_slot() to take
a size instead of an end address: it wouldn't return a slot because
callers would pass the same address for start and end. Don't always
map area as read/write/execute, respect area flags.
PanNengyuan [Mon, 25 Nov 2019 12:34:51 +0000 (20:34 +0800)]
ppc/spapr_events: fix potential NULL pointer dereference in rtas_event_log_dequeue
This fixes coverity issues 68911917:
360
CID 68911917: (NULL_RETURNS)
361. dereference: Dereferencing "source", which is known to be
"NULL".
361 if (source->mask & event_mask) {
362 break;
363 }
projects / thirdparty / qemu.git / log
