aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-06-25Update version for 4.2.1 releasev4.2.1Michael Roth
2020-06-22iotests/283: Use consistent size for source and targetKevin Wolf
The test case forgot to specify the null-co size for the target node. When adding a check to backup that both sizes match, this would fail because of the size mismatch and not the behaviour that the test really wanted to test. Fixes: a541fcc27c98b96da187c7d4573f3270f3ddd283 Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20200430142755.315494-2-kwolf@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 813cc2545b82409fd504509f0ba2e96fab6edb9e) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22Fix tulip breakageHelge Deller
The tulip network driver in a qemu-system-hppa emulation is broken in the sense that bigger network packages aren't received any longer and thus even running e.g. "apt update" inside the VM fails. The breakage was introduced by commit 8ffb7265af ("check frame size and r/w data length") which added checks to prevent accesses outside of the rx/tx buffers. But the new checks were implemented wrong. The variable rx_frame_len counts backwards, from rx_frame_size down to zero, and the variable len is never bigger than rx_frame_len, so accesses just can't happen and the checks are unnecessary. On the contrary the checks now prevented bigger packages to be moved into the rx buffers. This patch reverts the wrong checks and were sucessfully tested with a qemu-system-hppa emulation. Fixes: 8ffb7265af ("check frame size and r/w data length") Buglink: https://bugs.launchpad.net/bugs/1874539 Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit d9b69640391618045949f7c500b87fc129f862ed) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22tcg/mips: mips sync* encode errorlixinyu
OPC_SYNC_WMB, OPC_SYNC_MB, OPC_SYNC_ACQUIRE, OPC_SYNC_RELEASE and OPC_SYNC_RMB have wrong encode. According to the mips manual, their encode should be 'OPC_SYNC | 0x?? << 6' rather than 'OPC_SYNC | 0x?? << 5'. Wrong encode can lead illegal instruction errors. These instructions often appear with multi-threaded simulation. Fixes: 6f0b99104a3 ("tcg/mips: Add support for fence") Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Aleksandar Markovic <aleksandar.qemu.devel@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: lixinyu <precinct@mail.ustc.edu.cn> Message-Id: <20200411124612.12560-1-precinct@mail.ustc.edu.cn> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit a4e57084c16d5b0eff3651693fba04f26b30b551) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22target/xtensa: fix pasto in pfwait.r opcode nameMax Filippov
Core xtensa opcode table has pfwait.o instead of pfwait.r. Fix that. Fixes: c884400f2988 ("target/xtensa: implement block prefetch option opcodes") Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> (cherry picked from commit 1a03362b14affa4d8ddede55df6e21d7a07b87c2) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22vpc: Don't round up already aligned BAT sizesKevin Wolf
As reported on Launchpad, Azure apparently doesn't accept images for upload that are not both aligned to 1 MB blocks and have a BAT size that matches the image size exactly. As far as I can tell, there is no real reason why we create a BAT that is one entry longer than necessary for aligned image sizes, so change that. (Even though the condition is only mentioned as "should" in the spec and previous products accepted larger BATs - but we'll try to maintain compatibility with as many of Microsoft's ever-changing interpretations of the VHD spec as possible.) Fixes: https://bugs.launchpad.net/bugs/1870098 Reported-by: Tobias Witek Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20200402093603.2369-1-kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 3f6de653b946fe849330208becf79d6af7e876cb) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22spapr: Fix failure path for attempting to hot unplug PCI bridgesDavid Gibson
For various technical reasons we can't currently allow unplug a PCI to PCI bridge on the pseries machine. spapr_pci_unplug_request() correctly generates an error message if that's attempted. But.. if the given errp is not error_abort or error_fatal, it doesn't actually stop trying to unplug the bridge anyway. Fixes: 14e714900f6b "spapr: Allow hot plug/unplug of PCI bridges and devices under PCI bridges" Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> (cherry picked from commit 7aab5899764887f6b0512cb2e5c11bdc2a5d3644) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22net: tulip: check frame size and r/w data lengthPrasad J Pandit
Tulip network driver while copying tx/rx buffers does not check frame size against r/w data length. This may lead to OOB buffer access. Add check to avoid it. Limit iterations over descriptors to avoid potential infinite loop issue in tulip_xmit_list_update. Reported-by: Li Qiang <pangpei.lq@antfin.com> Reported-by: Ziming Zhang <ezrakiez@gmail.com> Reported-by: Jason Wang <jasowang@redhat.com> Tested-by: Li Qiang <liq3ea@gmail.com> Reviewed-by: Li Qiang <liq3ea@gmail.com> Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit 8ffb7265af64ec81748335ec8f20e7ab542c3850) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22sheepdog: Consistently set bdrv_has_zero_init_truncateEric Blake
block_int.h claims that .bdrv_has_zero_init must return 0 if .bdrv_has_zero_init_truncate does likewise; but this is violated if only the former callback is provided if .bdrv_co_truncate also exists. When adding the latter callback, it was mistakenly added to only one of the three possible sheepdog instantiations. Fixes: 1dcaf527 Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20200324174233.1622067-5-eblake@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit ed049910637be991c88cc25c864115bc5b1e4dab) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22qcow2: List autoclear bit names in headerEric Blake
The feature table is supposed to advertise the name of all feature bits that we support; however, we forgot to update the table for autoclear bits. While at it, move the table to read-only memory in code, and tweak the qcow2 spec to name the second autoclear bit. Update iotests that are affected by the longer header length. Fixes: 88ddffae Fixes: 93c24936 Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20200324174233.1622067-3-eblake@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit bb40ebce2cb0bd4bf37968074d43d5a864fb6dee) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22migration/ram: fix use after free of local_errVladimir Sementsov-Ogievskiy
local_err is used again in migration_bitmap_sync_precopy() after precopy_notify(), so we must zero it. Otherwise try to set non-NULL local_err will crash. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20200324153630.11882-6-vsementsov@virtuozzo.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> (cherry picked from commit b4a1733c5e6827c72b0dcfa295e07ef7b1ebccff) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22migration/colo: fix use after free of local_errVladimir Sementsov-Ogievskiy
local_err is used again in secondary_vm_do_failover() after replication_stop_all(), so we must zero it. Otherwise try to set non-NULL local_err will crash. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20200324153630.11882-5-vsementsov@virtuozzo.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> (cherry picked from commit 27d07fcfa70c3afa0664288cbce5334ed9595a3a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22hmp/vnc: Fix info vnc list leakDr. David Alan Gilbert
We're iterating the list, and then freeing the iteration pointer rather than the list head. Fixes: 0a9667ecdb6d ("hmp: Update info vnc") Reported-by: Coverity (CID 1421932) Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20200323120822.51266-1-dgilbert@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> (cherry picked from commit d4ff109373ce871928c7e9ef648973eba642b484) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22block: bdrv_set_backing_bs: fix use-after-freeVladimir Sementsov-Ogievskiy
There is a use-after-free possible: bdrv_unref_child() leaves bs->backing freed but not NULL. bdrv_attach_child may produce nested polling loop due to drain, than access of freed pointer is possible. I've produced the following crash on 30 iotest with modified code. It does not reproduce on master, but still seems possible: #0 __strcmp_avx2 () at /lib64/libc.so.6 #1 bdrv_backing_overridden (bs=0x55c9d3cc2060) at block.c:6350 #2 bdrv_refresh_filename (bs=0x55c9d3cc2060) at block.c:6404 #3 bdrv_backing_attach (c=0x55c9d48e5520) at block.c:1063 #4 bdrv_replace_child_noperm (child=child@entry=0x55c9d48e5520, new_bs=new_bs@entry=0x55c9d3cc2060) at block.c:2290 #5 bdrv_replace_child (child=child@entry=0x55c9d48e5520, new_bs=new_bs@entry=0x55c9d3cc2060) at block.c:2320 #6 bdrv_root_attach_child (child_bs=child_bs@entry=0x55c9d3cc2060, child_name=child_name@entry=0x55c9d241d478 "backing", child_role=child_role@entry=0x55c9d26ecee0 <child_backing>, ctx=<optimized out>, perm=<optimized out>, shared_perm=21, opaque=0x55c9d3c5a3d0, errp=0x7ffd117108e0) at block.c:2424 #7 bdrv_attach_child (parent_bs=parent_bs@entry=0x55c9d3c5a3d0, child_bs=child_bs@entry=0x55c9d3cc2060, child_name=child_name@entry=0x55c9d241d478 "backing", child_role=child_role@entry=0x55c9d26ecee0 <child_backing>, errp=errp@entry=0x7ffd117108e0) at block.c:5876 #8 in bdrv_set_backing_hd (bs=bs@entry=0x55c9d3c5a3d0, backing_hd=backing_hd@entry=0x55c9d3cc2060, errp=errp@entry=0x7ffd117108e0) at block.c:2576 #9 stream_prepare (job=0x55c9d49d84a0) at block/stream.c:150 #10 job_prepare (job=0x55c9d49d84a0) at job.c:761 #11 job_txn_apply (txn=<optimized out>, fn=<optimized out>) at job.c:145 #12 job_do_finalize (job=0x55c9d49d84a0) at job.c:778 #13 job_completed_txn_success (job=0x55c9d49d84a0) at job.c:832 #14 job_completed (job=0x55c9d49d84a0) at job.c:845 #15 job_completed (job=0x55c9d49d84a0) at job.c:836 #16 job_exit (opaque=0x55c9d49d84a0) at job.c:864 #17 aio_bh_call (bh=0x55c9d471a160) at util/async.c:117 #18 aio_bh_poll (ctx=ctx@entry=0x55c9d3c46720) at util/async.c:117 #19 aio_poll (ctx=ctx@entry=0x55c9d3c46720, blocking=blocking@entry=true) at util/aio-posix.c:728 #20 bdrv_parent_drained_begin_single (poll=true, c=0x55c9d3d558f0) at block/io.c:121 #21 bdrv_parent_drained_begin_single (c=c@entry=0x55c9d3d558f0, poll=poll@entry=true) at block/io.c:114 #22 bdrv_replace_child_noperm (child=child@entry=0x55c9d3d558f0, new_bs=new_bs@entry=0x55c9d3d27300) at block.c:2258 #23 bdrv_replace_child (child=child@entry=0x55c9d3d558f0, new_bs=new_bs@entry=0x55c9d3d27300) at block.c:2320 #24 bdrv_root_attach_child (child_bs=child_bs@entry=0x55c9d3d27300, child_name=child_name@entry=0x55c9d241d478 "backing", child_role=child_role@entry=0x55c9d26ecee0 <child_backing>, ctx=<optimized out>, perm=<optimized out>, shared_perm=21, opaque=0x55c9d3cc2060, errp=0x7ffd11710c60) at block.c:2424 #25 bdrv_attach_child (parent_bs=parent_bs@entry=0x55c9d3cc2060, child_bs=child_bs@entry=0x55c9d3d27300, child_name=child_name@entry=0x55c9d241d478 "backing", child_role=child_role@entry=0x55c9d26ecee0 <child_backing>, errp=errp@entry=0x7ffd11710c60) at block.c:5876 #26 bdrv_set_backing_hd (bs=bs@entry=0x55c9d3cc2060, backing_hd=backing_hd@entry=0x55c9d3d27300, errp=errp@entry=0x7ffd11710c60) at block.c:2576 #27 stream_prepare (job=0x55c9d495ead0) at block/stream.c:150 ... Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20200316060631.30052-2-vsementsov@virtuozzo.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit 6e57963a77df1e275a73dab4c6a7ec9a9d3468d4) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22block: Avoid memleak on qcow2 image info failureEric Blake
If we fail to get bitmap info, we must not leak the encryption info. Fixes: b8968c875f403 Fixes: Coverity CID 1421894 Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20200320183620.1112123-1-eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Andrey Shinkevich <andrey.shinkevich@virtuozzo.com> Tested-by: Andrey Shinkevich <andrey.shinkevich@virtuozzo.com> Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit 71eaec2e8c7c8d266137b5c5f42da0bd6d6b5eb7) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22ppc/ppc405_boards: Remove unnecessary NULL checkPhilippe Mathieu-Daudé
This code is inside the "if (dinfo)" condition, so testing again here whether it is NULL is unnecessary. Fixes: dd59bcae7 (Don't size flash memory to match backing image) Reported-by: Coverity (CID 1421917) Suggested-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200320155740.5342-1-philmd@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit 1583794b9b36911df116cc726750dadbeeac506a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22iotests: Fix nonportable use of od --endianEric Blake
Tests 261 and 272 fail on RHEL 7 with coreutils 8.22, since od --endian was not added until coreutils 8.23. Fix this by manually constructing the final value one byte at a time. Fixes: fc8ba423 Reported-by: Andrey Shinkevich <andrey.shinkevich@virtuozzo.com> Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Message-Id: <20200226125424.481840-1-eblake@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit 69135eb30b9c3fca583737a96df015174dc8e6dd) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22pc-bios: s390x: Save iplb location in lowcoreJanosch Frank
The POP states that for a list directed IPL the IPLB is stored into memory by the machine loader and its address is stored at offset 0x14 of the lowcore. ZIPL currently uses the address in offset 0x14 to access the IPLB and acquire flags about secure boot. If the IPLB address points into memory which has an unsupported mix of flags set, ZIPL will panic instead of booting the OS. As the lowcore can have quite a high entropy for a guest that did drop out of protected mode (i.e. rebooted) we encountered the ZIPL panic quite often. Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Tested-by: Marc Hartmayer <mhartmay@linux.ibm.com> Message-Id: <20200304114231.23493-19-frankja@linux.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> (cherry picked from commit 9bfc04f9ef6802fff0fc77130ff345a541783363) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22hw/arm/cubieboard: use ARM Cortex-A8 as the default CPU in machine definitionNiek Linnenbank
The Cubieboard is a singleboard computer with an Allwinner A10 System-on-Chip [1]. As documented in the Allwinner A10 User Manual V1.5 [2], the SoC has an ARM Cortex-A8 processor. Currently the Cubieboard machine definition specifies the ARM Cortex-A9 in its description and as the default CPU. This patch corrects the Cubieboard machine definition to use the ARM Cortex-A8. The only user-visible effect is that our textual description of the machine was wrong, because hw/arm/allwinner-a10.c always creates a Cortex-A8 CPU regardless of the default value in the MachineClass struct. [1] http://docs.cubieboard.org/products/start#cubieboard1 [2] https://linux-sunxi.org/File:Allwinner_A10_User_manual_V1.5.pdf Fixes: 8a863c8120994981a099 Signed-off-by: Niek Linnenbank <nieklinnenbank@gmail.com> Message-id: 20200227220149.6845-2-nieklinnenbank@gmail.com Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> [note in commit message that the bug didn't have much visible effect] Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 2104df2a1fbf44b2564427aa72fd58d66ce290a7) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22vhost-user-blk: delete virtioqueues in unrealize to fix memleaksPan Nengyuan
virtio queues forgot to delete in unrealize, and aslo error path in realize, this patch fix these memleaks, the leak stack is as follow: Direct leak of 114688 byte(s) in 16 object(s) allocated from: #0 0x7f24024fdbf0 in calloc (/lib64/libasan.so.3+0xcabf0) #1 0x7f2401642015 in g_malloc0 (/lib64/libglib-2.0.so.0+0x50015) #2 0x55ad175a6447 in virtio_add_queue /mnt/sdb/qemu/hw/virtio/virtio.c:2327 #3 0x55ad17570cf9 in vhost_user_blk_device_realize /mnt/sdb/qemu/hw/block/vhost-user-blk.c:419 #4 0x55ad175a3707 in virtio_device_realize /mnt/sdb/qemu/hw/virtio/virtio.c:3509 #5 0x55ad176ad0d1 in device_set_realized /mnt/sdb/qemu/hw/core/qdev.c:876 #6 0x55ad1781ff9d in property_set_bool /mnt/sdb/qemu/qom/object.c:2080 #7 0x55ad178245ae in object_property_set_qobject /mnt/sdb/qemu/qom/qom-qobject.c:26 #8 0x55ad17821eb4 in object_property_set_bool /mnt/sdb/qemu/qom/object.c:1338 #9 0x55ad177aeed7 in virtio_pci_realize /mnt/sdb/qemu/hw/virtio/virtio-pci.c:1801 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20200224041336.30790-2-pannengyuan@huawei.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 13e5468127111bf44c5dc314d1dd2ec5a65dfec4) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22virtio-crypto: do delete ctrl_vq in virtio_crypto_device_unrealizePan Nengyuan
Similar to other virtio-deivces, ctrl_vq forgot to delete in virtio_crypto_device_unrealize, this patch fix it. This device has aleardy maintained vq pointers. Thus, we use the new virtio_delete_queue function directly to do the cleanup. The leak stack: Direct leak of 10752 byte(s) in 3 object(s) allocated from: #0 0x7f4c024b1970 in __interceptor_calloc (/lib64/libasan.so.5+0xef970) #1 0x7f4c018be49d in g_malloc0 (/lib64/libglib-2.0.so.0+0x5249d) #2 0x55a2f8017279 in virtio_add_queue /mnt/sdb/qemu-new/qemu_test/qemu/hw/virtio/virtio.c:2333 #3 0x55a2f8057035 in virtio_crypto_device_realize /mnt/sdb/qemu-new/qemu_test/qemu/hw/virtio/virtio-crypto.c:814 #4 0x55a2f8005d80 in virtio_device_realize /mnt/sdb/qemu-new/qemu_test/qemu/hw/virtio/virtio.c:3531 #5 0x55a2f8497d1b in device_set_realized /mnt/sdb/qemu-new/qemu_test/qemu/hw/core/qdev.c:891 #6 0x55a2f8b48595 in property_set_bool /mnt/sdb/qemu-new/qemu_test/qemu/qom/object.c:2238 #7 0x55a2f8b54fad in object_property_set_qobject /mnt/sdb/qemu-new/qemu_test/qemu/qom/qom-qobject.c:26 #8 0x55a2f8b4de2c in object_property_set_bool /mnt/sdb/qemu-new/qemu_test/qemu/qom/object.c:1390 #9 0x55a2f80609c9 in virtio_crypto_pci_realize /mnt/sdb/qemu-new/qemu_test/qemu/hw/virtio/virtio-crypto-pci.c:58 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Cc: "Gonglei (Arei)" <arei.gonglei@huawei.com> Message-Id: <20200225075554.10835-5-pannengyuan@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit d56e1c8256cb37e68f9b5d98c6cc4e6ca463f1fd) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22virtio-pmem: do delete rq_vq in virtio_pmem_unrealizePan Nengyuan
Similar to other virtio-devices, rq_vq forgot to delete in virtio_pmem_unrealize, this patch fix it. This device has already maintained a vq pointer, thus we use the new virtio_delete_queue function directly to do the cleanup. Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Message-Id: <20200225075554.10835-4-pannengyuan@huawei.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 9861546e1dae05c5152de7d3bd14e341ecadc972) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22target/arm: Correct definition of PMCRDPPeter Maydell
The PMCR_EL0.DP bit is bit 5, which is 0x20, not 0x10. 0x10 is 'X'. Correct our #define of PMCRDP and add the missing PMCRX. We do have the correct behaviour for handling the DP bit being set, so this fixes a guest-visible bug. Fixes: 033614c47de Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20200214175116.9164-17-peter.maydell@linaro.org (cherry picked from commit a1ed04dd79aabb9dbeeb5fa7d49f1a3de0357553) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22block: Fix VM size field width in snapshot dumpMax Reitz
When printing the snapshot list (e.g. with qemu-img snapshot -l), the VM size field is only seven characters wide. As of de38b5005e9, this is not necessarily sufficient: We generally print three digits, and this may require a decimal point. Also, the unit field grew from something as plain as "M" to " MiB". This means that number and unit may take up eight characters in total; but we also want spaces in front. Considering previously the maximum width was four characters and the field width was chosen to be three characters wider, let us adjust the field width to be eleven now. Fixes: de38b5005e946aa3714963ea4c501e279e7d3666 Buglink: https://bugs.launchpad.net/qemu/+bug/1859989 Signed-off-by: Max Reitz <mreitz@redhat.com> Message-Id: <20200117105859.241818-2-mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit 804359b8b90f76d9d8fbe8d85a6544b68f107f10) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22block: fix crash on zero-length unaligned write and readVladimir Sementsov-Ogievskiy
Commit 7a3f542fbd "block/io: refactor padding" occasionally dropped aligning for zero-length request: bdrv_init_padding() blindly return false if bytes == 0, like there is nothing to align. This leads the following command to crash: ./qemu-io --image-opts -c 'write 1 0' \ driver=blkdebug,align=512,image.driver=null-co,image.size=512 >> qemu-io: block/io.c:1955: bdrv_aligned_pwritev: Assertion `(offset & (align - 1)) == 0' failed. >> Aborted (core dumped) Prior to 7a3f542fbd we does aligning of such zero requests. Instead of recovering this behavior let's just do nothing on such requests as it is useless. Note that driver may have special meaning of zero-length reqeusts, like qcow2_co_pwritev_compressed_part, so we can't skip any zero-length operation. But for unaligned ones, we can't pass it to driver anyway. This commit also fixes crash in iotest 80 running with -nocache: ./check -nocache -qcow2 80 which crashes on same assertion due to trying to read empty extra data in qcow2_do_read_snapshots(). Cc: qemu-stable@nongnu.org # v4.2 Fixes: 7a3f542fbd Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Message-id: 20200206164245.17781-1-vsementsov@virtuozzo.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> (cherry picked from commit ac9d00bf7b47acae6b0e42910d9ed55fef3af5b8) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22target/arm/monitor: query-cpu-model-expansion crashed qemu when using ↵Liang Yan
machine type none Commit e19afd566781 mentioned that target-arm only supports queryable cpu models 'max', 'host', and the current type when KVM is in use. The logic works well until using machine type none. For machine type none, cpu_type will be null if cpu option is not set by command line, strlen(cpu_type) will terminate process. So We add a check above it. This won't affect i386 and s390x since they do not use current_cpu. Signed-off-by: Liang Yan <lyan@suse.com> Message-id: 20200203134251.12986-1-lyan@suse.com Reviewed-by: Andrew Jones <drjones@redhat.com> Tested-by: Andrew Jones <drjones@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 0999a4ba8718aa96105b978d3567fc7e90244c7e) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22iotests: add test for backup-top failure on permission activationVladimir Sementsov-Ogievskiy
This test checks that bug is really fixed by previous commit. Cc: qemu-stable@nongnu.org # v4.2.0 Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-id: 20200121142802.21467-3-vsementsov@virtuozzo.com Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit a541fcc27c98b96da187c7d4573f3270f3ddd283) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22block/backup-top: fix failure pathVladimir Sementsov-Ogievskiy
We can't access top after call bdrv_backup_top_drop, as it is already freed at this time. Also, no needs to unref target child by hand, it will be unrefed on bdrv_close() automatically. So, just do bdrv_backup_top_drop if append succeed and one bdrv_unref otherwise. Note, that in !appended case bdrv_unref(top) moved into drained section on source. It doesn't really matter, but just for code simplicity. Fixes: 7df7868b96404 Cc: qemu-stable@nongnu.org # v4.2.0 Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Message-id: 20200121142802.21467-2-vsementsov@virtuozzo.com Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit 0df62f45c1de6c020f1e6fba4eeafd248209b003) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22block: fix memleaks in bdrv_refresh_filenamePan Nengyuan
If we call the qmp 'query-block' while qemu is working on 'block-commit', it will cause memleaks, the memory leak stack is as follow: Indirect leak of 12360 byte(s) in 3 object(s) allocated from: #0 0x7f80f0b6d970 in __interceptor_calloc (/lib64/libasan.so.5+0xef970) #1 0x7f80ee86049d in g_malloc0 (/lib64/libglib-2.0.so.0+0x5249d) #2 0x55ea95b5bb67 in qdict_new /mnt/sdb/qemu-4.2.0-rc0/qobject/qdict.c:29 #3 0x55ea956cd043 in bdrv_refresh_filename /mnt/sdb/qemu-4.2.0-rc0/block.c:6427 #4 0x55ea956cc950 in bdrv_refresh_filename /mnt/sdb/qemu-4.2.0-rc0/block.c:6399 #5 0x55ea956cc950 in bdrv_refresh_filename /mnt/sdb/qemu-4.2.0-rc0/block.c:6399 #6 0x55ea956cc950 in bdrv_refresh_filename /mnt/sdb/qemu-4.2.0-rc0/block.c:6399 #7 0x55ea958818ea in bdrv_block_device_info /mnt/sdb/qemu-4.2.0-rc0/block/qapi.c:56 #8 0x55ea958879de in bdrv_query_info /mnt/sdb/qemu-4.2.0-rc0/block/qapi.c:392 #9 0x55ea9588b58f in qmp_query_block /mnt/sdb/qemu-4.2.0-rc0/block/qapi.c:578 #10 0x55ea95567392 in qmp_marshal_query_block qapi/qapi-commands-block-core.c:95 Indirect leak of 4120 byte(s) in 1 object(s) allocated from: #0 0x7f80f0b6d970 in __interceptor_calloc (/lib64/libasan.so.5+0xef970) #1 0x7f80ee86049d in g_malloc0 (/lib64/libglib-2.0.so.0+0x5249d) #2 0x55ea95b5bb67 in qdict_new /mnt/sdb/qemu-4.2.0-rc0/qobject/qdict.c:29 #3 0x55ea956cd043 in bdrv_refresh_filename /mnt/sdb/qemu-4.2.0-rc0/block.c:6427 #4 0x55ea956cc950 in bdrv_refresh_filename /mnt/sdb/qemu-4.2.0-rc0/block.c:6399 #5 0x55ea956cc950 in bdrv_refresh_filename /mnt/sdb/qemu-4.2.0-rc0/block.c:6399 #6 0x55ea9569f301 in bdrv_backing_attach /mnt/sdb/qemu-4.2.0-rc0/block.c:1064 #7 0x55ea956a99dd in bdrv_replace_child_noperm /mnt/sdb/qemu-4.2.0-rc0/block.c:2283 #8 0x55ea956b9b53 in bdrv_replace_node /mnt/sdb/qemu-4.2.0-rc0/block.c:4196 #9 0x55ea956b9e49 in bdrv_append /mnt/sdb/qemu-4.2.0-rc0/block.c:4236 #10 0x55ea958c3472 in commit_start /mnt/sdb/qemu-4.2.0-rc0/block/commit.c:306 #11 0x55ea94b68ab0 in qmp_block_commit /mnt/sdb/qemu-4.2.0-rc0/blockdev.c:3459 #12 0x55ea9556a7a7 in qmp_marshal_block_commit qapi/qapi-commands-block-core.c:407 Fixes: bb808d5f5c0978828a974d547e6032402c339555 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Message-id: 20200116085600.24056-1-pannengyuan@huawei.com Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit cb8956144ccaccf23d5cc4167677e2c84fa5a9f8) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22target/arm: fix TCG leak for fcvt half->doubleAlex Bennée
When support for the AHP flag was added we inexplicably only freed the new temps in one of the two legs. Move those tcg_temp_free to the same level as the allocation to fix that leak. Fixes: 486624fcd3eac Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20200131153439.26027-1-alex.bennee@linaro.org Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit aeab8e5eb220cc5ff84b0b68b9afccc611bf0fcd) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22audio/oss: fix buffer pos calculationGerd Hoffmann
Fixes: 3ba4066d085f ("ossaudio: port to the new audio backend api") Reported-by: ziming zhang <ezrakiez@gmail.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-Id: <20200120101804.29578-1-kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> (cherry picked from commit 7a4ede0047a8613b0e3b72c9d351038f013dd357) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22hw/intc/arm_gicv3_kvm: Stop wrongly programming GICR_PENDBASER.PTZ bitZenghui Yu
If LPIs are disabled, KVM will just ignore the GICR_PENDBASER.PTZ bit when restoring GICR_CTLR. Setting PTZ here makes littlt sense in "reduce GIC initialization time". And what's worse, PTZ is generally programmed by guest to indicate to the Redistributor whether the LPI Pending table is zero when enabling LPIs. If migration is triggered when the PTZ has just been cleared by guest (and before enabling LPIs), we will see PTZ==1 on the destination side, which is not as expected. Let's just drop this hackish userspace behavior. Also take this chance to refine the comment a bit. Fixes: 367b9f527bec ("hw/intc/arm_gicv3_kvm: Implement get/put functions") Signed-off-by: Zenghui Yu <yuzenghui@huawei.com> Message-id: 20200119133051.642-1-yuzenghui@huawei.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 618bacabd3c8c3360be795cd8763bacdf5bec101) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22tpm-ppi: page-align PPI RAMMarc-André Lureau
post-copy migration fails on destination with error such as: 2019-12-26T10:22:44.714644Z qemu-kvm: ram_block_discard_range: Unaligned start address: 0x559d2afae9a0 Use qemu_memalign() to constrain the PPI RAM memory alignment. Cc: qemu-stable@nongnu.org Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Message-id: 20200103074000.1006389-3-marcandre.lureau@redhat.com (cherry picked from commit 71e415c8a75c130875f14d6b2136825789feb297) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22block/backup: fix memory leak in bdrv_backup_top_append()Eiichi Tsukata
bdrv_open_driver() allocates bs->opaque according to drv->instance_size. There is no need to allocate it and overwrite opaque in bdrv_backup_top_append(). Reproducer: $ QTEST_QEMU_BINARY=./x86_64-softmmu/qemu-system-x86_64 valgrind -q --leak-check=full tests/test-replication -p /replication/secondary/start ==29792== 24 bytes in 1 blocks are definitely lost in loss record 52 of 226 ==29792== at 0x483AB1A: calloc (vg_replace_malloc.c:762) ==29792== by 0x4B07CE0: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.6000.7) ==29792== by 0x12BAB9: bdrv_open_driver (block.c:1289) ==29792== by 0x12BEA9: bdrv_new_open_driver (block.c:1359) ==29792== by 0x1D15CB: bdrv_backup_top_append (backup-top.c:190) ==29792== by 0x1CC11A: backup_job_create (backup.c:439) ==29792== by 0x1CD542: replication_start (replication.c:544) ==29792== by 0x1401B9: replication_start_all (replication.c:52) ==29792== by 0x128B50: test_secondary_start (test-replication.c:427) ... Fixes: 7df7868b9640 ("block: introduce backup-top filter driver") Signed-off-by: Eiichi Tsukata <devel@etsukata.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit fb574de81bfdd71fdb0315105a3a7761efb68395) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22s390x: adapter routes error handlingCornelia Huck
If the kernel irqchip has been disabled, we don't want the {add,release}_adapter_routes routines to call any kvm_irqchip_* interfaces, as they may rely on an irqchip actually having been created. Just take a quick exit in that case instead. If you are trying to use irqfd without a kernel irqchip, we will fail with an error. Also initialize routes->gsi[] with -1 in the virtio-ccw handling, to make sure we don't trip over other errors, either. (Nobody else uses the gsi array in that structure.) Fixes: d426d9fba8ea ("s390x/virtio-ccw: wire up irq routing and irqfds") Reviewed-by: Thomas Huth <thuth@redhat.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Message-Id: <20200117111147.5006-1-cohuck@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com> (cherry picked from commit 3c5fd8074335c67777d9391b84f97070c35d9c63) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22target/i386: kvm: initialize feature MSRs very earlyPaolo Bonzini
Some read-only MSRs affect the behavior of ioctls such as KVM_SET_NESTED_STATE. We can initialize them once and for all right after the CPU is realized, since they will never be modified by the guest. Reported-by: Qingua Cheng <qcheng@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <1579544504-3616-2-git-send-email-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 420ae1fc51c99abfd03b1c590f55617edd2a2bed) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22target/arm: Fix PAuth sbox functionsVincent Dehors
In the PAC computation, sbox was applied over wrong bits. As this is a 4-bit sbox, bit index should be incremented by 4 instead of 16. Test vector from QARMA paper (https://eprint.iacr.org/2016/444.pdf) was used to verify one computation of the pauth_computepac() function which uses sbox2. Launchpad: https://bugs.launchpad.net/bugs/1859713 Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Vincent DEHORS <vincent.dehors@smile.fr> Signed-off-by: Adrien GRASSEIN <adrien.grassein@smile.fr> Message-id: 20200116230809.19078-2-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 de0b1bae6461f67243282555475f88b2384a1eb9) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22m68k: Fix regression causing Single-Step via GDB/RSP to not single stepLaurent Vivier
A regression that was introduced, with the refactor to TranslatorOps, drops two lines that update the PC when single-stepping is being performed. Fixes: 11ab74b01e0a ("target/m68k: Convert to TranslatorOps") Reported-by: Lucien Murray-Pitts <lucienmp_antispam@yahoo.com> Suggested-by: Lucien Murray-Pitts <lucienmp_antispam@yahoo.com> Suggested-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20200116165454.2076265-1-laurent@vivier.eu> (cherry picked from commit 322f244aaa80a5208090d41481c1c09c6face66b) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22Revert "vnc: allow fall back to RAW encoding"Gerd Hoffmann
This reverts commit de3f7de7f4e257ce44cdabb90f5f17ee99624557. Remove VNC optimization to reencode framebuffer update as raw if it's smaller than the default encoding. QEMU's implementation was naive and didn't account for the ZLIB z_stream mutating with each compression. Because of the mutation, simply resetting the output buffer's offset wasn't sufficient to "rewind" the operation. The mutated z_stream would generate future zlib blocks which referred to symbols in past blocks which weren't sent. This would lead to artifacting. Considering that ZRLE is never larger than raw and even though ZLIB can occasionally be fractionally larger than raw, the overhead of implementing this optimization correctly isn't worth it. Signed-off-by: Cameron Esfahani <dirty@apple.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 0780ec7be82dd4781e9fd216b5d99a125882ff5a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22migration: Rate limit inside host pagesDr. David Alan Gilbert
When using hugepages, rate limiting is necessary within each huge page, since a 1G huge page can take a significant time to send, so you end up with bursty behaviour. Fixes: 4c011c37ecb3 ("postcopy: Send whole huge pages") Reported-by: Lin Ma <LMa@suse.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> (cherry picked from commit 97e1e06780e70f6e98a0d2df881e0c0927d3aeb6) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22runstate: ignore finishmigrate -> prelaunch transitionLaurent Vivier
Commit 1bd71dce4bf2 tries to prevent a finishmigrate -> prelaunch transition by exiting at the beginning of the main_loop_should_exit() function if the state is already finishmigrate. As the finishmigrate state is set in the migration thread it can happen concurrently to the function. The migration thread and the function are normally protected by the iothread mutex and thus the state should no evolve between the start of the function and its end. Unfortunately during the function life the lock is released by pause_all_vcpus() just before the point we need to be sure we are not in finishmigrate state and if the migration thread is waiting for the lock it will take the opportunity to change the state to finishmigrate. The only way to be sure we are not in the finishmigrate state when we need is to check the state after the pause_all_vcpus() function. Fixes: 1bd71dce4bf2 ("runstate: ignore exit request in finish migrate state") Signed-off-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> (cherry picked from commit ddad81bd28de665475a87693a93e6cf5d6fd8bab) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22target/arm: Return correct IL bit in merge_syn_data_abortJeff Kubascik
The IL bit is set for 32-bit instructions, thus passing false with the is_16bit parameter to syn_data_abort_with_iss() makes a syn mask that always has the IL bit set. Pass is_16bit as true to make the initial syn mask have IL=0, so that the final IL value comes from or'ing template_syn. Cc: qemu-stable@nongnu.org Fixes: aaa1f954d4ca ("target-arm: A64: Create Instruction Syndromes for Data Aborts") Signed-off-by: Jeff Kubascik <jeff.kubascik@dornerworks.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200117004618.2742-2-richard.henderson@linaro.org [rth: Extracted this as a self-contained bug fix from a larger patch] Signed-off-by: Richard Henderson <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 30d544839e278dc76017b9a42990c41e84a34377) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22migration-test: ppc64: fix FORTH test programLaurent Vivier
Commit e51e711b1bef has moved the initialization of start_address and end_address after the definition of the command line argument, where the nvramrc is initialized, and thus the loop is between 0 and 0 rather than 1 MiB and 100 MiB. It doesn't affect the result of the test if all the tests are run in sequence because the two first tests don't run the loop, so the values are correctly initialized when we actually need them. But it hangs when we ask to run only one test, for instance: QTEST_QEMU_BINARY=ppc64-softmmu/qemu-system-ppc64 \ tests/migration-test -m=quick -p /ppc64/migration/validate_uuid_error Fixes: e51e711b1bef ("tests/migration: Add migration-test header file") Cc: wei@redhat.com Signed-off-by: Laurent Vivier <lvivier@redhat.com> Message-Id: <20200107163437.52139-1-lvivier@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 16c5c6928ff53bd95e6504301ef6c285501531e7) Conflicts: tests/migration-test.c *drop context dep. on 68d95609 Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22blkdebug: Allow taking/unsharing permissionsMax Reitz
Sometimes it is useful to be able to add a node to the block graph that takes or unshare a certain set of permissions for debugging purposes. This patch adds this capability to blkdebug. (Note that you cannot make blkdebug release or share permissions that it needs to take or cannot share, because this might result in assertion failures in the block layer. But if the blkdebug node has no parents, it will not take any permissions and share everything by default, so you can then freely choose what permissions to take and share.) Signed-off-by: Max Reitz <mreitz@redhat.com> Message-id: 20191108123455.39445-4-mreitz@redhat.com Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit 69c6449ff10fe4e3219e960549307096d5366bd0) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22block: Add bdrv_qapi_perm_to_blk_perm()Max Reitz
We need some way to correlate QAPI BlockPermission values with BLK_PERM_* flags. We could: (1) have the same order in the QAPI definition as the the BLK_PERM_* flags are in LSb-first order. However, then there is no guarantee that they actually match (e.g. when someone modifies the QAPI schema without thinking of the BLK_PERM_* definitions). We could add static assertions, but these would break what’s good about this solution, namely its simplicity. (2) define the BLK_PERM_* flags based on the BlockPermission values. But this way whenever someone were to modify the QAPI order (perfectly sensible in theory), the BLK_PERM_* values would change. Because these values are used for file locking, this might break file locking between different qemu versions. Therefore, go the slightly more cumbersome way: Add a function to translate from the QAPI constants to the BLK_PERM_* flags. Signed-off-by: Max Reitz <mreitz@redhat.com> Message-id: 20191108123455.39445-2-mreitz@redhat.com Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit 7b1d9c4df0603fbc526226a9c5ef91118aa6c957) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22hw/arm/smmuv3: Report F_STE_FETCH fault address in correct word positionSimon Veith
The smmuv3_record_event() function that generates the F_STE_FETCH error uses the EVT_SET_ADDR macro to record the fetch address, placing it in 32-bit words 4 and 5. The correct position for this address is in words 6 and 7, per the SMMUv3 Architecture Specification. Update the function to use the EVT_SET_ADDR2 macro instead, which is the macro intended for writing to these words. ref. ARM IHI 0070C, section 7.3.4. Signed-off-by: Simon Veith <sveith@amazon.de> Acked-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Message-id: 1576509312-13083-7-git-send-email-sveith@amazon.de Cc: Eric Auger <eric.auger@redhat.com> Cc: qemu-devel@nongnu.org Cc: qemu-arm@nongnu.org Acked-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit b255cafb59578d16716186ed955717bc8f87bdb7) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22hw/arm/smmuv3: Use correct bit positions in EVT_SET_ADDR2 macroSimon Veith
The bit offsets in the EVT_SET_ADDR2 macro do not match those specified in the ARM SMMUv3 Architecture Specification. In all events that use this macro, e.g. F_WALK_EABT, the faulting fetch address or IPA actually occupies the 32-bit words 6 and 7 in the event record contiguously, with the upper and lower unused bits clear due to alignment or maximum supported address bits. How many bits are clear depends on the individual event type. Update the macro to write to the correct words in the event record so that guest drivers can obtain accurate address information on events. ref. ARM IHI 0070C, sections 7.3.12 through 7.3.16. Signed-off-by: Simon Veith <sveith@amazon.de> Acked-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Message-id: 1576509312-13083-6-git-send-email-sveith@amazon.de Cc: Eric Auger <eric.auger@redhat.com> Cc: qemu-devel@nongnu.org Cc: qemu-arm@nongnu.org Acked-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit a7f65ceb851af5a5b639c6e30801076d848db2c2) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22hw/arm/smmuv3: Align stream table base address to table sizeSimon Veith
Per the specification, and as observed in hardware, the SMMUv3 aligns the SMMU_STRTAB_BASE address to the size of the table by masking out the respective least significant bits in the ADDR field. Apply this masking logic to our smmu_find_ste() lookup function per the specification. ref. ARM IHI 0070C, section 6.3.23. Signed-off-by: Simon Veith <sveith@amazon.de> Acked-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Message-id: 1576509312-13083-5-git-send-email-sveith@amazon.de Cc: Eric Auger <eric.auger@redhat.com> Cc: qemu-devel@nongnu.org Cc: qemu-arm@nongnu.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 41678c33aac61261522b74f08595ccf2221a430a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22hw/arm/smmuv3: Check stream IDs against actual table LOG2SIZESimon Veith
When checking whether a stream ID is in range of the stream table, we have so far been only checking it against our implementation limit (SMMU_IDR1_SIDSIZE). However, the guest can program the STRTAB_BASE_CFG.LOG2SIZE field to a size that is smaller than this limit. Check the stream ID against this limit as well to match the hardware behavior of raising C_BAD_STREAMID events in case the limit is exceeded. Also, ensure that we do not go one entry beyond the end of the table by checking that its index is strictly smaller than the table size. ref. ARM IHI 0070C, section 6.3.24. Signed-off-by: Simon Veith <sveith@amazon.de> Acked-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Message-id: 1576509312-13083-4-git-send-email-sveith@amazon.de Cc: Eric Auger <eric.auger@redhat.com> Cc: qemu-devel@nongnu.org Cc: qemu-arm@nongnu.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 05ff2fb80ce4ca85d8a39d48ff8156de739b4f51) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22hw/arm/smmuv3: Correct SMMU_BASE_ADDR_MASK valueSimon Veith
There are two issues with the current value of SMMU_BASE_ADDR_MASK: - At the lower end, we are clearing bits [4:0]. Per the SMMUv3 spec, we should also be treating bit 5 as zero in the base address. - At the upper end, we are clearing bits [63:48]. Per the SMMUv3 spec, only bits [63:52] must be explicitly treated as zero. Update the SMMU_BASE_ADDR_MASK value to mask out bits [63:52] and [5:0]. ref. ARM IHI 0070C, section 6.3.23. Signed-off-by: Simon Veith <sveith@amazon.de> Acked-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Message-id: 1576509312-13083-3-git-send-email-sveith@amazon.de Cc: Eric Auger <eric.auger@redhat.com> Cc: qemu-devel@nongnu.org Cc: qemu-arm@nongnu.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 3293b9f514a413e019b7dbc9d543458075b4849e) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
generated by cgit v1.2.3 (git 2.26.2) at 2024-11-22 00:16:55 +0000