sort by:
Revision Author Date Message Commit Date
aba5970 usb/dev-mtp: Fix use of uninitialized values This fixes: hw/usb/dev-mtp.c:971:5: warning: 4th function call argument is an uninitialized value trace_usb_mtp_op_get_partial_object(s->dev.addr, o->handle, o->path, c->argv[1], c->argv[2]); ^~~~~~~~~~ and: hw/usb/dev-mtp.c:981:12: warning: Assigned value is garbage or undefined offset = c->argv[1]; ^ ~~~~~~~~~~ Reported-by: Clang Static Analyzer Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20180604151421.23385-3-f4bug@amsat.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 62713a2e50f653162387451034f1a2490e87be88) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 15:18:22 UTC
17e3fcb usb: correctly handle Zero Length Packets USB Specification Revision 2.0, §5.5.3: The Data stage of a control transfer from an endpoint to the host is complete when the endpoint does one of the following: • Has transferred exactly the amount of data specified during the Setup stage • Transfers a packet with a payload size less than wMaxPacketSize or transfers a zero-length packet" hw/usb/redirect.c:802:9: warning: Declared variable-length array (VLA) has zero size uint8_t buf[size]; ^~~~~~~~~~~ ~~~~ Reported-by: Clang Static Analyzer Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20180604151421.23385-2-f4bug@amsat.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit bf78fb1c1b61a819a47f7a1dbecf9934b9f32a0d) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 15:18:16 UTC
9e4fa09 gdbstub: fix off-by-one in gdb_handle_packet() memtohex() adds an extra trailing NUL character. Reported-by: AddressSanitizer Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: 20180408145933.1149-1-f4bug@amsat.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 9005774b27b6aa5e1c99d80bd59d5d048c2f7077) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 15:18:10 UTC
a8e4217 Merge tag 'tags/s390x-20180621-211-stable' into stable-2.11-staging update s390-ccw.img for stable Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 15:16:52 UTC
728d6c6 pc-bios/s390-ccw.img: update image for stable Contains the following commits: - s390: Do not pass inofficial IPL type to the guest - s390-ccw: force diag 308 subcode to unsigned long - pc-bios/s390-ccw: struct tpi_info must be declared as aligned(4) Signed-off-by: Cornelia Huck <cohuck@redhat.com> 21 June 2018, 08:22:15 UTC
1e13e7d tpm: lookup cancel path under tpm device class Since Linux commit 313d21eeab9282e, tpm devices have their own device class "tpm" and the cancel path must be looked up under /sys/class/tpm/ instead of /sys/class/misc/. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Stefan Berger <stefanb@linux.vnet.ibm.com> Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com> (cherry picked from commit 05b71fb207ab7f016e067bd2a40fc0804362eb74) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:08 UTC
a36591f tpm-passthrough: don't save guessed cancel_path in options The value is later unneeded, and may leak if the free visitor doesn't consider it since has_cancel_path is false. And for consistency with "path" it shouldn't be returned in get_tpm_options(). Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Stefan Berger <stefanb@linux.vnet.ibm.com> Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com> (cherry picked from commit 69c07db04625cb243db6e8a0ac0a8e3973dd961a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:08 UTC
0f04a8b s390-ccw-virtio: allow for systems larger that 7.999TB KVM does not allow memory regions > KVM_MEM_MAX_NR_PAGES, basically limiting the memory per slot to 8TB-4k. As memory slots on s390/kvm must be a multiple of 1MB we need start a new memory region if we cross 8TB-1M. With that (and optimistic overcommitment in the kernel) I was able to start a 24TB guest on a 1TB system. Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Message-Id: <20171211122146.162430-1-borntraeger@de.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> [CH: 1UL -> 1ULL in KVM_MEM_MAX_NR_PAGES; build fix on 32 bit hosts] Signed-off-by: Cornelia Huck <cohuck@redhat.com> (cherry picked from commit bb223055b9b327ec66e1f6d2fbaebaee0b8f3dbe) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:08 UTC
2ab0ce6 crypto: ensure we use a predictable TLS priority setting The TLS test cert generation relies on a fixed set of algorithms that are only usable under GNUTLS' default priority setting. When building QEMU with a custom distro specific priority setting, this can cause the TLS tests to fail. By forcing the tests to always use "NORMAL" priority we can make them more robust. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> (cherry picked from commit 057ad0b46992e3ec4ce29b9103162aa3c683f347) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:08 UTC
8bbb76e qapi: ensure stable sort ordering when checking QAPI entities Some early python 3.x versions will have different default ordering when calling the 'values()' method on a dict, compared to python 2.x and later 3.x versions. Explicitly sort the items to get a stable ordering. Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-Id: <20180116134217.8725-8-berrange@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> (cherry picked from commit f7a5376d4b667cf6c83c1d640e32d22456d7b5ee) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:07 UTC
6622e94 arm_gicv3_kvm: kvm_dist_get/put_priority: skip the registers banked by GICR_IPRIORITYR While for_each_dist_irq_reg loop starts from GIC_INTERNAL, it forgot to offset the date array and index. This will overlap the GICR registers value and leave the last GIC_INTERNAL irq's registers out of update. Fixes: 367b9f527becdd20ddf116e17a3c0c2bbc486920 Cc: qemu-stable@nongnu.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 1dcf3675196a1cec616ce71b067d9498590a60a6) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:07 UTC
99e051b iotests: Add test 221 to catch qemu-img map regression Although qemu-img creates aligned files (by rounding up), it must also gracefully handle files that are not sector-aligned. Test that the bug fixed in the previous patch does not recur. It's a bit annoying that we can see the (implicit) hole past the end of the file on to the next sector boundary, so if we ever reach the point where we report a byte-accurate size rather than our current behavior of always rounding up, this test will probably need a slight modification. Signed-off-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit c6a9d2f6f9bc0c163b3a3073126464a2446bad5f) Conflicts: tests/qemu-iotests/group * drop context dep on tests not present in 2.11 Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:07 UTC
9c5a843 qemu-img: Fix assert when mapping unaligned raw file Commit a290f085 exposed a latent bug in qemu-img map introduced during the conversion of block status to be byte-based. Earlier in commit 5e344dd8, the internal interface get_block_status() switched to take byte-based parameters, but still called a sector-based block layer function; as such, rounding was added in the lone caller to obey the contract. However, commit 237d78f8 changed get_block_status() to truly be byte-based, at which point rounding to sector boundaries can result in calling bdrv_block_status() with 'bytes == 0' (a coding error) when the boundary between data and a hole falls mid-sector (true for the past-EOF implicit hole present in POSIX files). Fix things by removing the rounding that is now no longer necessary. See also https://bugzilla.redhat.com/1589738 Fixes: 237d78f8 Reported-by: Dan Kenigsberg <danken@redhat.com> Reported-by: Nir Soffer <nsoffer@redhat.com> Reported-by: Maor Lipchuk <mlipchuk@redhat.com> CC: qemu-stable@nongnu.org Signed-off-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit e0b371ed5e2db079051139136fd0478728b6a58f) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:07 UTC
d8a919f vhost-user: delete net client if necessary As qemu_new_net_client create new ncs but error happens later, ncs will be left in global net_clients list and we can't use them any more, so we need to cleanup them. Cc: qemu-stable@nongnu.org Signed-off-by: linzhecheng <linzhecheng@huawei.com> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit c67daf4a24442d1bb404a11a6a54dc45ea10f234) Conflicts: net/vhost-user.c * drop functional dep on 4d0cf552 Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:07 UTC
f4e93bb tap: set vhostfd passed from qemu cli to non-blocking A guest boot hangs while probing the network interface when iommu_platform=on is used. The following qemu cli hangs without this patch: # $QEMU \ -netdev tap,fd=3,id=hostnet0,vhost=on,vhostfd=4 3<>/dev/tap67 4<>/dev/host-net \ -device virtio-net-pci,netdev=hostnet0,id=net0,iommu_platform=on,disable-legacy=on \ ... Commit: c471ad0e9bd46 (vhost_net: device IOTLB support) took care of setting vhostfd to non-blocking when QEMU opens /dev/host-net but if the fd is passed from qemu cli then we need to ensure that fd is set to non-blocking. Fixes: c471ad0e9bd46 ("vhost_net: device IOTLB support") Cc: qemu-stable@nongnu.org Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit d542800d1edc62f63f8a29cfa6bdd1a9536ae11c) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:07 UTC
afa43eb i386: define the AMD 'virt-ssbd' CPUID feature bit (CVE-2018-3639) AMD Zen expose the Intel equivalant to Speculative Store Bypass Disable via the 0x80000008_EBX[25] CPUID feature bit. This needs to be exposed to guest OS to allow them to protect against CVE-2018-3639. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20180521215424.13520-3-berrange@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> (cherry picked from commit 403503b162ffc33fb64cfefdf7b880acf41772cd) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:07 UTC
73521f6 i386: Define the Virt SSBD MSR and handling of it (CVE-2018-3639) "Some AMD processors only support a non-architectural means of enabling speculative store bypass disable (SSBD). To allow a simplified view of this to a guest, an architectural definition has been created through a new CPUID bit, 0x80000008_EBX[25], and a new MSR, 0xc001011f. With this, a hypervisor can virtualize the existence of this definition and provide an architectural method for using SSBD to a guest. Add the new CPUID feature, the new MSR and update the existing SSBD support to use this MSR when present." (from x86/speculation: Add virtualized speculative store bypass disable support in Linux). Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20180521215424.13520-4-berrange@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> (cherry picked from commit cfeea0c021db6234c154dbc723730e81553924ff) Conflicts: target/i386/kvm.c target/i386/machine.c * drop context dep on b77146e9a Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:07 UTC
4ce0b75 i386: define the 'ssbd' CPUID feature bit (CVE-2018-3639) New microcode introduces the "Speculative Store Bypass Disable" CPUID feature bit. This needs to be exposed to guest OS to allow them to protect against CVE-2018-3639. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Message-Id: <20180521215424.13520-2-berrange@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> (cherry picked from commit d19d1f965904a533998739698020ff4ee8a103da) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:07 UTC
84cfae0 vga: fix region calculation Typically the scanline length and the line offset are identical. But in case they are not our calculation for region_end is incorrect. Using line_offset is fine for all scanlines, except the last one where we have to use the actual scanline length. Fixes: CVE-2018-7550 Reported-by: Ross Lagerwall <ross.lagerwall@citrix.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Prasad J Pandit <pjp@fedoraproject.org> Tested-by: Ross Lagerwall <ross.lagerwall@citrix.com> Message-id: 20180309143704.13420-1-kraxel@redhat.com (cherry picked from commit 7cdc61becd095b64a786b2625f321624e7111f3d) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:07 UTC
d80b60f throttle: Fix crash on reopen The throttle block filter can be reopened, and with this it is possible to change the throttle group that the filter belongs to. The way the code does that is the following: - On throttle_reopen_prepare(): create a new ThrottleGroupMember and attach it to the new throttle group. - On throttle_reopen_commit(): detach the old ThrottleGroupMember, delete it and replace it with the new one. The problem with this is that by replacing the ThrottleGroupMember the previous value of io_limits_disabled is lost, causing an assertion failure in throttle_co_drain_end(). This problem can be reproduced by reopening a throttle node: $QEMU -monitor stdio -object throttle-group,id=tg0,x-iops-total=1000 \ -blockdev node-name=hd0,driver=qcow2,file.driver=file,file.filename=hd.qcow2 \ -blockdev node-name=root,driver=throttle,throttle-group=tg0,file=hd0,read-only=on (qemu) block_stream root block/throttle.c:214: throttle_co_drain_end: Assertion `tgm->io_limits_disabled' failed. Since we only want to change the throttle group on reopen there's no need to create a ThrottleGroupMember and discard the old one. It's easier if we simply detach it from its current group and attach it to the new one. Signed-off-by: Alberto Garcia <berto@igalia.com> Message-id: 20180608151536.7378-1-berto@igalia.com Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit bc33c047d1ec0b35c9cd8be62bcefae2da28654f) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:06 UTC
f647a4f iotests: Add case for a corrupted inactive image Reviewed-by: John Snow <jsnow@redhat.com> Tested-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> Message-id: 20180606193702.7113-4-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit c50abd175a88cd41c2c08339de91f6f6e4a7b162) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:06 UTC
f91f44f qcow2: Do not mark inactive images corrupt When signaling a corruption on a read-only image, qcow2 already makes fatal events non-fatal (i.e., they will not result in the image being closed, and the image header's corrupt flag will not be set). This is necessary because we cannot set the corrupt flag on read-only images, and it is possible because further corruption of read-only images is impossible. Inactive images are effectively read-only, too, so we should do the same for them. bdrv_is_writable() can tell us whether an image can actually be written to, so use its result instead of !bs->read_only. (Otherwise, the assert(!(bs->open_flags & BDRV_O_INACTIVE)) in bdrv_co_pwritev() will fail, crashing qemu.) Cc: qemu-stable@nongnu.org Signed-off-by: Max Reitz <mreitz@redhat.com> Message-id: 20180606193702.7113-3-mreitz@redhat.com Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit ddf3b47ef4b5ed0bf6558d4c2c8ae130b8d8a580) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:06 UTC
62891ca block: Make bdrv_is_writable() public This is a useful function for the whole block layer, so make it public. At the same time, users outside of block.c probably do not need to make use of the reopen functionality, so rename the current function to bdrv_is_writable_after_reopen() create a new bdrv_is_writable() function that just passes NULL to it for the reopen queue. Cc: qemu-stable@nongnu.org Signed-off-by: Max Reitz <mreitz@redhat.com> Message-id: 20180606193702.7113-2-mreitz@redhat.com Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit cc022140972f8b6ac3973c12ccf9dd6b1d2fd200) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:06 UTC
5d63953 arm_gicv3_kvm: kvm_dist_get/put: skip the registers banked by GICR While we skip the GIC_INTERNAL irqs, we don't change the register offset accordingly. This will overlap the GICR registers value and leave the last GIC_INTERNAL irq's registers out of update. Fix this by skipping the registers banked by GICR. Also for migration compatibility if the migration source (old version qemu) doesn't send gicd_no_migration_shift_bug = 1 to destination, then we shift the data of PPI to get the right data for SPI. Fixes: 367b9f527becdd20ddf116e17a3c0c2bbc486920 Cc: qemu-stable@nongnu.org Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com> Message-id: 1527816987-16108-1-git-send-email-zhaoshenglong@huawei.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 910e204841954b95c051b2ee49ab0f5c735ff93c) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:06 UTC
deabb45 ahci: fix PxCI register race Fixes: https://bugs.launchpad.net/qemu/+bug/1769189 AHCI presently signals completion prior to the PxCI register being cleared to indicate completion. If a guest driver attempts to issue a new command in its IRQ handler, it might be surprised to learn there is still a command pending. In the case of Windows 10's boot driver, it will actually poll the IRQ register hoping to find out when the command is done running -- which will never happen, as there isn't a command running. Fix this: clear PxCI in ahci_cmd_done and not in the asynchronous BH. Because it now runs synchronously, we don't need to check if the command is actually done by spying on the ATA registers. We know it's done. CC: qemu-stable <qemu-stable@nongnu.org> Reported-by: François Guerraz <kubrick@fgv6.net> Tested-by: Bruce Rogers <brogers@suse.com> Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Message-id: 20180531004323.4611-3-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com> (cherry picked from commit 5694c7eacce6b263ad7497cc1bb76aad746cfd4e) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:06 UTC
1623832 Fix libusb-1.0.22 deprecated libusb_set_debug with libusb_set_option libusb-1.0.22 marked libusb_set_debug deprecated it is replaced with libusb_set_option(libusb_context, LIBUSB_OPTION_LOG_LEVEL, libusb_log_level); details here: https://github.com/libusb/libusb/commit/539f22e2fd916558d11ab9a66f10f461c5593168 Warning here: CC hw/usb/host-libusb.o /builds/xen/src/qemu-xen/hw/usb/host-libusb.c: In function 'usb_host_init': /builds/xen/src/qemu-xen/hw/usb/host-libusb.c:250:5: error: 'libusb_set_debug' is deprecated: Use libusb_set_option instead [-Werror=deprecated-declarations] libusb_set_debug(ctx, loglevel); ^~~~~~~~~~~~~~~~ In file included from /builds/xen/src/qemu-xen/hw/usb/host-libusb.c:40:0: /usr/include/libusb-1.0/libusb.h:1300:18: note: declared here void LIBUSB_CALL libusb_set_debug(libusb_context *ctx, int level); ^~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make: *** [/builds/xen/src/qemu-xen/rules.mak:66: hw/usb/host-libusb.o] Error 1 make: Leaving directory '/builds/xen/src/xen/tools/qemu-xen-build' Signed-off-by: John Thomson <git@johnthomson.fastmail.com.au> Message-id: 20180405132046.4968-1-git@johnthomson.fastmail.com.au Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 9d8fa0df49af16a208fa961c2968fba4daffcc07) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:06 UTC
e55c6b6 arm_gicv3_kvm: increase clroffset accordingly It forgot to increase clroffset during the loop. So it only clear the first 4 bytes. Fixes: 367b9f527becdd20ddf116e17a3c0c2bbc486920 Cc: qemu-stable@nongnu.org Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-id: 1527047633-12368-1-git-send-email-zhaoshenglong@huawei.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 34ffacae085914fce54590ea84bae9c6ad95e2a4) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:06 UTC
8da7a17 intel-iommu: rework the page walk logic This patch fixes a potential small window that the DMA page table might be incomplete or invalid when the guest sends domain/context invalidations to a device. This can cause random DMA errors for assigned devices. This is a major change to the VT-d shadow page walking logic. It includes but is not limited to: - For each VTDAddressSpace, now we maintain what IOVA ranges we have mapped and what we have not. With that information, now we only send MAP or UNMAP when necessary. Say, we don't send MAP notifies if we know we have already mapped the range, meanwhile we don't send UNMAP notifies if we know we never mapped the range at all. - Introduce vtd_sync_shadow_page_table[_range] APIs so that we can call in any places to resync the shadow page table for a device. - When we receive domain/context invalidation, we should not really run the replay logic, instead we use the new sync shadow page table API to resync the whole shadow page table without unmapping the whole region. After this change, we'll only do the page walk once for each domain invalidations (before this, it can be multiple, depending on number of notifiers per address space). While at it, the page walking logic is also refactored to be simpler. CC: QEMU Stable <qemu-stable@nongnu.org> Reported-by: Jintack Lim <jintack@cs.columbia.edu> Tested-by: Jintack Lim <jintack@cs.columbia.edu> Signed-off-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 63b88968f139b6a77f2f81e6f1eedf70c0170a85) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:06 UTC
bdb6f9b util: implement simple iova tree Introduce a simplest iova tree implementation based on GTree. CC: QEMU Stable <qemu-stable@nongnu.org> Signed-off-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 eecf5eedbdc0fc04f39abcf3afeedfbf21b25ca4) Conflicts: util/Makefile.objs * drop context dep Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:05 UTC
e2c44fc intel-iommu: trace domain id during page walk This patch only modifies the trace points. Previously we were tracing page walk levels. They are redundant since we have page mask (size) already. Now we trace something much more useful which is the domain ID of the page walking. That can be very useful when we trace more than one devices on the same system, so that we can know which map is for which domain. CC: QEMU Stable <qemu-stable@nongnu.org> Signed-off-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 d118c06ebbee2d23ddf873cae4a809311aa61310) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:05 UTC
e8aa1dc intel-iommu: pass in address space when page walk We pass in the VTDAddressSpace too. It'll be used in the follow up patches. CC: QEMU Stable <qemu-stable@nongnu.org> Signed-off-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 2f764fa87d2a81812b313dd6d998e10126292653) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:05 UTC
04e0e11 intel-iommu: introduce vtd_page_walk_info During the recursive page walking of IOVA page tables, some stack variables are constant variables and never changed during the whole page walking procedure. Isolate them into a struct so that we don't need to pass those contants down the stack every time and multiple times. CC: QEMU Stable <qemu-stable@nongnu.org> Signed-off-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 fe215b0cbb8c1f4b4af0a64aa5c02042080dd537) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:05 UTC
21962e6 intel-iommu: only do page walk for MAP notifiers For UNMAP-only IOMMU notifiers, we don't need to walk the page tables. Fasten that procedure by skipping the page table walk. That should boost performance for UNMAP-only notifiers like vhost. CC: QEMU Stable <qemu-stable@nongnu.org> Signed-off-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 4f8a62a933a79094e44bc1b16b63bb23e62d67b4) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:05 UTC
3585497 intel-iommu: add iommu lock SECURITY IMPLICATION: this patch fixes a potential race when multiple threads access the IOMMU IOTLB cache. Add a per-iommu big lock to protect IOMMU status. Currently the only thing to be protected is the IOTLB/context cache, since that can be accessed even without BQL, e.g., in IO dataplane. Note that we don't need to protect device page tables since that's fully controlled by the guest kernel. However there is still possibility that malicious drivers will program the device to not obey the rule. In that case QEMU can't really do anything useful, instead the guest itself will be responsible for all uncertainties. CC: QEMU Stable <qemu-stable@nongnu.org> Reported-by: Fam Zheng <famz@redhat.com> Signed-off-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 1d9efa73e12ddf361ea997c2d532cc4afa6674d1) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:05 UTC
99fc962 intel-iommu: remove IntelIOMMUNotifierNode That is not really necessary. Removing that node struct and put the list entry directly into VTDAddressSpace. It simplfies the code a lot. Since at it, rename the old notifiers_list into vtd_as_with_notifiers. CC: QEMU Stable <qemu-stable@nongnu.org> Signed-off-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 b4a4ba0d68f50f218ee3957b6638dbee32a5eeef) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:05 UTC
6c403b7 intel-iommu: send PSI always even if across PDEs SECURITY IMPLICATION: without this patch, any guest with both assigned device and a vIOMMU might encounter stale IO page mappings even if guest has already unmapped the page, which may lead to guest memory corruption. The stale mappings will only be limited to the guest's own memory range, so it should not affect the host memory or other guests on the host. During IOVA page table walking, there is a special case when the PSI covers one whole PDE (Page Directory Entry, which contains 512 Page Table Entries) or more. In the past, we skip that entry and we don't notify the IOMMU notifiers. This is not correct. We should send UNMAP notification to registered UNMAP notifiers in this case. For UNMAP only notifiers, this might cause IOTLBs cached in the devices even if they were already invalid. For MAP/UNMAP notifiers like vfio-pci, this will cause stale page mappings. This special case doesn't trigger often, but it is very easy to be triggered by nested device assignments, since in that case we'll possibly map the whole L2 guest RAM region into the device's IOVA address space (several GBs at least), which is far bigger than normal kernel driver usages of the device (tens of MBs normally). Without this patch applied to L1 QEMU, nested device assignment to L2 guests will dump some errors like: qemu-system-x86_64: VFIO_MAP_DMA: -17 qemu-system-x86_64: vfio_dma_map(0x557305420c30, 0xad000, 0x1000, 0x7f89a920d000) = -17 (File exists) CC: QEMU Stable <qemu-stable@nongnu.org> Acked-by: Jason Wang <jasowang@redhat.com> [peterx: rewrite the commit message] Signed-off-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 36d2d52bdb45f5b753a61fdaf0fe7891f1f5b61d) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:05 UTC
0b25025 intel-iommu: Extend address width to 48 bits The current implementation of Intel IOMMU code only supports 39 bits iova address width. This patch provides a new parameter (x-aw-bits) for intel-iommu to extend its address width to 48 bits but keeping the default the same (39 bits). The reason for not changing the default is to avoid potential compatibility problems with live migration of intel-iommu enabled QEMU guest. The only valid values for 'x-aw-bits' parameter are 39 and 48. After enabling larger address width (48), we should be able to map larger iova addresses in the guest. For example, a QEMU guest that is configured with large memory ( >=1TB ). To check whether 48 bits aw is enabled, we can grep in the guest dmesg output with line: "DMAR: Host address width 48". Signed-off-by: Prasad Singamsetty <prasad.singamsety@oracle.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 37f51384ae05bd50f83308339dbffa3e78404874) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:05 UTC
d45364e intel-iommu: Redefine macros to enable supporting 48 bit address width The current implementation of Intel IOMMU code only supports 39 bits host/iova address width so number of macros use hard coded values based on that. This patch is to redefine them so they can be used with variable address widths. This patch doesn't add any new functionality but enables adding support for 48 bit address width. Signed-off-by: Prasad Singamsetty <prasad.singamsety@oracle.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 92e5d85e8345a22e87eda940ffe0f6422eb45360) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:05 UTC
7128bcb hw/intc/arm_gicv3: Fix APxR<n> register dispatching There was a nasty flip in identifying which register group an access is targeting. The issue caused spuriously raised priorities of the guest when handing CPUs over in the Jailhouse hypervisor. Cc: qemu-stable@nongnu.org Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Message-id: 28b927d3-da58-bce4-cc13-bfec7f9b1cb9@siemens.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 887aae10f6150dfdc71c45d7588e8efe6c144019) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:04 UTC
2e70085 console: Avoid segfault in screendump After f771c5440e04626f1 it is possible to select device and head which to take screendump from. And even though we check if provided head number falls within range, it may still happen that the console has no surface yet leading to SIGSEGV: qemu.git $ ./x86_64-softmmu/qemu-system-x86_64 \ -qmp stdio \ -device virtio-vga,id=video0,max_outputs=4 {"execute":"qmp_capabilities"} {"execute":"screendump", "arguments":{"filename":"/tmp/screen.ppm", "device":"video0", "head":1}} Segmentation fault #0 0x00005628249dda88 in ppm_save (filename=0x56282826cbc0 "/tmp/screen.ppm", ds=0x0, errp=0x7fff52a6fae0) at ui/console.c:304 #1 0x00005628249ddd9b in qmp_screendump (filename=0x56282826cbc0 "/tmp/screen.ppm", has_device=true, device=0x5628276902d0 "video0", has_head=true, head=1, errp=0x7fff52a6fae0) at ui/console.c:375 #2 0x00005628247740df in qmp_marshal_screendump (args=0x562828265e00, ret=0x7fff52a6fb68, errp=0x7fff52a6fb60) at qapi/qapi-commands-ui.c:110 Here, @ds from frame #0 (or @surface from frame #1) is dereferenced at the very beginning of ppm_save(). And because it's NULL crash happens. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-id: cb05bb1909daa6ba62145c0194aafa05a14ed3d1.1526569138.git.mprivozn@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 08d9864fa4e0c616e076ca8b225d39a7ecb189af) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:04 UTC
b68ef59 s390x/ccw: make sure all ccw devices are properly reset Thomas reported that the subchannel for a 3270 device that ended up in a broken state (status pending even though not enabled) did not get out of that state even after a reboot (which involves a subsytem reset). The reason for this is that the 3270 device did not define a reset handler. Let's fix this by introducing a base reset handler (set up for all ccw devices) that resets the subchannel and have virtio-ccw call its virtio-specific reset procedure in addition to that. CC: qemu-stable@nongnu.org Reported-by: Thomas Huth <thuth@redhat.com> Suggested-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Tested-by: Thomas Huth <thuth@redhat.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Halil Pasic <pasic@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com> (cherry picked from commit 838fb84f83c84f00d15b1bede5e080b495644458) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:04 UTC
b2ca602 virtio-ccw: common reset handler All the different virtio ccw devices use the same reset handler, so let's move setting it into the base virtio ccw device class. CC: qemu-stable@nongnu.org Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Halil Pasic <pasic@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com> (cherry picked from commit 0c53057adb04d254bc09511880670c92ab185fc6) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:04 UTC
f7f5398 s390x/virtio: Convert virtio-ccw from *_exit to *_unrealize Signed-off-by: Nia Alarie <nia.alarie@gmail.com> Message-Id: <20180307162958.11232-1-nia.alarie@gmail.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com> (cherry picked from commit 24118af846868bb22e573be206c63e684ba9846a) *prereq for 0c53057adb Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:04 UTC
18f59bb qdev: add helpers to be more explicit when using abstract QOM parent functions QOM API learning curve is quite hard, in particular when devices inherit from abstract parent. To be more explicit about when a device class change the parent hooks, add few helpers hoping a device class_init() will be easier to understand. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20180114020412.26160-3-f4bug@amsat.org> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 46795cf2e2f643ace9454822022ba8b1e9c0cf61) *prereq for 0c53057adb Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:04 UTC
0db8952 qdev: rename typedef qdev_resetfn() -> DeviceReset() following the DeviceRealize and DeviceUnrealize typedefs, this unify a bit the new QOM API. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20180114020412.26160-2-f4bug@amsat.org> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit b850f664a1dbbc1ea27bef12cd251ee5da0bfe05) *prereq for 0c53057adb Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:04 UTC
ce4e7b0 pc-bios/s390-ccw: struct tpi_info must be declared as aligned(4) I've run into a compilation error today with the current version of GCC 8: In file included from s390-ccw.h:49, from main.c:12: cio.h:128:1: error: alignment 1 of 'struct tpi_info' is less than 4 [-Werror=packed-not-aligned] } __attribute__ ((packed)); ^ cc1: all warnings being treated as errors Since the struct tpi_info contains an element ("struct subchannel_id schid") which is marked as aligned(4), we've got to mark the struct tpi_info as aligned(4), too. CC: qemu-stable@nongnu.org Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <1525774672-11913-1-git-send-email-thuth@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com> (cherry picked from commit a6e4385dea94850d7b06b0542e7960c1063fdabd) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:04 UTC
435a31f s390x/css: disabled subchannels cannot be status pending The 3270 code will try to post an attention interrupt when the 3270 emulator (e.g. x3270) attaches. If the guest has not yet enabled the subchannel for the 3270 device, we will present a spurious cc 1 (status pending) when it uses msch on it later on, e.g. when trying to enable the subchannel. To fix this, just don't do anything in css_conditional_io_interrupt() if the subchannel is not enabled. The 3270 code will work fine with that, and the other user of this function (virtio-ccw) never attempts to post an interrupt for a disabled device to begin with. CC: qemu-stable@nongnu.org Reported-by: Thomas Huth <thuth@redhat.com> Tested-by: Thomas Huth <thuth@redhat.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Acked-by: Halil Pasic <pasic@linux.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com> (cherry picked from commit 6e9c893ecd00afd5344c35d0d0ded50eaa0938f6) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:04 UTC
720db5d raw: Check byte range uniformly We don't verify the request range against s->size in the I/O callbacks except for raw_co_pwritev. This is inconsistent (especially for raw_co_pwrite_zeroes and raw_co_pdiscard), so fix them, in the meanwhile make the helper reusable by the coming new callbacks. Note that in most cases the block layer already verifies the request byte range against our reported image length, before invoking the driver callbacks. The exception is during image creating, after blk_set_allow_write_beyond_eof(blk, true) is called. But in that case, the requests are not directly from the user or guest. So there is no visible behavior change in adding the check code. The int64_t -> uint64_t inconsistency, as shown by the type casting, is pre-existing due to the interface. Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Fam Zheng <famz@redhat.com> Message-id: 20180601092648.24614-3-famz@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> (cherry picked from commit 384455385248762e74a080978f18f0c8f74757fe) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:04 UTC
979e7ea lm32: take BQL before writing IP/IM register Writing to these registers may raise an interrupt request. Actually, this prevents the milkymist board from starting. Cc: qemu-stable@nongnu.org Signed-off-by: Michael Walle <michael@walle.cc> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> (cherry picked from commit 81e9cbd0ca1131012b058df6804b1f626a6b730c) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:03 UTC
15fb5db iotests: Add test for -U/force-share conflicts Signed-off-by: Max Reitz <mreitz@redhat.com> Message-id: 20180502202051.15493-4-mreitz@redhat.com Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit 4e7d73c5fbd97e55ffe5af02f24d1f7dbe3bbf20) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:03 UTC
5704f53 qemu-img: Use only string options in img_open_opts img_open_opts() takes a QemuOpts and converts them to a QDict, so all values therein are strings. Then it may try to call qdict_get_bool(), however, which will fail with a segmentation fault every time: $ ./qemu-img info -U --image-opts \ driver=file,filename=/dev/null,force-share=off [1] 27869 segmentation fault (core dumped) ./qemu-img info -U --image-opts driver=file,filename=/dev/null,force-share=off Fix this by using qdict_get_str() and comparing the value as a string. Also, when adding a force-share value to the QDict, add it as a string so it fits the rest of the dict. Cc: qemu-stable@nongnu.org Signed-off-by: Max Reitz <mreitz@redhat.com> Message-id: 20180502202051.15493-3-mreitz@redhat.com Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit 4615f87832d2fcb7a544bedeece2741bf8c21f94) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:03 UTC
dbacc54 qemu-io: Use purely string blockdev options Currently, qemu-io only uses string-valued blockdev options (as all are converted directly from QemuOpts) -- with one exception: -U adds the force-share option as a boolean. This in itself is already a bit questionable, but a real issue is that it also assumes the value already existing in the options QDict would be a boolean, which is wrong. That has the following effect: $ ./qemu-io -r -U --image-opts \ driver=file,filename=/dev/null,force-share=off [1] 15200 segmentation fault (core dumped) ./qemu-io -r -U --image-opts driver=file,filename=/dev/null,force-share=off Since @opts is converted from QemuOpts, the value must be a string, and we have to compare it as such. Consequently, it makes sense to also set it as a string instead of a boolean. Cc: qemu-stable@nongnu.org Signed-off-by: Max Reitz <mreitz@redhat.com> Message-id: 20180502202051.15493-2-mreitz@redhat.com Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit 2a01c01f9ecb43af4c0a85fe6adc429ffc9c31b5) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:03 UTC
324bef4 iotests: Add test for rebasing with relative paths Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20180509182002.8044-3-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit 28036a7f7044fddb79819e3c8fcb4ae5605c60e0) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:03 UTC
1bec53c qemu-img: Resolve relative backing paths in rebase Currently, rebase interprets a relative path for the new backing image as follows: (1) Open the new backing image with the given relative path (thus relative to qemu-img's working directory). (2) Write it directly into the overlay's backing path field (thus relative to the overlay). If the overlay is not in qemu-img's working directory, both will be different interpretations, which may either lead to an error somewhere (either rebase fails because it cannot open the new backing image, or your overlay becomes unusable because its backing path does not point to a file), or, even worse, it may result in your rebase being performed for a different backing file than what your overlay will point to after the rebase. Fix this by interpreting the target backing path as relative to the overlay, like qemu-img does everywhere else. Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1569835 Cc: qemu-stable@nongnu.org Signed-off-by: Max Reitz <mreitz@redhat.com> Message-id: 20180509182002.8044-2-mreitz@redhat.com Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit d16699b64671466b42079c45b89127aeea1ca565) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:03 UTC
088a224 configure: recognize more rpmbuild macros Extend the list of recognized, but ignored options from rpms %configure macro. This fixes build on hosts running SUSE Linux. Cc: qemu-stable@nongnu.org Signed-off-by: Olaf Hering <olaf@aepfle.de> Message-Id: <20180418075045.27393-1-olaf@aepfle.de> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 181ce1d05c6d4f1c80f0e7ebb41e489c2b541edf) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:03 UTC
ecd54d6 qxl: fix local renderer crash Make sure we only ask the spice local renderer for display updates in case we have a valid primary surface. Without that spice is confused and throws errors in case a display update request (triggered by screendump for example) happens in parallel to a mode switch and hits the race window where the old primary surface is gone and the new isn't establisted yet. Cc: qemu-stable@nongnu.org Fixes: https://bugzilla.redhat.com//show_bug.cgi?id=1567733 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20180427115528.345-1-kraxel@redhat.com (cherry picked from commit 5bd5c27c7d284d01477c5cc022ce22438c46bf9f) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:03 UTC
1378cb9 spapr: don't advertise radix GTSE if max-compat-cpu < power9 On a POWER9 host, if a guest runs in pre POWER9 compat mode, it necessarily uses the hash MMU mode. In this case, we shouldn't advertise radix GTSE in the ibm,arch-vec-5-platform-support DT property as the current code does. The first reason is that it doesn't make sense, and the second one is that causes the CAS-negotiated options subsection to be migrated. This breaks backward migration to QEMU 2.7 and older versions on POWER8 hosts: qemu-system-ppc64: error while loading state for instance 0x0 of device 'spapr' qemu-system-ppc64: load of migration failed: No such file or directory This patch hence initialize CPUs a bit earlier so that we can check the requested compat mode, and don't set OV5_MMU_RADIX_GTSE for power8 and older. Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit 0550b1206a91d66051a21441a02c4ff126b531fe) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:03 UTC
0ab2f8e target/ppc: always set PPC_MEM_TLBIE in pre 2.8 migration hack The pseries-2.7 and older machine types require CPUPPCState::insns_flags to be strictly equal between source and destination. This checking is abusive and breaks migration of KVM guests when the host CPU models are different, even if they are compatible enough to allow the guest to run transparently. This buggy behaviour was fixed for pseries-2.8 and we added some hacks to allow backward migration of older machine types. These hacks assume that the CPU belongs to the POWER8 family, which was true for most KVM based setup we cared about at the time. But now POWER9 systems are coming, and backward migration of pre 2.8 guests running in POWER8 architected mode from a POWER9 host to a POWER8 host is broken: qemu-system-ppc64: error while loading state for instance 0x0 of device 'cpu' qemu-system-ppc64: load of migration failed: Invalid argument This happens because POWER9 doesn't set PPC_MEM_TLBIE in insns_flags, while POWER8 does. Let's force PPC_MEM_TLBIE in the migration hack to fix the issue. This is an acceptable hack because these old machine types only support CPU models that do set PPC_MEM_TLBIE. Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit bce009645b9f1d59195518e35747c8ea30f985f7) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:03 UTC
67bacd5 target/arm: Implement v8M VLLDM and VLSTM For v8M the instructions VLLDM and VLSTM support lazy saving and restoring of the secure floating-point registers. Even if the floating point extension is not implemented, these instructions must act as NOPs in Secure state, so they can be used as part of the secure-to-nonsecure call sequence. Fixes: https://bugs.launchpad.net/qemu/+bug/1768295 Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20180503105730.5958-1-peter.maydell@linaro.org (cherry picked from commit b1e5336a9899016c53d59eba53ebf6abcc21995c) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:02 UTC
a27d261 tcg/arm: Fix memory barrier encoding I found with qemu 2.11.x or newer that I would get an illegal instruction error running some Intel binaries on my ARM chromebook. On investigation, I found it was quitting on memory barriers. qemu instruction: mb $0x31 was translating as: 0x604050cc: 5bf07ff5 blpl #0x600250a8 After patch it gives: 0x604050cc: f57ff05b dmb ish In short, I found INSN_DMB_ISH (memory barrier for ARMv7) appeared to be correct based on online docs, but due to some endian-related shenanigans it had to be byte-swapped to suit qemu; it appears INSN_DMB_MCR (memory barrier for ARMv6) also should be byte swapped (and this patch does so). I have not checked for correctness of aarch64's barrier instruction. Cc: qemu-stable@nongnu.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Henry Wertz <hwertz10@gmail.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit 3f814b803797c007abfe5c4041de754e01723031) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:02 UTC
834a846 s390-ccw: force diag 308 subcode to unsigned long We currently pass an integer as the subcode parameter. However, the upper bits of the register containing the subcode need to be 0, which is not guaranteed unless we explicitly specify the subcode to be an unsigned long value. Fixes: d046c51dad3 ("pc-bios/s390-ccw: Get device address via diag 308/6") Cc: qemu-stable@nongnu.org Signed-off-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Tested-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 63d8b5ace31c1e1f3996fe4cd551d6d377594d5a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:02 UTC
0304f75 s390: Do not pass inofficial IPL type to the guest IPL over a virtio-scsi device requires special handling not available in the real architecture. For this purpose the IPL type 0xFF has been chosen as means of communication between QEMU and the pc-bios. However, a guest OS could be confused by seeing an unknown IPL type. This change sets the IPL parameter type to 0x02 (CCW) to prevent this. Pre-existing Linux has looked up the IPL parameters only in the case of FCP IPL. This means that the behavior should stay the same even if Linux checks for the IPL type unconditionally. Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com> Message-Id: <1522940844-12336-4-git-send-email-mihajlov@linux.vnet.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com> (cherry picked from commit e8c7ef288abb05b741a95418ee2de85c1071e0db) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:02 UTC
955b77f nbd/client: Fix error messages during NBD_INFO_BLOCK_SIZE A missing space makes for poor error messages, and sizes can't go negative. Also, we missed diagnosing a server that sends a maximum block size less than the minimum. Fixes: 081dd1fe CC: qemu-stable@nongnu.org Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20180501154654.943782-1-eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> (cherry picked from commit e475d108f1b3d3163f0affea67cdedbe5fc9752b) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:02 UTC
f3f01ba ccid: Fix dwProtocols advertisement of T=0 Commit d7d218ef02d87c637d20d64da8f575d434ff6f78 attempted to change dwProtocols to only advertise support for T=0 and not T=1. The change was incorrect as it changed 0x00000003 to 0x00010000. lsusb -v in a linux guest shows: "dwProtocols 65536 (Invalid values detected)", though the smart card could still be accessed. Windows 7 does not detect inserted smart cards and logs the the following Error in the Event Logs: Source: Smart Card Service Event ID: 610 Smart Card Reader 'QEMU QEMU USB CCID 0' rejected IOCTL SET_PROTOCOL: Incorrect function. If this error persists, your smart card or reader may not be functioning correctly Command Header: 03 00 00 00 Setting to 0x00000001 fixes the Windows issue. Signed-off-by: Jason Andryuk <jandryuk@gmail.com> Message-id: 20180420183219.20722-1-jandryuk@gmail.com Cc: qemu-stable@nongnu.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 0ee86bb6c5beb6498488850104f7557c376d0bef) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:02 UTC
5648a81 device_tree: Increase FDT_MAX_SIZE to 1 MiB It is not uncommon for a contemporary FDT to be larger than 64 KiB, leading to failures loading the device tree from sysfs: qemu-system-aarch64: qemu_fdt_setprop: Couldn't set ...: FDT_ERR_NOSPACE Hence increase the limit to 1 MiB, like on PPC. For reference, the largest arm64 DTB created from the Linux sources is ca. 75 KiB large (100 KiB when built with symbols/fixup support). Cc: qemu-stable@nongnu.org Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Message-id: 1523541337-23919-1-git-send-email-geert+renesas@glider.be Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 14ec3cbd7c1e31dca4d23f028100c8f43e156573) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:02 UTC
0580c63 hw/char/cmsdk-apb-uart.c: Correctly clear INTSTATUS bits on writes The CMSDK APB UART INTSTATUS register bits are all write-one-to-clear. We were getting this correct for the TXO and RXO bits (which need special casing because their state lives in the STATE register), but had forgotten to handle the normal bits for RX and TX which we do store in our s->intstatus field. Perform the W1C operation on the bits in s->intstatus too. Fixes: https://bugs.launchpad.net/qemu/+bug/1760262 Cc: qemu-stable@nongnu.org Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20180410134203.17552-1-peter.maydell@linaro.org (cherry picked from commit 6670b494fdb23f74ecd9be3d952c007f64e268f1) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:02 UTC
b17ed3e tcg: Introduce tcg_set_insn_start_param The parameters for tcg_gen_insn_start are target_ulong, which may be split into two TCGArg parameters for storage in the opcode on 32-bit hosts. Fixes the ARM target and its direct use of tcg_set_insn_param, which would set the wrong argument in the 64-on-32 case. Cc: qemu-stable@nongnu.org Reported-by: alarson@ddci.com Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20180410003558.2470-1-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 9743cd5736263e90d312b2c33bd739ffe1eae70d) Conflicts: target/arm/translate.h tcg/tcg.h * rework to avoid functional dependency on 15fa08f Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:02 UTC
44633a2 hw/block/pflash_cfi: fix off-by-one error ASAN reported: hw/block/pflash_cfi02.c:245:33: runtime error: index 82 out of bounds for type 'uint8_t [82]' Since the 'cfi_len' member is not used, remove it to keep the code safer. Cc: qemu-stable@nongnu.org Reported-by: AddressSanitizer Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 07c13a71721d9f8c690b66752964e254af247475) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:01 UTC
8999a59 vfio-ccw: fix memory leaks in vfio_ccw_realize() If the subchannel is already attached or if vfio_get_device() fails, the code jumps to the 'out_device_err' label and doesn't free the string it has just allocated. The code should be reworked so that vcdev->vdev.name only gets set when the device has been attached, and freed when it is about to be detached. This could be achieved with the addition of a vfio_ccw_get_device() function that would be the counterpart of vfio_put_device(). But this is a more elaborate cleanup that should be done in a follow-up. For now, let's just add calls to g_free() on the buggy error paths. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <152311222681.203086.8874800175539040298.stgit@bahia> Signed-off-by: Cornelia Huck <cohuck@redhat.com> (cherry picked from commit be4d026f645eb31078e08d431c93a898b895024e) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:01 UTC
28895d0 cpus.c: ensure running CPU recalculates icount deadlines on timer expiry When we run in TCG icount mode, we calculate the number of instructions to execute using tcg_get_icount_limit(), which ensures that we stop execution at the next timer deadline. However there is a bug where currently we do not recalculate that limit if the guest reprograms a timer so that the next deadline moves closer, and so we will continue execution until the original limit and fire the timer later than we should. Fix this bug in qemu_timer_notify_cb(): if we are currently running a VCPU in icount mode, we simply need to kick it out of the main loop and back to tcg_cpu_exec(), where it will recalculate the icount limit. If we are not currently running a VCPU, then we retain the existing logic for waking up a halted CPU. Cc: qemu-stable@nongnu.org Fixes: https://bugs.launchpad.net/qemu/+bug/1754038 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20180406123838.21249-1-peter.maydell@linaro.org (cherry picked from commit c52e7132d7c885841500f5277f7305f62767fe1d) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:01 UTC
12fc0de gluster: Fix blockdev-add with server.N.type=unix The legacy command line interface gets the socket path from an option called 'socket'. QAPI in contract uses SocketAddress, where the corresponding option is called 'path'. Fix the gluster block driver to accept both 'socket' and 'path', with 'path' being the preferred syntax. https://bugzilla.redhat.com/show_bug.cgi?id=1545155 Cc: qemu-stable@nongnu.org Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-id: 20180403110810.25624-1-kwolf@redhat.com Signed-off-by: Jeff Cody <jcody@redhat.com> (cherry picked from commit 9dae635afa98f83688806861cefe77ff1b4d76a8) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:01 UTC
bb8d4bb exec: fix memory leak in find_max_supported_pagesize() The string returned by object_property_get_str() is dynamically allocated. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <152231458624.69730.1752893648612848392.stgit@bahia.lan> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> (cherry picked from commit 72a841d2a403b56ff894fa007b172dc9bcb3dae8) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:01 UTC
2b73d5d target/i386: Fix andn instruction In commit 7073fbada733c8d10992f00772c9b9299d740e9b, the `andn` instruction was implemented via `tcg_gen_andc` but passes the operands in the wrong order: - X86 defines `andn dest,src1,src2` as: dest = ~src1 & src2 - TCG defines `andc dest,src1,src2` as: dest = src1 & ~src2 The following simple test shows the issue: #include <stdio.h> #include <stdint.h> int main(void) { uint32_t ret = 0; __asm ( "mov $0xFF00, %%ecx\n" "mov $0x0F0F, %%eax\n" "andn %%ecx, %%eax, %%ecx\n" "mov %%ecx, %0\n" : "=r" (ret)); printf("%08X\n", ret); return 0; } This patch fixes the problem by simply swapping the order of the two last arguments in `tcg_gen_andc_tl`. Reported-by: Alexandro Sanchez Bach <alexandro@phi.nz> Signed-off-by: Alexandro Sanchez Bach <alexandro@phi.nz> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 5cd10051c2e02b7a86eae49919d6c65a87dbea46) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:01 UTC
5aac5f6 tcg: Mark muluh_i64 and mulsh_i64 as 64-bit ops Failure to do so results in the tcg optimizer sign-extending any constant fold from 32-bits. This turns out to be visible in the RISC-V testsuite using a host that emits these opcodes (e.g. any non-x86_64). Reported-by: Michael Clark <mjc@sifive.com> Reviewed-by: Emilio G. Cota <cota@braap.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit f2f1dde75160cac6ede330f3db50dc817d01a2d6) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:01 UTC
c793a0d iotests: Test preallocated truncate of 2G image Signed-off-by: Max Reitz <mreitz@redhat.com> Message-id: 20180228131315.30194-3-mreitz@redhat.com Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit 733d1dce0f3c8ab7b79a173f6482781d3718f844) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:01 UTC
d315353 block/file-posix: Fix fully preallocated truncate Storing the lseek() result in an int results in it overflowing when the file is at least 2 GB big. Then, we have a 50 % chance of the result being "negative" and thus thinking an error occurred when actually everything went just fine. So we should use the correct type for storing the result: off_t. Reported-by: Daniel P. Berrange <berrange@redhat.com> Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1549231 Cc: qemu-stable@nongnu.org Signed-off-by: Max Reitz <mreitz@redhat.com> Message-id: 20180228131315.30194-2-mreitz@redhat.com Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit 82b45e0a0b824787bd79ce3f6453eaa2afddd138) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:01 UTC
332969a qemu-pr-helper: Actually allow users to specify pidfile Due to wrong specification of arguments to getopt_long() any attempt to set pidfile resulted in: 1) the default to be leaked 2) the @pidfile variable to be set to NULL (because optarg is NULL without this patch). Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Message-Id: <6f10cd53d361a395aa0e85a9311ec4e9a8fc11e5.1521868451.git.mprivozn@redhat.com> Cc: qemu-stable@nongnu.org Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit f8e1a989644f22ba2f7afb0e13b6ce2309ea9503) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:01 UTC
db9c0d9 virtio_net: flush uncompleted TX on reset If the backend could not transmit a packet right away for some reason, the packet is queued for asynchronous sending. The corresponding vq element is tracked in the async_tx.elem field of the VirtIONetQueue, for later freeing when the transmission is complete. If a reset happens before completion, virtio_net_tx_complete() will push async_tx.elem back to the guest anyway, and we end up with the inuse flag of the vq being equal to -1. The next call to virtqueue_pop() is then likely to fail with "Virtqueue size exceeded". This can be reproduced easily by starting a guest with an hubport backend that is not connected to a functional network, eg, -device virtio-net-pci,netdev=hub0 -netdev hubport,id=hub0,hubid=0 and no other -netdev hubport,hubid=0 on the command line. The appropriate fix is to ensure that such an asynchronous transmission cannot survive a device reset. So for all queues, we first try to send the packet again, and eventually we purge it if the backend still could not deliver it. CC: qemu-stable@nongnu.org Reported-by: R. Nageswara Sastry <nasastry@in.ibm.com> Buglink: https://github.com/open-power-host-os/qemu/issues/37 Signed-off-by: Greg Kurz <groug@kaod.org> Tested-by: R. Nageswara Sastry <nasastry@in.ibm.com> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit 94b52958b77a2a040564cf7ed716d3a9545d94e5) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:00 UTC
a053477 arm/translate-a64: treat DISAS_UPDATE as variant of DISAS_EXIT In OE project 4.15 linux kernel boot hang was observed under single cpu aarch64 qemu. Kernel code was in a loop waiting for vtimer arrival, spinning in TC generated blocks, while interrupt was pending unprocessed. This happened because when qemu tried to handle vtimer interrupt target had interrupts disabled, as result flag indicating TCG exit, cpu->icount_decr.u16.high, was cleared but arm_cpu_exec_interrupt function did not call arm_cpu_do_interrupt to process interrupt. Later when target reenabled interrupts, it happened without exit into main loop, so following code that waited for result of interrupt execution run in infinite loop. To solve the problem instructions that operate on CPU sys state (i.e enable/disable interrupt), and marked as DISAS_UPDATE, should be considered as DISAS_EXIT variant, and should be forced to exit back to main loop so qemu will have a chance processing pending CPU state updates, including pending interrupts. This change brings consistency with how DISAS_UPDATE is treated in aarch32 case. CC: Peter Maydell <peter.maydell@linaro.org> CC: Alex Bennée <alex.bennee@linaro.org> CC: qemu-stable@nongnu.org Suggested-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Victor Kamensky <kamensky@cisco.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 1521526368-1996-1-git-send-email-kamensky@cisco.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit a75a52d62418dafe462be4fe30485501d1010bb9) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:00 UTC
7c22c5a tests/multiboot: Add .gitignore Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jack Schwartz <jack.schwartz@oracle.com> Reviewed-by: Eric Blake <eblake@redhat.com> (cherry picked from commit e2679395d598bd40770c22a793c0152576ac211f) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:00 UTC
678a75b tests/multiboot: Add tests for the a.out kludge Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jack Schwartz <jack.schwartz@oracle.com> (cherry picked from commit 1c8c426fb44bf5b3ffbcad1b00c7def4b89b03ec) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:00 UTC
2392a86 tests/multiboot: Test exit code for every qemu run Testing the exit code only once after a whole group of tests has completed is not enough, it catches errors only in the very last qemu invocation. We need to have the check after each qemu run. The logging and diff with the reference output is still done once per group to keep things more managable. This is not a problem because the log file accumulates the output of all runs. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jack Schwartz <jack.schwartz@oracle.com> (cherry picked from commit 49713c413a65ab4b02124aabe83f8539cc6ece5e) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:00 UTC
32ccaed multiboot: Check validity of mh_header_addr I couldn't find a case where this prevents something bad from happening that isn't already caught by other checks, but let's err on the safe side and check that mh_header_addr is as expected. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jack Schwartz <jack.schwartz@oracle.com> (cherry picked from commit dbf2dce7aabb7723542bd182175904846d70b0f9) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:00 UTC
31b0eb0 multiboot: Reject kernels exceeding the address space The code path where mh_load_end_addr is non-zero in the Multiboot header checks that mh_load_end_addr >= mh_load_addr and so mb_load_size is checked. However, mb_load_size is not checked when calculated from the file size, when mh_load_end_addr is 0. If the kernel binary size is larger than can fit in the address space after load_addr, we ended up with a kernel_size that is smaller than load_size, which means that we read the file into a too small buffer. Add a check to reject kernel files with such Multiboot headers. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jack Schwartz <jack.schwartz@oracle.com> (cherry picked from commit b17a9054a0652a1481be48a6729e972abf02412f) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:00 UTC
bbdcfd2 multiboot: fprintf(stderr...) -> error_report() Change all fprintf(stderr...) calls in hw/i386/multiboot.c to call error_report() instead, including the mb_debug macro. Remove the "\n" from strings passed to all modified calls, since error_report() appends one. Signed-off-by: Jack Schwartz <jack.schwartz@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 4b9006a41ea8818f2385ae5228e07f211bb4a33d) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:00 UTC
ddf965e multiboot: Use header names when displaying fields Refer to field names when displaying fields in printf and debug statements. Signed-off-by: Jack Schwartz <jack.schwartz@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit ce5eb6dc4dc5652f7e360a1db817f1d5dafab90f) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:00 UTC
a030730 multiboot: Remove unused variables from multiboot.c Remove unused variables: mh_mode_type, mh_width, mh_height, mh_depth Signed-off-by: Jack Schwartz <jack.schwartz@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> Reviewed-by: Prasad J Pandit <pjp@fedoraproject.org> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 7a2e43cc96fd017883973caf9ee076ae23a3bebd) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:00 UTC
059a696 multiboot: bss_end_addr can be zero The multiboot spec (https://www.gnu.org/software/grub/manual/multiboot/), section 3.1.3, allows for bss_end_addr to be zero. A zero bss_end_addr signifies there is no .bss section. Suggested-by: Daniel Kiper <daniel.kiper@oracle.com> Signed-off-by: Jack Schwartz <jack.schwartz@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> Reviewed-by: Prasad J Pandit <pjp@fedoraproject.org> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 2a8fcd119eb7c6bb3837fc3669eb1b2dfb31daf8) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:45:00 UTC
ab2dfe8 migration/block: reset dirty bitmap before read in bulk phase Reset the dirty bitmap before reading to make sure we don't miss any new data. Cc: qemu-stable@nongnu.org Signed-off-by: Peter Lieven <pl@kamp.de> Message-Id: <1520507908-16743-3-git-send-email-pl@kamp.de> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> (cherry picked from commit 86b124bc76bd7137d0fb20696c4e349571b8533d) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:44:59 UTC
cebb7fe memory: fix flatview_access_valid RCU read lock/unlock imbalance Fixes: 11e732a5ed46903f997985bed4c3767ca28a7eb6 Reported-by: Cornelia Huck <cohuck@redhat.com> Reported-by: luigi burdo <intermediadc@hotmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Tested-by: Cornelia Huck <cohuck@redhat.com> Tested-by: Thomas Huth <thuth@redhat.com> Message-id: 20180307130238.19358-1-pbonzini@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit b39b61e410022f96ceb53d4381d25cba5126ac44) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:44:59 UTC
aedaf01 address_space_rw: address_space_to_flatview needs RCU lock address_space_rw is calling address_space_to_flatview but it can be called outside the RCU lock. To fix it, transform flatview_rw into address_space_rw, since flatview_rw is otherwise unused. Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit db84fd973eba3f1e121416dcab73a4e8a60f2526) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:44:59 UTC
a7f4d8a address_space_map: address_space_to_flatview needs RCU lock address_space_map is calling address_space_to_flatview but it can be called outside the RCU lock. The function itself is calling rcu_read_lock/rcu_read_unlock, just in the wrong place, so the fix is easy. Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit ad0c60fa572d4050255b698ecdb67294dd4c0125) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:44:59 UTC
fa876bc address_space_access_valid: address_space_to_flatview needs RCU lock address_space_access_valid is calling address_space_to_flatview but it can be called outside the RCU lock. To fix it, push the rcu_read_lock/unlock pair up from flatview_access_valid to address_space_access_valid. Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 11e732a5ed46903f997985bed4c3767ca28a7eb6) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:44:59 UTC
f77c231 address_space_read: address_space_to_flatview needs RCU lock address_space_read is calling address_space_to_flatview but it can be called outside the RCU lock. To fix it, push the rcu_read_lock/unlock pair up from flatview_read_full to address_space_read's constant size fast path and address_space_read_full. Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit b2a44fcad74f1cc7a6786d38eba7db12ab2352ba) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:44:59 UTC
df04d1f address_space_write: address_space_to_flatview needs RCU lock address_space_write is calling address_space_to_flatview but it can be called outside the RCU lock. To fix it, push the rcu_read_lock/unlock pair up from flatview_write to address_space_write. Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 4c6ebbb364aa6f42c5d8e83e932e967eb83f0e44) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:44:59 UTC
ac25a32 memory: inline some performance-sensitive accessors These accessors are called from inlined functions, and the call sequence is much more expensive than just inlining the access. Move the struct declaration to memory-internal.h so that exec.c and memory.c can both use an inline function. Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 785a507ec78bbda1c346f3d3593e5a58b62e73ef) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:44:59 UTC
8e8b739 openpic_kvm: drop address_space_to_flatview call The MemoryListener is registered on address_space_memory, there is not much to assert. This currently works because the callback is invoked only once when the listener is registered, but section->fv is the _new_ FlatView, not the old one on later calls and that would break. This confines address_space_to_flatview to exec.c and memory.c. Acked-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 80d2b933f9fe3e53d4f76a45a1bc1a0175669468) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:44:59 UTC
4992118 sparc: fix leon3 casa instruction when MMU is disabled Since the commit af7a06bac7d3abb2da48ef3277d2a415772d2ae8: `casa [..](10), .., ..` (and probably others alternate space instructions) triggers a data access exception when the MMU is disabled. When we enter get_asi(...) dc->mem_idx is set to MMU_PHYS_IDX when the MMU is disabled. Just keep mem_idx unchanged in this case so we passthrough the MMU when it is disabled. Signed-off-by: KONRAD Frederic <frederic.konrad@adacore.com> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> (cherry picked from commit 6e10f37c86068e35151f982c976a85f1bec07ef2) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:44:58 UTC
e1f5a04 linux-user: fix target_mprotect/target_munmap error return values target_mprotect/target_munmap return value goes through get_errno at the call site, thus the functions must either set errno to host error code and return -1 or return negative guest error code. Do the latter. Cc: qemu-stable@nongnu.org Cc: Riku Voipio <riku.voipio@iki.fi> Cc: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20180228221609.11265-8-jcmvbkbc@gmail.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu> (cherry picked from commit 78cf339039c325b336442f1d7f3ccc531b22c4a0) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:44:58 UTC
8fc971e linux-user: fix assertion in shmdt shmdt fails to call mmap_lock/mmap_unlock around page_set_flags, resulting in the following assertion: page_set_flags: Assertion `have_mmap_lock()' failed. Wrap shmdt internals into mmap_lock/mmap_unlock. Cc: qemu-stable@nongnu.org Cc: Riku Voipio <riku.voipio@iki.fi> Cc: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20180228221609.11265-7-jcmvbkbc@gmail.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu> (cherry picked from commit 3c5f6a5f888729f9fbc64211298f7c3e2fb42b64) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 21 June 2018, 01:44:58 UTC
back to top