aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-06-22hw/arm/smmuv3: Apply address mask to linear strtab base addressSimon Veith1-1/+1
In the SMMU_STRTAB_BASE register, the stream table base address only occupies bits [51:6]. Other bits, such as RA (bit [62]), must be masked out to obtain the base address. The branch for 2-level stream tables correctly applies this mask by way of SMMU_BASE_ADDR_MASK, but the one for linear stream tables does not. Apply the missing mask in that case as well so that the correct stream base address is used by guests which configure a linear stream table. Linux guests are unaffected by this change because they choose a 2-level stream table layout for the QEMU SMMUv3, based on the size of its stream ID space. 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-2-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 3d44c60500785f18bb469c9de0aeba7415c0f28f) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22display/bochs-display: fix memory leakCameron Esfahani1-0/+2
Fix memory leak in bochs_display_update(). Leaks 304 bytes per frame. Fixes: 33ebad54056 Signed-off-by: Cameron Esfahani <dirty@apple.com> Message-Id: <d6c26e68db134c7b0c7ce8b61596ca2e65e01e12.1576013209.git.dirty@apple.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 0d82411d0e38a0de7829f97d04406765c8d2210d) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22vhost-user-gpu: Drop trailing json commaCole Robinson1-1/+1
Trailing comma is not valid json: $ cat contrib/vhost-user-gpu/50-qemu-gpu.json.in | jq parse error: Expected another key-value pair at line 5, column 1 Signed-off-by: Cole Robinson <crobinso@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Li Qiang <liq3ea@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 7f5dd2ac9f3504e2699f23e69bc3d8051b729832.1568925097.git.crobinso@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit ca26b032e5a0e8a190c763ce828a8740d24b9b65) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22iotests: Fix IMGOPTSSYNTAX for nbdMax Reitz1-1/+2
There is no $SOCKDIR, only $SOCK_DIR. Fixes: f3923a72f199b2c63747a7032db74730546f55c6 Signed-off-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 eb4ea9aaa0051054b3c148ad8631be7510851681) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22Fix double free issue in qemu_set_log_filename().Robert Foley1-0/+1
After freeing the logfilename, we set logfilename to NULL, in case of an error which returns without setting logfilename. Signed-off-by: Robert Foley <robert.foley@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20191118211528.3221-2-robert.foley@linaro.org> (cherry picked from commit 0f516ca4767042aec8716369d6d62436fa10593a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22Revert "qemu-options.hx: Update for reboot-timeout parameter"Han Han1-2/+2
This reverts commit bbd9e6985ff342cbe15b9cb7eb30e842796fbbe8. In 20a1922032 we allowed reboot-timeout=-1 again, so update the doc accordingly. Signed-off-by: Han Han <hhan@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20191205024821.245435-1-hhan@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu> (cherry picked from commit 8937a39da22e5d5689c516a2d4ce4f2bb6a378fc) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22iotests/026: Move v3-exclusive test to new fileMax Reitz6-43/+98
data_file does not work with v2, and we probably want 026 to keep working for v2 images. Thus, open a new file for v3-exclusive error path test cases. Fixes: 81311255f217859413c94f2cd9cebf2684bbda94 (“iotests/026: Test EIO on allocation in a data-file”) Signed-off-by: Max Reitz <mreitz@redhat.com> Message-Id: <20200311140707.1243218-1-mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Tested-by: John Snow <jsnow@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit c264e5d2f9f5d73977eac8e5d084f727b3d07ea9) Conflicts: tests/qemu-iotests/group Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22dp8393x: Mask EOL bit from descriptor addresses, take 2Finn Thain1-2/+2
A portion of a recent patch got lost due to a merge snafu. That patch is now commit 88f632fbb1 ("dp8393x: Mask EOL bit from descriptor addresses"). This patch restores the portion that got lost. Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <alpine.LNX.2.22.394.2003041421280.12@nippy.intranet> Signed-off-by: Laurent Vivier <laurent@vivier.eu> (cherry picked from commit a0cf4297d6b8d88047ab00c467f14aecf9c2a8eb) Conflicts: hw/net/dp8393x.c *drop context dep. on 19f70347 Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22slirp: update to fix CVE-2020-1983Marc-André Lureau1-0/+0
This is an update on the stable-4.2 branch of libslirp.git: git shortlog 55ab21c9a3..2faae0f778f81 Marc-André Lureau (1): Fix use-afte-free in ip_reass() (CVE-2020-1983) CVE-2020-1983 is actually a follow up fix for commit 126c04acbabd7ad32c2b018fe10dfac2a3bc1210 ("Fix heap overflow in ip_reass on big packet input") which was was included in qemu v4.1 (commit e1a4a24d262ba5ac74ea1795adb3ab1cd574c7fb "slirp: update with CVE-2019-14378 fix"). Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20200421170227.843555-1-marcandre.lureau@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 7769c23774d1278f60b9e40d2c0b98784de6425f) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22kvm: Reallocate dirty_bmap when we change a slotDr. David Alan Gilbert1-15/+29
kvm_set_phys_mem can be called to reallocate a slot by something the guest does (e.g. writing to PAM and other chipset registers). This can happen in the middle of a migration, and if we're unlucky it can now happen between the split 'sync' and 'clear'; the clear asserts if there's no bmap to clear. Recreate the bmap whenever we change the slot, keeping the clear path happy. Typically this is triggered by the guest rebooting during a migrate. Corresponds to: https://bugzilla.redhat.com/show_bug.cgi?id=1772774 https://bugzilla.redhat.com/show_bug.cgi?id=1771032 Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> (cherry picked from commit 9b3a31c745b61758aaa5466a3a9fc0526d409188) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22es1370: check total frame count against current framePrasad J Pandit1-2/+5
A guest user may set channel frame count via es1370_write() such that, in es1370_transfer_audio(), total frame count 'size' is lesser than the number of frames that are processed 'cnt'. int cnt = d->frame_cnt >> 16; int size = d->frame_cnt & 0xffff; if (size < cnt), it results in incorrect calculations leading to OOB access issue(s). Add check to avoid it. Reported-by: Ren Ding <rding@gatech.edu> Reported-by: Hanqing Zhao <hanqing@gatech.edu> Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org> Message-id: 20200514200608.1744203-1-ppandit@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 369ff955a8497988d079c4e3fa1e93c2570c1c69) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22ati-vga: check mm_index before recursive call (CVE-2020-13800)Prasad J Pandit1-2/+8
While accessing VGA registers via ati_mm_read/write routines, a guest may set 's->regs.mm_index' such that it leads to infinite recursion. Check mm_index value to avoid such recursion. Log an error message for wrong values. Reported-by: Ren Ding <rding@gatech.edu> Reported-by: Hanqing Zhao <hanqing@gatech.edu> Reported-by: Yi Ren <c4tren@gmail.com> Message-id: 20200604090830.33885-1-ppandit@redhat.com Suggested-by: BALATON Zoltan <balaton@eik.bme.hu> Suggested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit a98610c429d52db0937c1e48659428929835c455) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22ati-vga: Fix checks in ati_2d_blt() to avoid crashBALATON Zoltan1-11/+26
In some corner cases (that never happen during normal operation but a malicious guest could program wrong values) pixman functions were called with parameters that result in a crash. Fix this and add more checks to disallow such cases. Reported-by: Ziming Zhang <ezrakiez@gmail.com> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-id: 20200406204029.19559747D5D@zero.eik.bme.hu Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit ac2071c3791b67fc7af78b8ceb320c01ca1b5df7) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22iscsi: Cap block count from GET LBA STATUS (CVE-2020-1711)Felipe Franciosi1-2/+3
When querying an iSCSI server for the provisioning status of blocks (via GET LBA STATUS), Qemu only validates that the response descriptor zero's LBA matches the one requested. Given the SCSI spec allows servers to respond with the status of blocks beyond the end of the LUN, Qemu may have its heap corrupted by clearing/setting too many bits at the end of its allocmap for the LUN. A malicious guest in control of the iSCSI server could carefully program Qemu's heap (by selectively setting the bitmap) and then smash it. This limits the number of bits that iscsi_co_block_status() will try to update in the allocmap so it can't overflow the bitmap. Fixes: CVE-2020-1711 Cc: qemu-stable@nongnu.org Signed-off-by: Felipe Franciosi <felipe@nutanix.com> Signed-off-by: Peter Turschmid <peter.turschm@nutanix.com> Signed-off-by: Raphael Norwitz <raphael.norwitz@nutanix.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 693fd2acdf14dd86c0bf852610f1c2cca80a74dc) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22target/i386: do not set unsupported VMX secondary execution controlsVitaly Kuznetsov1-15/+26
Commit 048c95163b4 ("target/i386: work around KVM_GET_MSRS bug for secondary execution controls") added a workaround for KVM pre-dating commit 6defc591846d ("KVM: nVMX: include conditional controls in /dev/kvm KVM_GET_MSRS") which wasn't setting certain available controls. The workaround uses generic CPUID feature bits to set missing VMX controls. It was found that in some cases it is possible to observe hosts which have certain CPUID features but lack the corresponding VMX control. In particular, it was reported that Azure VMs have RDSEED but lack VMX_SECONDARY_EXEC_RDSEED_EXITING; attempts to enable this feature bit result in QEMU abort. Resolve the issue but not applying the workaround when we don't have to. As there is no good way to find out if KVM has the fix itself, use 95c5c7c77c ("KVM: nVMX: list VMX MSRs in KVM_GET_MSR_INDEX_LIST") instead as these [are supposed to] come together. Fixes: 048c95163b4 ("target/i386: work around KVM_GET_MSRS bug for secondary execution controls") Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20200331162752.1209928-1-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 4a910e1f6ab4155ec8b24c49b2585cc486916985) Conflicts: target/i386/kvm.c *drop context dep. on 6702514814c Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22target/riscv: update mstatus.SD when FS is set dirtyShihPo Hung2-3/+2
remove the check becuase SD bit should summarize FS and XS fields unconditionally. Signed-off-by: ShihPo Hung <shihpo.hung@sifive.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com> (cherry picked from commit 82f014671cf057de51c4a577c9e2ad637dcec6f9) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22target/riscv: fsd/fsw doesn't dirty FP stateShihPo Hung2-2/+0
Signed-off-by: ShihPo Hung <shihpo.hung@sifive.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com> (cherry picked from commit a59796eb6d59bbd74ce28ddbddb1b83e60674e96) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22target/riscv: Fix tb->flags FS statusShihPo Hung1-4/+1
It was found that running libquantum on riscv-linux qemu produced an incorrect result. After investigation, FP registers are not saved during context switch due to incorrect mstatus.FS. In current implementation tb->flags merges all non-disabled state to dirty. This means the code in mark_fs_dirty in translate.c that handles initial and clean states is unreachable. This patch fixes it and is successfully tested with: libquantum Thanks to Richard for pointing out the actual bug. v3: remove the redundant condition v2: root cause FS problem Suggested-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: ShihPo Hung <shihpo.hung@sifive.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com> (cherry picked from commit 613fa160e19abe8e1fe44423fcfa8ec73d3d48e5) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22riscv: Set xPIE to 1 after xRETYiting Wang1-2/+2
When executing an xRET instruction, supposing xPP holds the value y, xIE is set to xPIE; the privilege mode is changed to y; xPIE is set to 1. But QEMU sets xPIE to 0 incorrectly. Signed-off-by: Yiting Wang <yiting.wang@windriver.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com> (cherry picked from commit a37f21c27d3e2342c2080aafd4cfe7e949612428) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22riscv/sifive_u: fix a memory leak in soc_realize()Pan Nengyuan1-0/+1
Fix a minor memory leak in riscv_sifive_u_soc_realize() Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com> (cherry picked from commit bb8136df698bd565ee4f6c18d26c50dee320bfe4) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22tests: fix modules-test 'duplicate test case' errorCole Robinson1-1/+2
./configure --enable-sdl --audio-drv-list=sdl --enable-modules Will generate two identical test names: /$arch/module/load/sdl Which generates an error like: (tests/modules-test:23814): GLib-ERROR **: 18:23:06.359: duplicate test case path: /aarch64//module/load/sdl Add the subsystem prefix in the name as well, so instead we get: /$arch/module/load/audio-sdl /$arch/module/load/ui-sdl Signed-off-by: Cole Robinson <crobinso@redhat.com> Message-Id: <d64c9aa098cc6e5c0b638438c4959eddfa7e24e2.1573679311.git.crobinso@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit eca3a945234a5f0a499860dd11df64b5f1a2e0a5) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-16xen/9pfs: yield when there isn't enough room on the ringStefano Stabellini1-6/+25
Instead of truncating replies, which is problematic, wait until the client reads more data and frees bytes on the reply ring. Do that by calling qemu_coroutine_yield(). The corresponding qemu_coroutine_enter_if_inactive() is called from xen_9pfs_bh upon receiving the next notification from the client. We need to be careful to avoid races in case xen_9pfs_bh and the coroutine are both active at the same time. In xen_9pfs_bh, wait until either the critical section is over (ring->co == NULL) or until the coroutine becomes inactive (qemu_coroutine_yield() was called) before continuing. Then, simply wake up the coroutine if it is inactive. Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com> Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Message-Id: <20200521192627.15259-2-sstabellini@kernel.org> Signed-off-by: Greg Kurz <groug@kaod.org> (cherry picked from commit a4c4d462729466c4756bac8a0a8d77eb63b21ef7) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-169pfs: include linux/limits.h for XATTR_SIZE_MAXDan Robertson1-0/+1
linux/limits.h should be included for the XATTR_SIZE_MAX definition used by v9fs_xattrcreate. Fixes: 3b79ef2cf488 ("9pfs: limit xattr size in xattrcreate") Signed-off-by: Dan Robertson <dan@dlrobertson.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Message-Id: <20200515203015.7090-2-dan@dlrobertson.com> Signed-off-by: Greg Kurz <groug@kaod.org> (cherry picked from commit 03556ea920b23c466ce7c1283199033de33ee671) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-169pfs: local: ignore O_NOATIME if we don't have permissionsOmar Sandoval1-0/+13
QEMU's local 9pfs server passes through O_NOATIME from the client. If the QEMU process doesn't have permissions to use O_NOATIME (namely, it does not own the file nor have the CAP_FOWNER capability), the open will fail. This causes issues when from the client's point of view, it believes it has permissions to use O_NOATIME (e.g., a process running as root in the virtual machine). Additionally, overlayfs on Linux opens files on the lower layer using O_NOATIME, so in this case a 9pfs mount can't be used as a lower layer for overlayfs (cf. https://github.com/osandov/drgn/blob/dabfe1971951701da13863dbe6d8a1d172ad9650/vmtest/onoatimehack.c and https://github.com/NixOS/nixpkgs/issues/54509). Luckily, O_NOATIME is effectively a hint, and is often ignored by, e.g., network filesystems. open(2) notes that O_NOATIME "may not be effective on all filesystems. One example is NFS, where the server maintains the access time." This means that we can honor it when possible but fall back to ignoring it. Acked-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Signed-off-by: Omar Sandoval <osandov@fb.com> Message-Id: <e9bee604e8df528584693a4ec474ded6295ce8ad.1587149256.git.osandov@fb.com> Signed-off-by: Greg Kurz <groug@kaod.org> (cherry picked from commit a5804fcf7b22fc7d1f9ec794dd284c7d504bd16b) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-169p/proxy: Fix export_flagsGreg Kurz1-2/+2
The common fsdev options are set by qemu_fsdev_add() before it calls the backend specific option parsing code. In the case of "proxy" this means "writeout" or "readonly" were simply ignored. This has been broken from the beginning. Reported-by: Stéphane Graber <stgraber@ubuntu.com> Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Message-Id: <158349633705.1237488.8895481990204796135.stgit@bahia.lan> (cherry picked from commit 659f1953281bcfa5ac217e42877d7d3c32eeea38) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-16virtio-9p-device: fix memleak in virtio_9p_device_unrealizePan Nengyuan1-0/+1
v->vq forgot to cleanup in virtio_9p_device_unrealize, the memory leak stack is as follow: Direct leak of 14336 byte(s) in 2 object(s) allocated from: #0 0x7f819ae43970 (/lib64/libasan.so.5+0xef970) ??:? #1 0x7f819872f49d (/lib64/libglib-2.0.so.0+0x5249d) ??:? #2 0x55a3a58da624 (./x86_64-softmmu/qemu-system-x86_64+0x2c14624) /mnt/sdb/qemu/hw/virtio/virtio.c:2327 #3 0x55a3a571bac7 (./x86_64-softmmu/qemu-system-x86_64+0x2a55ac7) /mnt/sdb/qemu/hw/9pfs/virtio-9p-device.c:209 #4 0x55a3a58e7bc6 (./x86_64-softmmu/qemu-system-x86_64+0x2c21bc6) /mnt/sdb/qemu/hw/virtio/virtio.c:3504 #5 0x55a3a5ebfb37 (./x86_64-softmmu/qemu-system-x86_64+0x31f9b37) /mnt/sdb/qemu/hw/core/qdev.c:876 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Message-Id: <20200117060927.51996-2-pannengyuan@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Acked-by: Greg Kurz <groug@kaod.org> (cherry picked from commit 9580d60e66d1543a0d79265c0085ee09b8782987) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-169p: local: always return -1 on error in local_unlinkat_commonDaniel Henrique Barboza1-8/+6
local_unlinkat_common() is supposed to always return -1 on error. This is being done by jumps to the 'err_out' label, which is a 'return ret' call, and 'ret' is initialized with -1. Unfortunately there is a condition in which the function will return 0 on error: in a case where flags == AT_REMOVEDIR, 'ret' will be 0 when reaching map_dirfd = openat_dir(...) And, if map_dirfd == -1 and errno != ENOENT, the existing 'err_out' jump will execute 'return ret', when ret is still set to zero at that point. This patch fixes it by changing all 'err_out' labels by 'return -1' calls, ensuring that the function will always return -1 on error conditions. 'ret' can be left unintialized since it's now being used just to store the result of 'unlinkat' calls. CC: Greg Kurz <groug@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> [groug: changed prefix in title to be "9p: local:"] Signed-off-by: Greg Kurz <groug@kaod.org> (cherry picked from commit 846cf408a4c8055063f4a5a71ccf7ed030cdad30) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-169pfs: local: Fix possible memory leak in local_link()Jiajun Chen1-1/+1
There is a possible memory leak while local_link return -1 without free odirpath and oname. Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Jaijun Chen <chenjiajun8@huawei.com> Signed-off-by: Xiang Zheng <zhengxiang9@huawei.com> Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Greg Kurz <groug@kaod.org> (cherry picked from commit 841b8d099c462cd4282c4ced8c2a6512899fd8d9) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-15block: Call attention to truncation of long NBD exportsEric Blake2-10/+18
Commit 93676c88 relaxed our NBD client code to request export names up to the NBD protocol maximum of 4096 bytes without NUL terminator, even though the block layer can't store anything longer than 4096 bytes including NUL terminator for display to the user. Since this means there are some export names where we have to truncate things, we can at least try to make the truncation a bit more obvious for the user. Note that in spite of the truncated display name, we can still communicate with an NBD server using such a long export name; this was deemed nicer than refusing to even connect to such a server (since the server may not be under our control, and since determining our actual length limits gets tricky when nbd://host:port/export and nbd+unix:///export?socket=/path are themselves variable-length expansions beyond the export name but count towards the block layer name length). Reported-by: Xueqiang Wei <xuwei@redhat.com> Fixes: https://bugzilla.redhat.com/1843684 Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20200610163741.3745251-3-eblake@redhat.com> (cherry picked from commit 5c86bdf1208916ece0b87e1151c9b48ee54faa3e) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-15virtio-balloon: unref the iothread when unrealizingDavid Hildenbrand1-0/+1
We took a reference when realizing, so let's drop that reference when unrealizing. Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alexander Duyck <alexander.h.duyck@linux.intel.com> Fixes: c13c4153f76d ("virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT") Cc: qemu-stable@nongnu.org Cc: Wei Wang <wei.w.wang@intel.com> Cc: Alexander Duyck <alexander.duyck@gmail.com> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20200520100439.19872-4-david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 105aef9c9479786d27c1c45c9b0b1fa03dc46be3) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-15virtio-balloon: fix free page hinting check on unrealizeDavid Hildenbrand1-1/+1
Checking against guest features is wrong. We allocated data structures based on host features. We can rely on "free_page_bh" as an indicator whether to un-do stuff instead. Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alexander Duyck <alexander.h.duyck@linux.intel.com> Fixes: c13c4153f76d ("virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT") Cc: qemu-stable@nongnu.org Cc: Wei Wang <wei.w.wang@intel.com> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Alexander Duyck <alexander.duyck@gmail.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20200520100439.19872-3-david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 49b01711b8eb3796c6904c7f85d2431572cfe54f) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-15virtio-balloon: fix free page hinting without an iothreadDavid Hildenbrand1-17/+16
In case we don't have an iothread, we mark the feature as abscent but still add the queue. 'free_page_bh' remains set to NULL. qemu-system-i386 \ -M microvm \ -nographic \ -device virtio-balloon-device,free-page-hint=true \ -nographic \ -display none \ -monitor none \ -serial none \ -qtest stdio Doing a "write 0xc0000e30 0x24 0x030000000300000003000000030000000300000003000000030000000300000003000000" We will trigger a SEGFAULT. Let's move the check and bail out. While at it, move the static initializations to instance_init(). free_page_report_status and block_iothread are implicitly set to the right values (0/false) already, so drop the initialization. Reviewed-by: Alexander Duyck <alexander.h.duyck@linux.intel.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Fixes: c13c4153f76d ("virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT") Reported-by: Alexander Bulekov <alxndr@bu.edu> Cc: qemu-stable@nongnu.org Cc: Wei Wang <wei.w.wang@intel.com> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Alexander Duyck <alexander.duyck@gmail.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20200520100439.19872-2-david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 12fc8903a8ee09fb5f642de82699a0b211e1b5a7) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-15nbd/server: Avoid long error message assertions CVE-2020-10761Eric Blake3-3/+26
Ever since commit 36683283 (v2.8), the server code asserts that error strings sent to the client are well-formed per the protocol by not exceeding the maximum string length of 4096. At the time the server first started sending error messages, the assertion could not be triggered, because messages were completely under our control. However, over the years, we have added latent scenarios where a client could trigger the server to attempt an error message that would include the client's information if it passed other checks first: - requesting NBD_OPT_INFO/GO on an export name that is not present (commit 0cfae925 in v2.12 echoes the name) - requesting NBD_OPT_LIST/SET_META_CONTEXT on an export name that is not present (commit e7b1948d in v2.12 echoes the name) At the time, those were still safe because we flagged names larger than 256 bytes with a different message; but that changed in commit 93676c88 (v4.2) when we raised the name limit to 4096 to match the NBD string limit. (That commit also failed to change the magic number 4096 in nbd_negotiate_send_rep_err to the just-introduced named constant.) So with that commit, long client names appended to server text can now trigger the assertion, and thus be used as a denial of service attack against a server. As a mitigating factor, if the server requires TLS, the client cannot trigger the problematic paths unless it first supplies TLS credentials, and such trusted clients are less likely to try to intentionally crash the server. We may later want to further sanitize the user-supplied strings we place into our error messages, such as scrubbing out control characters, but that is less important to the CVE fix, so it can be a later patch to the new nbd_sanitize_name. Consideration was given to changing the assertion in nbd_negotiate_send_rep_verr to instead merely log a server error and truncate the message, to avoid leaving a latent path that could trigger a future CVE DoS on any new error message. However, this merely complicates the code for something that is already (correctly) flagging coding errors, and now that we are aware of the long message pitfall, we are less likely to introduce such errors in the future, which would make such error handling dead code. Reported-by: Xueqiang Wei <xuwei@redhat.com> CC: qemu-stable@nongnu.org Fixes: https://bugzilla.redhat.com/1843684 CVE-2020-10761 Fixes: 93676c88d7 Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20200610163741.3745251-2-eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> (cherry picked from commit 5c4fe018c025740fef4a0a4421e8162db0c3eefd) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-15net: Do not include a newline in the id of -nic devicesThomas Huth1-1/+1
The '\n' sneaked in by accident here, an "id" string should really not contain a newline character at the end. Fixes: 78cd6f7bf6b ('net: Add a new convenience option "--nic" ...') Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200518074352.23125-1-thuth@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu> (cherry picked from commit 0561dfac082becdd9e89110249a27b309b62aa9f) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-099p: Lock directory streams with a CoMutexGreg Kurz1-4/+4
Locking was introduced in QEMU 2.7 to address the deprecation of readdir_r(3) in glibc 2.24. It turns out that the frontend code is the worst place to handle a critical section with a pthread mutex: the code runs in a coroutine on behalf of the QEMU mainloop and then yields control, waiting for the fsdev backend to process the request in a worker thread. If the client resends another readdir request for the same fid before the previous one finally unlocked the mutex, we're deadlocked. This never bit us because the linux client serializes readdir requests for the same fid, but it is quite easy to demonstrate with a custom client. A good solution could be to narrow the critical section in the worker thread code and to return a copy of the dirent to the frontend, but this causes quite some changes in both 9p.c and codir.c. So, instead of that, in order for people to easily backport the fix to older QEMU versions, let's simply use a CoMutex since all the users for this sit in coroutines. Fixes: 7cde47d4a89d ("9p: add locking to V9fsDir") Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Message-Id: <158981894794.109297.3530035833368944254.stgit@bahia.lan> Signed-off-by: Greg Kurz <groug@kaod.org> (cherry picked from commit ed463454efd0ac3042ff772bfe1b1d846dc281a5) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-09qemu-nbd: Close inherited stderrRaphael Pour1-1/+5
Close inherited stderr of the parent if fork_process is false. Otherwise no one will close it. (introduced by e6df58a5) This only affected 'qemu-nbd -c /dev/nbd0'. Signed-off-by: Raphael Pour <raphael.pour@hetzner.com> Message-Id: <d8ddc993-9816-836e-a3de-c6edab9d9c49@hetzner.com> Reviewed-by: Eric Blake <eblake@redhat.com> [eblake: Enhance commit message] Signed-off-by: Eric Blake <eblake@redhat.com> (cherry picked from commit 0eaf453ebf6788885fbb5d40426b154ef8805407) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-09target/arm: Clear tail in gvec_fmul_idx_*, gvec_fmla_idx_*Richard Henderson1-0/+2
Must clear the tail for AdvSIMD when SVE is enabled. Fixes: ca40a6e6e39 Cc: qemu-stable@nongnu.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200513163245.17915-15-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 525d9b6d42844e187211d25b69be8b378785bc24) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-09hostmem: don't use mbind() if host-nodes is emptyIgor Mammedov1-2/+4
Since 5.0 QEMU uses hostmem backend for allocating main guest RAM. The backend however calls mbind() which is typically NOP in case of default policy/absent host-nodes bitmap. However when runing in container with black-listed mbind() syscall, QEMU fails to start with error "cannot bind memory to host NUMA nodes: Operation not permitted" even when user hasn't provided host-nodes to pin to explictly (which is the case with -m option) To fix issue, call mbind() only in case when user has provided host-nodes explicitly (i.e. host_nodes bitmap is not empty). That should allow to run QEMU in containers with black-listed mbind() without memory pinning. If QEMU provided memory-pinning is required user still has to white-list mbind() in container configuration. Reported-by: Manuel Hohmann <mhohmann@physnet.uni-hamburg.de> Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20200430154606.6421-1-imammedo@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> (cherry picked from commit 70b6d525dfb51d5e523d568d1139fc051bc223c5) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-09target/ppc: Fix mtmsr(d) L=1 variant that loses interruptsNicholas Piggin1-19/+27
If mtmsr L=1 sets MSR[EE] while there is a maskable exception pending, it does not cause an interrupt. This causes the test case to hang: https://lists.gnu.org/archive/html/qemu-ppc/2019-10/msg00826.html More recently, Linux reduced the occurance of operations (e.g., rfi) which stop translation and allow pending interrupts to be processed. This started causing hangs in Linux boot in long-running kernel tests, running with '-d int' shows the decrementer stops firing despite DEC wrapping and MSR[EE]=1. https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-April/208301.html The cause is the broken mtmsr L=1 behaviour, which is contrary to the architecture. From Power ISA v3.0B, p.977, Move To Machine State Register, Programming Note states: If MSR[EE]=0 and an External, Decrementer, or Performance Monitor exception is pending, executing an mtmsrd instruction that sets MSR[EE] to 1 will cause the interrupt to occur before the next instruction is executed, if no higher priority exception exists Fix this by handling L=1 exactly the same way as L=0, modulo the MSR bits altered. The confusion arises from L=0 being "context synchronizing" whereas L=1 is "execution synchronizing", which is a weaker semantic. However this is not a relaxation of the requirement that these exceptions cause interrupts when MSR[EE]=1 (e.g., when mtmsr executes to completion as TCG is doing here), rather it specifies how a pipelined processor can have multiple instructions in flight where one may influence how another behaves. Cc: qemu-stable@nongnu.org Reported-by: Anton Blanchard <anton@ozlabs.org> Reported-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20200414111131.465560-1-npiggin@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Tested-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit 5ed195065cc6895f61b9d59bfa0a0536ed5ed51e) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-09vhost-user-gpu: Release memory returned by vu_queue_pop() with free()Philippe Mathieu-Daudé2-3/+3
vu_queue_pop() returns memory that must be freed with free(). Cc: qemu-stable@nongnu.org Reported-by: Coverity (CID 1421887 ALLOC_FREE_MISMATCH) Suggested-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 4ff97121a3ee631971aadc87e3d4e7fb66f15aa8) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-09xen-block: Fix double qlist remove and request leakAnthony PERARD1-32/+16
Commit a31ca6801c02 ("qemu/queue.h: clear linked list pointers on remove") revealed that a request was removed twice from a list, once in xen_block_finish_request() and a second time in xen_block_release_request() when both function are called from xen_block_complete_aio(). But also, the `requests_inflight' counter is decreased twice, and thus became negative. This is a bug that was introduced in bfd0d6366043 ("xen-block: improve response latency"), where a `finished' list was removed. That commit also introduced a leak of request in xen_block_do_aio(). That function calls xen_block_finish_request() but the request is never released after that. To fix both issue, we do two changes: - we squash finish_request() and release_request() together as we want to remove a request from 'inflight' list to add it to 'freelist'. - before releasing a request, we need to let the other end know the result, thus we should call xen_block_send_response() before releasing a request. The first change fixes the double QLIST_REMOVE() as we remove the extra call. The second change makes the leak go away because if we want to call finish_request(), we need to call a function that does all of finish, send response, and release. Fixes: bfd0d6366043 ("xen-block: improve response latency") Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Message-Id: <20200406140217.1441858-1-anthony.perard@citrix.com> Reviewed-by: Paul Durrant <paul@xen.org> [mreitz: Amended commit message as per Paul's suggestions] Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit 36d883ba0de8a281072ded2b51e0a711fd002139) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-09dump: Fix writing of ELF sectionPeter Maydell1-1/+1
In write_elf_section() we set the 'shdr' pointer to point to local structures shdr32 or shdr64, which we fill in to be written out to the ELF dump. Unfortunately the address we pass to fd_write_vmcore() has a spurious '&' operator, so instead of writing out the section header we write out the literal pointer value followed by whatever is on the stack after the 'shdr' local variable. Pass the correct address into fd_write_vmcore(). Spotted by Coverity: CID 1421970. Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200324173630.12221-1-peter.maydell@linaro.org (cherry picked from commit 174d2d6856bf435f4f58e9303ba30dd0e1279d3f) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-09tcg/i386: Fix INDEX_op_dup2_vecRichard Henderson1-3/+7
We were only constructing the 64-bit element, and not replicating the 64-bit element across the rest of the vector. Cc: qemu-stable@nongnu.org Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit e20cb81d9c5a3d0f9c08f3642728a210a1c162c9) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-09hw/i386/amd_iommu.c: Fix corruption of log events passed to guestPeter Maydell1-1/+1
In the function amdvi_log_event(), we write an event log buffer entry into guest ram, whose contents are passed to the function via the "uint64_t *evt" argument. Unfortunately, a spurious '&' in the call to dma_memory_write() meant that instead of writing the event to the guest we would write the literal value of the pointer, plus whatever was in the following 8 bytes on the stack. This error was spotted by Coverity. Fix the bug by removing the '&'. Fixes: CID 1421945 Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20200326105349.24588-1-peter.maydell@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 32a2d6b1f6b4405f0fc20c031e61d5d48e3d9cd1) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-03qemu-ga: document vsock-listen in the man pageStefan Hajnoczi2-3/+6
Although qemu-ga has supported vsock since 2016 it was not documented on the man page. Also add the socket address representation to the qga --help output. Fixes: 586ef5dee77180fc32e33bc08051600030630239 ("qga: add vsock-listen method") Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> (cherry picked from commit 7b46aadbbfb7b06cd45a3b113b1f7c003c68f603) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-03qga: Fix undefined C behaviorEric Blake1-2/+7
The QAPI struct GuestFileWhence has a comment about how we are exploiting equivalent values between two different integer types shared in a union. But C says behavior is undefined on assignments to overlapping storage when the two types are not the same width, and indeed, 'int64_t value' and 'enum QGASeek name' are very likely to be different in width. Utilize a temporary variable to fix things. Reported-by: Peter Maydell <peter.maydell@linaro.org> Fixes: 0b4b49387 Fixes: Coverity CID 1421990 Signed-off-by: Eric Blake <eblake@redhat.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> (cherry picked from commit a23f38a72921fa915536a981a4f8a9134512f120) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-03qga-win: prevent crash when executing guest-file-read with large countBasil Salman1-1/+7
guest-file-read command is currently implemented to read from a file handle count number of bytes. when executed with a very large count number qemu-ga crashes. after some digging turns out that qemu-ga crashes after trying to allocate a buffer large enough to save the data read in it, the buffer was allocated using g_malloc0 which is not fail safe, and results a crash in case of failure. g_malloc0 was replaced with g_try_malloc0() which returns NULL on failure, A check was added for that case in order to prevent qemu-ga from crashing and to send a response to the qemu-ga client accordingly. Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1594054 Signed-off-by: Basil Salman <basil@daynix.com> Reported-by: Fakhri Zulkifli <mohdfakhrizulkifli@gmail.com> Cc: qemu-stable@nongnu.org Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> (cherry picked from commit 807e2b6fce022707418bc8f61c069d91c613b3d2) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-03qga-win: Handle VSS_E_PROVIDER_ALREADY_REGISTERED errorSameeh Jubran1-0/+11
This patch handles the case where VSS Provider is already registered, where in such case qga uninstalls the provider and registers it again. Signed-off-by: Sameeh Jubran <sjubran@redhat.com> Signed-off-by: Basil Salman <basil@daynix.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> (cherry picked from commit b2413df83348acf371c03bced9a3845bba883ed5) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-03qga: Installer: Wait for installation to finishBasil Salman1-1/+1
Installation might fail if we don't wait for the provider unregisteration process to finish. Signed-off-by: Sameeh Jubran <sjubran@redhat.com> Signed-off-by: Basil Salman <basil@daynix.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> (cherry picked from commit bb1ce44b15f159b67fafc5f4b285bbf20a1961e9) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-03compat: disable edid on correct virtio-gpu deviceCornelia Huck1-1/+1
Commit bb15791166c1 ("compat: disable edid on virtio-gpu base device") tried to disable 'edid' on the virtio-gpu base device. However, that device is not 'virtio-gpu', but 'virtio-gpu-device'. Fix it. Fixes: bb15791166c1 ("compat: disable edid on virtio-gpu base device") Reported-by: Lukáš Doktor <ldoktor@redhat.com> Tested-by: Lukáš Doktor <ldoktor@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com> Message-id: 20200318093919.24942-1-cohuck@redhat.com Cc: qemu-stable@nongnu.org Signed-off-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 02501fc39381c4dabaf6becdd12c2a4754c3847c) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
generated by cgit v1.1 at 2025-09-18 00:14:26 +0000