- 21 6月, 2018 40 次提交
-
-
由 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>
-
由 Viktor Mihajlovski 提交于
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: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com> Message-Id: <1522940844-12336-4-git-send-email-mihajlov@linux.vnet.ibm.com> Reviewed-by: NChristian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com> (cherry picked from commit e8c7ef28) 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>
-
由 Peter Maydell 提交于
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: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Message-id: 20180410134203.17552-1-peter.maydell@linaro.org (cherry picked from commit 6670b494) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Richard Henderson 提交于
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: NRichard Henderson <richard.henderson@linaro.org> Message-id: 20180410003558.2470-1-richard.henderson@linaro.org Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> (cherry picked from commit 9743cd57) Conflicts: target/arm/translate.h tcg/tcg.h * rework to avoid functional dependency on 15fa08f8Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Philippe Mathieu-Daudé 提交于
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: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: NKevin Wolf <kwolf@redhat.com> (cherry picked from commit 07c13a71) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Greg Kurz 提交于
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: NGreg Kurz <groug@kaod.org> Message-Id: <152311222681.203086.8874800175539040298.stgit@bahia> Signed-off-by: NCornelia Huck <cohuck@redhat.com> (cherry picked from commit be4d026f) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Peter Maydell 提交于
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/1754038Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Reviewed-by: NAlex Bennée <alex.bennee@linaro.org> Message-id: 20180406123838.21249-1-peter.maydell@linaro.org (cherry picked from commit c52e7132) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Kevin Wolf 提交于
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: NKevin Wolf <kwolf@redhat.com> Message-id: 20180403110810.25624-1-kwolf@redhat.com Signed-off-by: NJeff Cody <jcody@redhat.com> (cherry picked from commit 9dae635a) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Greg Kurz 提交于
The string returned by object_property_get_str() is dynamically allocated. Signed-off-by: NGreg Kurz <groug@kaod.org> Message-Id: <152231458624.69730.1752893648612848392.stgit@bahia.lan> Reviewed-by: NCornelia Huck <cohuck@redhat.com> Reviewed-by: NThomas Huth <thuth@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com> (cherry picked from commit 72a841d2) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Alexandro Sanchez Bach 提交于
In commit 7073fbad, 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: NAlexandro Sanchez Bach <alexandro@phi.nz> Signed-off-by: NAlexandro Sanchez Bach <alexandro@phi.nz> Cc: qemu-stable@nongnu.org Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 5cd10051) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Richard Henderson 提交于
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: NMichael Clark <mjc@sifive.com> Reviewed-by: NEmilio G. Cota <cota@braap.org> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: NRichard Henderson <richard.henderson@linaro.org> (cherry picked from commit f2f1dde7) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Max Reitz 提交于
Signed-off-by: NMax Reitz <mreitz@redhat.com> Message-id: 20180228131315.30194-3-mreitz@redhat.com Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> Signed-off-by: NMax Reitz <mreitz@redhat.com> (cherry picked from commit 733d1dce) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Max Reitz 提交于
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: NDaniel P. Berrange <berrange@redhat.com> Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1549231 Cc: qemu-stable@nongnu.org Signed-off-by: NMax Reitz <mreitz@redhat.com> Message-id: 20180228131315.30194-2-mreitz@redhat.com Reviewed-by: NEric Blake <eblake@redhat.com> Signed-off-by: NMax Reitz <mreitz@redhat.com> (cherry picked from commit 82b45e0a) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Michal Privoznik 提交于
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: NMichal Privoznik <mprivozn@redhat.com> Message-Id: <6f10cd53d361a395aa0e85a9311ec4e9a8fc11e5.1521868451.git.mprivozn@redhat.com> Cc: qemu-stable@nongnu.org Reviewed-by: NEric Blake <eblake@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> (cherry picked from commit f8e1a989) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Greg Kurz 提交于
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: NR. Nageswara Sastry <nasastry@in.ibm.com> Buglink: https://github.com/open-power-host-os/qemu/issues/37Signed-off-by: NGreg Kurz <groug@kaod.org> Tested-by: NR. Nageswara Sastry <nasastry@in.ibm.com> Signed-off-by: NJason Wang <jasowang@redhat.com> (cherry picked from commit 94b52958) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Victor Kamensky 提交于
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: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NVictor Kamensky <kamensky@cisco.com> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Message-id: 1521526368-1996-1-git-send-email-kamensky@cisco.com Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> (cherry picked from commit a75a52d6) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Kevin Wolf 提交于
Signed-off-by: NKevin Wolf <kwolf@redhat.com> Reviewed-by: NJack Schwartz <jack.schwartz@oracle.com> Reviewed-by: NEric Blake <eblake@redhat.com> (cherry picked from commit e2679395) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Kevin Wolf 提交于
Signed-off-by: NKevin Wolf <kwolf@redhat.com> Reviewed-by: NJack Schwartz <jack.schwartz@oracle.com> (cherry picked from commit 1c8c426f) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Kevin Wolf 提交于
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: NKevin Wolf <kwolf@redhat.com> Reviewed-by: NJack Schwartz <jack.schwartz@oracle.com> (cherry picked from commit 49713c41) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Kevin Wolf 提交于
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: NKevin Wolf <kwolf@redhat.com> Reviewed-by: NJack Schwartz <jack.schwartz@oracle.com> (cherry picked from commit dbf2dce7) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Kevin Wolf 提交于
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: NKevin Wolf <kwolf@redhat.com> Reviewed-by: NJack Schwartz <jack.schwartz@oracle.com> (cherry picked from commit b17a9054) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Jack Schwartz 提交于
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: NJack Schwartz <jack.schwartz@oracle.com> Reviewed-by: NDaniel Kiper <daniel.kiper@oracle.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com> (cherry picked from commit 4b9006a4) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Jack Schwartz 提交于
Refer to field names when displaying fields in printf and debug statements. Signed-off-by: NJack Schwartz <jack.schwartz@oracle.com> Reviewed-by: NDaniel Kiper <daniel.kiper@oracle.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com> (cherry picked from commit ce5eb6dc) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Jack Schwartz 提交于
Remove unused variables: mh_mode_type, mh_width, mh_height, mh_depth Signed-off-by: NJack Schwartz <jack.schwartz@oracle.com> Reviewed-by: NDaniel Kiper <daniel.kiper@oracle.com> Reviewed-by: NPrasad J Pandit <pjp@fedoraproject.org> Signed-off-by: NKevin Wolf <kwolf@redhat.com> (cherry picked from commit 7a2e43cc) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Jack Schwartz 提交于
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: NDaniel Kiper <daniel.kiper@oracle.com> Signed-off-by: NJack Schwartz <jack.schwartz@oracle.com> Reviewed-by: NDaniel Kiper <daniel.kiper@oracle.com> Reviewed-by: NPrasad J Pandit <pjp@fedoraproject.org> Signed-off-by: NKevin Wolf <kwolf@redhat.com> (cherry picked from commit 2a8fcd11) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Peter Lieven 提交于
Reset the dirty bitmap before reading to make sure we don't miss any new data. Cc: qemu-stable@nongnu.org Signed-off-by: NPeter Lieven <pl@kamp.de> Message-Id: <1520507908-16743-3-git-send-email-pl@kamp.de> Reviewed-by: NJuan Quintela <quintela@redhat.com> Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com> (cherry picked from commit 86b124bc) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Paolo Bonzini 提交于
Fixes: 11e732a5Reported-by: NCornelia Huck <cohuck@redhat.com> Reported-by: Nluigi burdo <intermediadc@hotmail.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Tested-by: NCornelia Huck <cohuck@redhat.com> Tested-by: NThomas Huth <thuth@redhat.com> Message-id: 20180307130238.19358-1-pbonzini@redhat.com Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> (cherry picked from commit b39b61e4) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Paolo Bonzini 提交于
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: NAlexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> (cherry picked from commit db84fd97) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Paolo Bonzini 提交于
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: NAlexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> (cherry picked from commit ad0c60fa) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Paolo Bonzini 提交于
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: NAlexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 11e732a5) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Paolo Bonzini 提交于
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: NAlexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> (cherry picked from commit b2a44fca) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Paolo Bonzini 提交于
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: NAlexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 4c6ebbb3) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-