aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-06-03block/io: fix bdrv_co_do_copy_on_readvVladimir Sementsov-Ogievskiy
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>
2020-06-03target/ppc: Fix rlwinm on ppc64Vitaly Chikunov
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>
2020-06-03block/block-copy: fix progress calculationVladimir Sementsov-Ogievskiy
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>
2020-06-03job: refactor progress to separate objectVladimir Sementsov-Ogievskiy
We need it in separate to pass to the block-copy object in the next commit. Cc: qemu-stable@nongnu.org Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Andrey Shinkevich <andrey.shinkevich@virtuozzo.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Message-Id: <20200311103004.7649-2-vsementsov@virtuozzo.com> Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit 01fe1ca945345d3dc420d70c69488143dc0451b1) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-03block/qcow2-threads: fix qcow2_decompressVladimir Sementsov-Ogievskiy
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>
2020-06-03scsi/qemu-pr-helper: Fix out-of-bounds access to trnptid_list[]Christophe de Dinechin
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: trnptid_list[paramp.descr.num_transportid++] = id; This is an actual out-of-bounds access. The fix is to malloc `paramp`. 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>
2020-06-03virtio: gracefully handle invalid region cachesStefan Hajnoczi
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. The fuzz test failure is as follows: $ qemu -M pc -device virtio-blk-pci,id=drv0,drive=drive0,addr=4.0 \ -drive if=none,id=drive0,file=null-co://,format=raw,auto-read-only=off \ -drive if=none,id=drive1,file=null-co://,file.read-zeroes=on,format=raw \ -display none \ -qtest stdio endianness outl 0xcf8 0x80002020 outl 0xcfc 0xe0000000 outl 0xcf8 0x80002004 outw 0xcfc 0x7 write 0xe0000000 0x24 0x00ffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffab5cffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffab0000000001 inb 0x4 writew 0xe000001c 0x1 write 0xe0000014 0x1 0x0d The following error message is produced: qemu-system-x86_64: /home/stefanha/qemu/hw/virtio/virtio.c:286: vring_get_region_caches: Assertion `caches != NULL' failed. The backtrace looks like this: #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>
2020-06-02iotests/026: Test EIO on allocation in a data-fileMax Reitz
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>
2020-06-02iotests/026: Test EIO on preallocated zero clusterMax Reitz
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>
2020-06-02qcow2: Fix alloc_cluster_abort() for pre-existing clustersMax Reitz
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>
2020-06-02iotests: Test copy offloading with external data fileKevin Wolf
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>
2020-06-02qcow2: Fix qcow2_alloc_cluster_abort() for external data fileKevin Wolf
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>
2020-06-02qcow2: update_refcount(): Reset old_table_index after qcow2_cache_put()Kevin Wolf
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>
2020-06-02tcg: save vaddr temp for plugin usageAlex Bennée
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>
2020-06-02plugins/core: add missing break in cb_to_tcg_flagsEmilio G. Cota
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>
2020-06-02s390/sclp: improve special wait psw logicChristian Borntraeger
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>
2020-06-02dp8393x: Don't stop reception upon RBE interrupt assertionFinn Thain
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>
2020-06-02dp8393x: Don't reset Silicon Revision registerFinn Thain
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>
2020-06-02dp8393x: Always update RRA pointers and sequence numbersFinn Thain
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>
2020-06-02dp8393x: Clear descriptor in_use field to release packetFinn Thain
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>
2020-06-02dp8393x: Pad frames to word or long word boundaryFinn Thain
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>
2020-06-02dp8393x: Use long-word-aligned RRA pointers in 32-bit modeFinn Thain
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>
2020-06-02dp8393x: Don't clobber packet checksumFinn Thain
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>
2020-06-02dp8393x: Implement packet size limit and RBAE interruptFinn Thain
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>
2020-06-02dp8393x: Clear RRRA command register bit only when appropriateFinn Thain
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>
2020-06-02dp8393x: Update LLFA and CRDA registers from rx descriptorFinn Thain
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>
2020-06-02dp8393x: Have dp8393x_receive() return the packet sizeFinn Thain
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>
2020-06-02dp8393x: Clean up endianness hacksFinn Thain
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>
2020-06-01dp8393x: Always use 32-bit accessesFinn Thain
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>
2020-06-01dp8393x: Mask EOL bit from descriptor addressesFinn Thain
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>
2020-06-01qcow2-bitmaps: fix qcow2_can_store_new_dirty_bitmapVladimir Sementsov-Ogievskiy
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>
2020-06-01vfio/pci: Don't remove irqchip notifier if not registeredPeter Xu
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>
2020-05-12intel_iommu: add present bit check for pasid table entriesLiu Yi L
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>
2020-05-12intel_iommu: a fix to vtd_find_as_from_bus_num()Liu Yi L
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>
2020-05-12virtio-net: delete also control queue when TX/RX deletedYuri Benditovich
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>
2020-05-12virtio: reset region cache when on queue deletionYuri Benditovich
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>
2020-05-12virtio: make virtio_delete_queue idempotentMichael S. Tsirkin
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>
2020-05-12virtio: add ability to delete vq through a pointerMichael S. Tsirkin
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>
2020-05-11virtio-mmio: update queue size on guest writeDenis Plotnikov
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>
2020-05-11virtio: update queue size on guest writeMichael S. Tsirkin
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>
2020-05-11target/arm: Set ISSIs16Bit in make_issinfoRichard Henderson
During the conversion to decodetree, the setting of ISSIs16Bit got lost. This causes the guest os to incorrectly adjust trapping memory operations. Cc: qemu-stable@nongnu.org Fixes: 46beb58efbb8a2a32 ("target/arm: Convert T16, load (literal)") Reported-by: Jeff Kubascik <jeff.kubascik@dornerworks.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200117004618.2742-3-richard.henderson@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 1a1fbc6cbb34c26d43d8360c66c1d21681af14a9) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-05-11ide: Fix incorrect handling of some PRDTs in ide_dma_cb()Alexander Popov
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>
2020-05-11tests/ide-test: Create a single unit-test covering more PRDT casesAlexander Popov
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>
2020-05-11hw/i386/pc: fix regression in parsing vga cmdline parameterPeter Wu
When the 'vga=' parameter is succeeded by another parameter, QEMU 4.2.0 would refuse to start with a rather cryptic message: $ qemu-system-x86_64 -kernel /boot/vmlinuz-linux -append 'vga=792 quiet' qemu: can't parse 'vga' parameter: Invalid argument 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>
2020-05-11arm/arm-powerctl: rebuild hflags after setting CP15 bits in arm_set_cpu_on()Niek Linnenbank
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: qemu-system-arm: target/arm/helper.c:11359: cpu_get_tb_cpu_state: Assertion `flags == rebuild_hflags_internal(env)' failed. Aborted (core dumped) Fixes: 0c7f8c43daf65 Cc: qemu-stable@nongnu.org Signed-off-by: Niek Linnenbank <nieklinnenbank@gmail.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit c8fa6079eb35888587f1be27c1590da4edcc5098) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-05-11arm/arm-powerctl: set NSACR.{CP11, CP10} bits in arm_set_cpu_on()Niek Linnenbank
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>
2020-05-11backup-top: Begin drain earlierMax Reitz
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>
2020-05-11numa: properly check if numa is supportedIgor Mammedov
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>
2020-05-11numa: remove not needed checkIgor Mammedov
Currently parse_numa_node() is always called from already numa enabled context. Drop unnecessary check if numa is supported. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <1576154936-178362-2-git-send-email-imammedo@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> (cherry picked from commit 5275db59aa7ff8a26bd6aa5d07cb4d53de5cfab5) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-05-11virtio-blk: fix out-of-bounds access to bitmap in notify_guest_bhLi Hangjing
When the number of a virtio-blk device's virtqueues is larger than BITS_PER_LONG, the out-of-bounds access to bitmap[ ] will occur. Fixes: e21737ab15 ("virtio-blk: multiqueue batch notify") Cc: qemu-stable@nongnu.org Cc: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Li Hangjing <lihangjing@baidu.com> Reviewed-by: Xie Yongji <xieyongji@baidu.com> Reviewed-by: Chai Wen <chaiwen@baidu.com> Message-id: 20191216023050.48620-1-lihangjing@baidu.com Message-Id: <20191216023050.48620-1-lihangjing@baidu.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> (cherry picked from commit 725fe5d10dbd4259b1853b7d253cef83a3c0d22a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-15 01:15:14 +0000