- 12 7月, 2018 25 次提交
-
-
由 Peter Xu 提交于
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: NJason Wang <jasowang@redhat.com> [peterx: rewrite the commit message] Signed-off-by: NPeter Xu <peterx@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> (cherry picked from commit 36d2d52b) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Jan Kiszka 提交于
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: NJan Kiszka <jan.kiszka@siemens.com> Message-id: 28b927d3-da58-bce4-cc13-bfec7f9b1cb9@siemens.com Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> (cherry picked from commit 887aae10) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Michal Privoznik 提交于
After f771c544 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: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NThomas Huth <thuth@redhat.com> Message-id: cb05bb1909daa6ba62145c0194aafa05a14ed3d1.1526569138.git.mprivozn@redhat.com Signed-off-by: NGerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 08d9864f) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Cornelia Huck 提交于
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: NThomas Huth <thuth@redhat.com> Suggested-by: NChristian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: NThomas Huth <thuth@redhat.com> Tested-by: NThomas Huth <thuth@redhat.com> Acked-by: NChristian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: NHalil Pasic <pasic@linux.ibm.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com> (cherry picked from commit 838fb84f) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Cornelia Huck 提交于
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: NThomas Huth <thuth@redhat.com> Reviewed-by: NDavid Hildenbrand <david@redhat.com> Reviewed-by: NHalil Pasic <pasic@linux.ibm.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com> (cherry picked from commit 0c53057a) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Thomas Huth 提交于
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: NThomas Huth <thuth@redhat.com> Message-Id: <1525774672-11913-1-git-send-email-thuth@redhat.com> Reviewed-by: NCornelia Huck <cohuck@redhat.com> Acked-by: NChristian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com> (cherry picked from commit a6e4385d) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Cornelia Huck 提交于
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: NThomas Huth <thuth@redhat.com> Tested-by: NThomas Huth <thuth@redhat.com> Acked-by: NChristian Borntraeger <borntraeger@de.ibm.com> Acked-by: NHalil Pasic <pasic@linux.ibm.com> Reviewed-by: NDavid Hildenbrand <david@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com> (cherry picked from commit 6e9c893e) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Fam Zheng 提交于
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: NStefan Hajnoczi <stefanha@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> Signed-off-by: NFam Zheng <famz@redhat.com> Message-id: 20180601092648.24614-3-famz@redhat.com Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com> (cherry picked from commit 38445538) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Michael Walle 提交于
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: NMichael Walle <michael@walle.cc> Tested-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: NAlex Bennée <alex.bennee@linaro.org> (cherry picked from commit 81e9cbd0) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Max Reitz 提交于
Signed-off-by: NMax Reitz <mreitz@redhat.com> Message-id: 20180502202051.15493-4-mreitz@redhat.com Reviewed-by: NEric Blake <eblake@redhat.com> Signed-off-by: NMax Reitz <mreitz@redhat.com> (cherry picked from commit 4e7d73c5) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Max Reitz 提交于
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: NMax Reitz <mreitz@redhat.com> Message-id: 20180502202051.15493-3-mreitz@redhat.com Reviewed-by: NEric Blake <eblake@redhat.com> Signed-off-by: NMax Reitz <mreitz@redhat.com> (cherry picked from commit 4615f878) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Max Reitz 提交于
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: NMax Reitz <mreitz@redhat.com> Message-id: 20180502202051.15493-2-mreitz@redhat.com Reviewed-by: NEric Blake <eblake@redhat.com> Signed-off-by: NMax Reitz <mreitz@redhat.com> (cherry picked from commit 2a01c01f) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Max Reitz 提交于
Signed-off-by: NMax Reitz <mreitz@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> Message-id: 20180509182002.8044-3-mreitz@redhat.com Signed-off-by: NMax Reitz <mreitz@redhat.com> (cherry picked from commit 28036a7f) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Max Reitz 提交于
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: NMax Reitz <mreitz@redhat.com> Message-id: 20180509182002.8044-2-mreitz@redhat.com Reviewed-by: NEric Blake <eblake@redhat.com> Signed-off-by: NMax Reitz <mreitz@redhat.com> (cherry picked from commit d16699b6) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Olaf Hering 提交于
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: NOlaf Hering <olaf@aepfle.de> Message-Id: <20180418075045.27393-1-olaf@aepfle.de> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 181ce1d0) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Gerd Hoffmann 提交于
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=1567733Signed-off-by: NGerd Hoffmann <kraxel@redhat.com> Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20180427115528.345-1-kraxel@redhat.com (cherry picked from commit 5bd5c27c) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Greg Kurz 提交于
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: NGreg Kurz <groug@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> (cherry picked from commit 0550b120) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Greg Kurz 提交于
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: NGreg Kurz <groug@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> (cherry picked from commit bce00964) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Peter Maydell 提交于
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: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Message-id: 20180503105730.5958-1-peter.maydell@linaro.org (cherry picked from commit b1e5336a) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Henry Wertz 提交于
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: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NHenry Wertz <hwertz10@gmail.com> Signed-off-by: NRichard Henderson <richard.henderson@linaro.org> (cherry picked from commit 3f814b80) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Cornelia Huck 提交于
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: d046c51d ("pc-bios/s390-ccw: Get device address via diag 308/6") Cc: qemu-stable@nongnu.org Signed-off-by: NCornelia Huck <cohuck@redhat.com> Acked-by: NChristian Borntraeger <borntraeger@de.ibm.com> Tested-by: NThomas Huth <thuth@redhat.com> Signed-off-by: NThomas Huth <thuth@redhat.com> (cherry picked from commit 63d8b5ac) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Eric Blake 提交于
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: NEric Blake <eblake@redhat.com> Message-Id: <20180501154654.943782-1-eblake@redhat.com> Reviewed-by: NVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> (cherry picked from commit e475d108) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Jason Andryuk 提交于
Commit d7d218ef 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: NJason Andryuk <jandryuk@gmail.com> Message-id: 20180420183219.20722-1-jandryuk@gmail.com Cc: qemu-stable@nongnu.org Signed-off-by: NGerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 0ee86bb6) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Geert Uytterhoeven 提交于
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: NGeert Uytterhoeven <geert+renesas@glider.be> Message-id: 1523541337-23919-1-git-send-email-geert+renesas@glider.be Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> (cherry picked from commit 14ec3cbd) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Marc-André Lureau 提交于
No need to close the TPM data socket on the emulator end, qemu will close it after a SHUTDOWN. This avoids a race between close() and read() in the TPM data thread. Reported-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com> Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru> (cherry picked from commit 7647d5c6) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
- 24 4月, 2018 1 次提交
-
-
由 Peter Maydell 提交于
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
- 18 4月, 2018 2 次提交
-
-
由 Peter Maydell 提交于
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Peter Maydell 提交于
This reverts commit 1b2503fc. Unfortunately this fix regresses console handling on MIPS Malta; since the mux ctrl-a b bug is not a regression since 2.11, we take the conservative approach and just drop it from 2.12. Reported-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
- 17 4月, 2018 8 次提交
-
-
由 Richard Henderson 提交于
Without bounding the increment, we can overflow exp either here in scalbn_decomposed or when adding the bias in round_canonical. This can result in e.g. underflowing to 0 instead of overflowing to infinity. The old softfloat code did bound the increment. Signed-off-by: NRichard Henderson <richard.henderson@linaro.org> Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NAlex Bennée <alex.bennee@linaro.org> Tested-by: NAlex Bennée <alex.bennee@linaro.org> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Marc-André Lureau 提交于
Commit fb5e19d2 originally fixed the regression, but was inadvertently broken again in merge commit 2d6752d3. Fixes: https://bugs.launchpad.net/qemu/+bug/1654137 Cc: qemu-stable@nongnu.org Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20180416181844.7851-1-marcandre.lureau@redhat.com Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Peter Maydell 提交于
In commit 8c5931de we added support for SVE extended sigframe records. These mean that the signal frame might now be larger than the size of the target_rt_sigframe record, so make sure we call lock_user on the entire frame size when we're creating it. (The code for restoring the signal frame already correctly handles the extended records by locking the 'extra' section separately to the main section.) In particular, this fixes a bug even for non-SVE signal frames, because it extends the locked section to cover the target_rt_frame_record. Previously this was part of 'struct target_rt_sigframe', but in commit e1eecd1d we pulled it out into its own struct, and so locking the target_rt_sigframe alone doesn't cover it. This bug would mean that we would fail to correctly handle the case where a signal was taken with SP pointing 16 bytes into an unwritable page, with the page immediately below it in memory being writable. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
-
由 Peter Maydell 提交于
i386: Don't automatically enable FEAT_KVM_HINTS bits Bug fix for "-cpu host" with newer kernels. # gpg: Signature made Mon 16 Apr 2018 17:37:53 BST # gpg: using RSA key 2807936F984DC5A6 # gpg: Good signature from "Eduardo Habkost <ehabkost@redhat.com>" # Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF D1AA 2807 936F 984D C5A6 * remotes/ehabkost/tags/x86-next-pull-request: i386: Don't automatically enable FEAT_KVM_HINTS bits Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Peter Maydell 提交于
vhost: bugfix This fixes a regression in vhost. Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> # gpg: Signature made Mon 16 Apr 2018 17:12:59 BST # gpg: using RSA key 281F0DB8D28D5469 # gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" # gpg: aka "Michael S. Tsirkin <mst@redhat.com>" # Primary key fingerprint: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67 # Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469 * remotes/mst/tags/for_upstream: vhost: do not verify ring mappings when IOMMU is enabled Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Alex Bennée 提交于
The re-factoring of div_floats changed the order of checking meaning an operation like -inf/0 erroneously raises the divbyzero flag. IEEE-754 (2008) specifies this should only occur for operations on finite operands. We fix this by moving the check on the dividend being Inf/0 to before the divisor is zero check. Signed-off-by: NAlex Bennée <alex.bennee@linaro.org> Message-id: 20180416135442.30606-1-alex.bennee@linaro.org Cc: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> Reviewed-by: NBastian Koppelmann <kbastian@mail.uni-paderborn.de> Tested-by: NBastian Koppelmann <kbastian@mail.uni-paderborn.de> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Eduardo Habkost 提交于
The assumption in the cpu->max_features code is that anything enabled on GET_SUPPORTED_CPUID should be enabled on "-cpu host". This shouldn't be the case for FEAT_KVM_HINTS. This adds a new FeatureWordInfo::no_autoenable_flags field, that can be used to prevent FEAT_KVM_HINTS bits to be enabled automatically. Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com> Message-Id: <20180410211534.26079-1-ehabkost@redhat.com> Tested-by: NWanpeng Li <wanpengli@tencent.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Jason Wang 提交于
When IOMMU is enabled, we store virtqueue metadata as iova (though it may has _phys suffix) and access them through dma helpers. Any translation failures could be reported by IOMMU. In this case, trying to validate iova against gpa won't work and will cause a false error reporting. So this patch bypasses the ring verification if IOMMU is enabled which is similar to the behavior before 0ca1fd2d that calls vhost_memory_map() which is a nop when IOMMU is enabled. Fixes: 0ca1fd2d ("vhost: Simplify ring verification checks") Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: NJason Wang <jasowang@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
- 16 4月, 2018 4 次提交
-
-
由 Michael Tokarev 提交于
Fixes 722cd749Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20180416093719.2543-1-mjt@msgid.tls.msk.ru Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Peter Maydell 提交于
A fix for handling dirty bitmaps stored in qcow2 files. This is not absolutely necessary for 2.12, but if there is an rc4, it should go in. # gpg: Signature made Mon 16 Apr 2018 13:35:08 BST # gpg: using RSA key F407DB0061D5CF40 # gpg: Good signature from "Max Reitz <mreitz@redhat.com>" # Primary key fingerprint: 91BE B60A 30DB 3E88 57D1 1829 F407 DB00 61D5 CF40 * remotes/maxreitz/tags/pull-block-2018-04-16: iotests: fix 169 qcow2: try load bitmaps only once Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
Improve and fix 169: - use MIGRATION events instead of RESUME - make a TODO: enable dirty-bitmaps capability for offline case - recreate vm_b without -incoming near test end This (likely) fixes racy faults at least of the following types: - timeout on waiting for RESUME event - sha256 mismatch on line 136 (142 after this patch) - fail to self.vm_b.launch() on line 135 (141 now after this patch) And surely fixes cat processes, left after test finish. Signed-off-by: NVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-id: 20180411122606.367301-3-vsementsov@virtuozzo.com Reviewed-by: NMax Reitz <mreitz@redhat.com> Signed-off-by: NMax Reitz <mreitz@redhat.com>
-
Checking reopen by existence of some bitmaps is wrong, as it may be some other bitmaps, or on the other hand, user may remove bitmaps. This criteria is bad. To simplify things and make behavior more predictable let's just add a flag to remember, that we've already tried to load bitmaps on open and do not want do it again. Signed-off-by: NVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-id: 20180411122606.367301-2-vsementsov@virtuozzo.com [mreitz: Changed comment wording according to Eric Blake's suggestion] Signed-off-by: NMax Reitz <mreitz@redhat.com>
-