aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-07-15kvm: Persistent per kvmslot dirty bitmapPeter Xu
When synchronizing dirty bitmap from kernel KVM we do it in a per-kvmslot fashion and we allocate the userspace bitmap for each of the ioctl. This patch instead make the bitmap cache be persistent then we don't need to g_malloc0() every time. More importantly, the cached per-kvmslot dirty bitmap will be further used when we want to add support for the KVM_CLEAR_DIRTY_LOG and this cached bitmap will be used to guarantee we won't clear any unknown dirty bits otherwise that can be a severe data loss issue for migration code. Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20190603065056.25211-9-peterx@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2019-07-15kvm: Update comments for sync_dirty_bitmapPeter Xu
It's obviously obsolete. Do some update. Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-Id: <20190603065056.25211-8-peterx@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2019-07-15memory: Introduce memory listener hook log_clear()Peter Xu
Introduce a new memory region listener hook log_clear() to allow the listeners to hook onto the points where the dirty bitmap is cleared by the bitmap users. Previously log_sync() contains two operations: - dirty bitmap collection, and, - dirty bitmap clear on remote site. Let's take KVM as example - log_sync() for KVM will first copy the kernel dirty bitmap to userspace, and at the same time we'll clear the dirty bitmap there along with re-protecting all the guest pages again. We add this new log_clear() interface only to split the old log_sync() into two separated procedures: - use log_sync() to collect the collection only, and, - use log_clear() to clear the remote dirty bitmap. With the new interface, the memory listener users will still be able to decide how to implement the log synchronization procedure, e.g., they can still only provide log_sync() method only and put all the two procedures within log_sync() (that's how the old KVM works before KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2 is introduced). However with this new interface the memory listener users will start to have a chance to postpone the log clear operation explicitly if the module supports. That can really benefit users like KVM at least for host kernels that support KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2. There are three places that can clear dirty bits in any one of the dirty bitmap in the ram_list.dirty_memory[3] array: cpu_physical_memory_snapshot_and_clear_dirty cpu_physical_memory_test_and_clear_dirty cpu_physical_memory_sync_dirty_bitmap Currently we hook directly into each of the functions to notify about the log_clear(). Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20190603065056.25211-7-peterx@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2019-07-15memory: Pass mr into snapshot_and_clear_dirtyPeter Xu
Also we change the 2nd parameter of it to be the relative offset within the memory region. This is to be used in follow up patches. Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-Id: <20190603065056.25211-6-peterx@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2019-07-15bitmap: Add bitmap_copy_with_{src|dst}_offset()Peter Xu
These helpers copy the source bitmap to destination bitmap with a shift either on the src or dst bitmap. Meanwhile, we never have bitmap tests but we should. This patch also introduces the initial test cases for utils/bitmap.c but it only tests the newly introduced functions. Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-Id: <20190603065056.25211-5-peterx@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> --- Bitmap test used sizeof(unsigned long) instead of BITS_PER_LONG.
2019-07-15memory: Don't set migration bitmap when without migrationPeter Xu
Similar to 9460dee4b2 ("memory: do not touch code dirty bitmap unless TCG is enabled", 2015-06-05) but for the migration bitmap - we can skip the MIGRATION bitmap update if migration not enabled. Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20190603065056.25211-4-peterx@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2019-07-15migration: No need to take rcu during sync_dirty_bitmapPeter Xu
cpu_physical_memory_sync_dirty_bitmap() has one RAMBlock* as parameter, which means that it must be with RCU read lock held already. Taking it again inside seems redundant. Removing it. Instead comment on the functions about the RCU read lock. Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20190603065056.25211-2-peterx@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2019-07-15migration/ram.c: reset complete_round when we gets a queued pageWei Yang
In case we gets a queued page, the order of block is interrupted. We may not rely on the complete_round flag to say we have already searched the whole blocks on the list. Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-Id: <20190605010828.6969-1-richardw.yang@linux.intel.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2019-07-15migration/multifd: sync packet_num after all thread are doneWei Yang
Notification from recv thread is not ordered, which means we may be notified by one MultiFDRecvParams but adjust packet_num for another. Move the adjustment after we are sure each recv thread are sync-ed. Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Message-Id: <20190604023540.26532-1-richardw.yang@linux.intel.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2019-07-15cutils: remove one unnecessary pointer operationWei Yang
Since we will not operate on the next address pointed by out, it is not necessary to do addition on it. After removing the operation, the function size reduced 16/18 bytes. Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20190610030852.16039-2-richardw.yang@linux.intel.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2019-07-15migration/xbzrle: update cache and current_data in one placeWei Yang
When we are not in the last_stage, we need to update the cache if page is not the same. Currently this procedure is scattered in two places and mixed with encoding status check. This patch extract this general step out to make the code a little bit easy to read. Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20190610004159.20966-1-richardw.yang@linux.intel.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2019-07-15migration/multifd: call multifd_send_sync_main when sending RAM_SAVE_FLAG_EOSWei Yang
On receiving RAM_SAVE_FLAG_EOS, multifd_recv_sync_main() is called to synchronize receive threads. Current synchronization mechanism is to wait for each channel's sem_sync semaphore. This semaphore is triggered by a packet with MULTIFD_FLAG_SYNC flag. While in current implementation, we don't do multifd_send_sync_main() to send such packet when blk_mig_bulk_active() is true. This will leads to the receive threads won't notify multifd_recv_sync_main() by sem_sync. And multifd_recv_sync_main() will always wait there. [Note]: normal migration test works, while didn't test the blk_mig_bulk_active() case. Since not sure how to produce this situation. Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-Id: <20190612014337.11255-1-richardw.yang@linux.intel.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2019-07-15migration-test: rename parameter to parameter_intJuan Quintela
We would need _str ones on the next patch. Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Wei Yang <richardw.yang@linux.intel.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2019-07-15migration: fix multifd_recv event typoJuan Quintela
It uses num in multifd_send(). Make it coherent. Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Wei Yang <richardw.yang@linux.intel.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2019-07-15target/arm: NS BusFault on vector table fetch escalates to NS HardFaultPeter Maydell
In the M-profile architecture, when we do a vector table fetch and it fails, we need to report a HardFault. Whether this is a Secure HF or a NonSecure HF depends on several things. If AIRCR.BFHFNMINS is 0 then HF is always Secure, because there is no NonSecure HardFault. Otherwise, the answer depends on whether the 'underlying exception' (MemManage, BusFault, SecureFault) targets Secure or NonSecure. (In the pseudocode, this is handled in the Vector() function: the final exc.isSecure is calculated by looking at the exc.isSecure from the exception returned from the memory access, not the isSecure input argument.) We weren't doing this correctly, because we were looking at the target security domain of the exception we were trying to load the vector table entry for. This produces errors of two kinds: * a load from the NS vector table which hits the "NS access to S memory" SecureFault should end up as a Secure HardFault, but we were raising an NS HardFault * a load from the S vector table which causes a BusFault should raise an NS HardFault if BFHFNMINS == 1 (because in that case all BusFaults are NonSecure), but we were raising a Secure HardFault Correct the logic. We also fix a comment error where we claimed that we might be escalating MemManage to HardFault, and forgot about SecureFault. (Vector loads can never hit MPU access faults, because they're always aligned and always use the default address map.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20190705094823.28905-1-peter.maydell@linaro.org
2019-07-15target/arm: Set VFP-related MVFR0 fields for arm926 and arm1026Peter Maydell
The ARMv5 architecture didn't specify detailed per-feature ID registers. Now that we're using the MVFR0 register fields to gate the existence of VFP instructions, we need to set up the correct values in the cpu->isar structure so that we still provide an FPU to the guest. This fixes a regression in the arm926 and arm1026 CPUs, which are the only ones that both have VFP and are ARMv5 or earlier. This regression was introduced by the VFP refactoring, and more specifically by commits 1120827fa182f0e76 and 266bd25c485597c, which accidentally disabled VFP short-vector support and double-precision support on these CPUs. Fixes: 1120827fa182f0e Fixes: 266bd25c485597c Fixes: https://bugs.launchpad.net/qemu/+bug/1836192 Reported-by: Christophe Lyon <christophe.lyon@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Christophe Lyon <christophe.lyon@linaro.org> Message-id: 20190711131241.22231-1-peter.maydell@linaro.org
2019-07-15pl031: Correctly migrate state when using -rtc clock=hostPeter Maydell
The PL031 RTC tracks the difference between the guest RTC and the host RTC using a tick_offset field. For migration, however, we currently always migrate the offset between the guest and the vm_clock, even if the RTC clock is not the same as the vm_clock; this was an attempt to retain migration backwards compatibility. Unfortunately this results in the RTC behaving oddly across a VM state save and restore -- since the VM clock stands still across save-then-restore, regardless of how much real world time has elapsed, the guest RTC ends up out of sync with the host RTC in the restored VM. Fix this by migrating the raw tick_offset. To retain migration compatibility as far as possible, we have a new property migrate-tick-offset; by default this is 'true' and we will migrate the true tick offset in a new subsection; if the incoming data has no subsection we fall back to the old vm_clock-based offset information, so old->new migration compatibility is preserved. For complete new->old migration compatibility, the property is set to 'false' for 4.0 and earlier machine types (this will only affect 'virt-4.0' and below, as none of the other pl031-using machines are versioned). Reported-by: Russell King <rmk@armlinux.org.uk> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-id: 20190709143912.28905-1-peter.maydell@linaro.org
2019-07-15hw/arm/virt: Fix non-secure flash modeDavid Engraf
Using the whole 128 MiB flash in non-secure mode is not working because virt_flash_fdt() expects the same address for secure_sysmem and sysmem. This is not correctly handled by caller because it forwards NULL for secure_sysmem in non-secure flash mode. Fixed by using sysmem when secure_sysmem is NULL. Signed-off-by: David Engraf <david.engraf@sysgo.com> Message-id: 20190712075002.14326-1-david.engraf@sysgo.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-15hw/display/xlnx_dp: Avoid crash when reading empty RX FIFOPhilippe Mathieu-Daudé
In the previous commit we fixed a crash when the guest read a register that pop from an empty FIFO. By auditing the repository, we found another similar use with an easy way to reproduce: $ qemu-system-aarch64 -M xlnx-zcu102 -monitor stdio -S QEMU 4.0.50 monitor - type 'help' for more information (qemu) xp/b 0xfd4a0134 Aborted (core dumped) (gdb) bt #0 0x00007f6936dea57f in raise () at /lib64/libc.so.6 #1 0x00007f6936dd4895 in abort () at /lib64/libc.so.6 #2 0x0000561ad32975ec in xlnx_dp_aux_pop_rx_fifo (s=0x7f692babee70) at hw/display/xlnx_dp.c:431 #3 0x0000561ad3297dc0 in xlnx_dp_read (opaque=0x7f692babee70, offset=77, size=4) at hw/display/xlnx_dp.c:667 #4 0x0000561ad321b896 in memory_region_read_accessor (mr=0x7f692babf620, addr=308, value=0x7ffe05c1db88, size=4, shift=0, mask=4294967295, attrs=...) at memory.c:439 #5 0x0000561ad321bd70 in access_with_adjusted_size (addr=308, value=0x7ffe05c1db88, size=1, access_size_min=4, access_size_max=4, access_fn=0x561ad321b858 <memory_region_read_accessor>, mr=0x7f692babf620, attrs=...) at memory.c:569 #6 0x0000561ad321e9d5 in memory_region_dispatch_read1 (mr=0x7f692babf620, addr=308, pval=0x7ffe05c1db88, size=1, attrs=...) at memory.c:1420 #7 0x0000561ad321ea9d in memory_region_dispatch_read (mr=0x7f692babf620, addr=308, pval=0x7ffe05c1db88, size=1, attrs=...) at memory.c:1447 #8 0x0000561ad31bd742 in flatview_read_continue (fv=0x561ad69c04f0, addr=4249485620, attrs=..., buf=0x7ffe05c1dcf0 "\020\335\301\005\376\177", len=1, addr1=308, l=1, mr=0x7f692babf620) at exec.c:3385 #9 0x0000561ad31bd895 in flatview_read (fv=0x561ad69c04f0, addr=4249485620, attrs=..., buf=0x7ffe05c1dcf0 "\020\335\301\005\376\177", len=1) at exec.c:3423 #10 0x0000561ad31bd90b in address_space_read_full (as=0x561ad5bb3020, addr=4249485620, attrs=..., buf=0x7ffe05c1dcf0 "\020\335\301\005\376\177", len=1) at exec.c:3436 #11 0x0000561ad33b1c42 in address_space_read (len=1, buf=0x7ffe05c1dcf0 "\020\335\301\005\376\177", attrs=..., addr=4249485620, as=0x561ad5bb3020) at include/exec/memory.h:2131 #12 0x0000561ad33b1c42 in memory_dump (mon=0x561ad59c4530, count=1, format=120, wsize=1, addr=4249485620, is_physical=1) at monitor/misc.c:723 #13 0x0000561ad33b1fc1 in hmp_physical_memory_dump (mon=0x561ad59c4530, qdict=0x561ad6c6fd00) at monitor/misc.c:795 #14 0x0000561ad37b4a9f in handle_hmp_command (mon=0x561ad59c4530, cmdline=0x561ad59d0f22 "/b 0x00000000fd4a0134") at monitor/hmp.c:1082 Fix by checking the FIFO is not empty before popping from it. The datasheet is not clear about the reset value of this register, we choose to return '0'. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20190709113715.7761-4-philmd@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-15hw/ssi/mss-spi: Avoid crash when reading empty RX FIFOPhilippe Mathieu-Daudé
Reading the RX_DATA register when the RX_FIFO is empty triggers an abort. This can be easily reproduced: $ qemu-system-arm -M emcraft-sf2 -monitor stdio -S QEMU 4.0.50 monitor - type 'help' for more information (qemu) x 0x40001010 Aborted (core dumped) (gdb) bt #1 0x00007f035874f895 in abort () at /lib64/libc.so.6 #2 0x00005628686591ff in fifo8_pop (fifo=0x56286a9a4c68) at util/fifo8.c:66 #3 0x00005628683e0b8e in fifo32_pop (fifo=0x56286a9a4c68) at include/qemu/fifo32.h:137 #4 0x00005628683e0efb in spi_read (opaque=0x56286a9a4850, addr=4, size=4) at hw/ssi/mss-spi.c:168 #5 0x0000562867f96801 in memory_region_read_accessor (mr=0x56286a9a4b60, addr=16, value=0x7ffeecb0c5c8, size=4, shift=0, mask=4294967295, attrs=...) at memory.c:439 #6 0x0000562867f96cdb in access_with_adjusted_size (addr=16, value=0x7ffeecb0c5c8, size=4, access_size_min=1, access_size_max=4, access_fn=0x562867f967c3 <memory_region_read_accessor>, mr=0x56286a9a4b60, attrs=...) at memory.c:569 #7 0x0000562867f99940 in memory_region_dispatch_read1 (mr=0x56286a9a4b60, addr=16, pval=0x7ffeecb0c5c8, size=4, attrs=...) at memory.c:1420 #8 0x0000562867f99a08 in memory_region_dispatch_read (mr=0x56286a9a4b60, addr=16, pval=0x7ffeecb0c5c8, size=4, attrs=...) at memory.c:1447 #9 0x0000562867f38721 in flatview_read_continue (fv=0x56286aec6360, addr=1073745936, attrs=..., buf=0x7ffeecb0c7c0 "\340ǰ\354\376\177", len=4, addr1=16, l=4, mr=0x56286a9a4b60) at exec.c:3385 #10 0x0000562867f38874 in flatview_read (fv=0x56286aec6360, addr=1073745936, attrs=..., buf=0x7ffeecb0c7c0 "\340ǰ\354\376\177", len=4) at exec.c:3423 #11 0x0000562867f388ea in address_space_read_full (as=0x56286aa3e890, addr=1073745936, attrs=..., buf=0x7ffeecb0c7c0 "\340ǰ\354\376\177", len=4) at exec.c:3436 #12 0x0000562867f389c5 in address_space_rw (as=0x56286aa3e890, addr=1073745936, attrs=..., buf=0x7ffeecb0c7c0 "\340ǰ\354\376\177", len=4, is_write=false) at exec.c:3466 #13 0x0000562867f3bdd7 in cpu_memory_rw_debug (cpu=0x56286aa19d00, addr=1073745936, buf=0x7ffeecb0c7c0 "\340ǰ\354\376\177", len=4, is_write=0) at exec.c:3976 #14 0x000056286811ed51 in memory_dump (mon=0x56286a8c32d0, count=1, format=120, wsize=4, addr=1073745936, is_physical=0) at monitor/misc.c:730 #15 0x000056286811eff1 in hmp_memory_dump (mon=0x56286a8c32d0, qdict=0x56286b15c400) at monitor/misc.c:785 #16 0x00005628684740ee in handle_hmp_command (mon=0x56286a8c32d0, cmdline=0x56286a8caeb2 "0x40001010") at monitor/hmp.c:1082 From the datasheet "Actel SmartFusion Microcontroller Subsystem User's Guide" Rev.1, Table 13-3 "SPI Register Summary", this register has a reset value of 0. Check the FIFO is not empty before accessing it, else log an error message. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20190709113715.7761-3-philmd@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-15hw/ssi/xilinx_spips: Avoid out-of-bound access to lqspi_buf[]Philippe Mathieu-Daudé
Both lqspi_read() and lqspi_load_cache() expect a 32-bit aligned address. >From UG1085 datasheet [*] chapter on 'Quad-SPI Controller': Transfer Size Limitations Because of the 32-bit wide TX, RX, and generic FIFO, all APB/AXI transfers must be an integer multiple of 4-bytes. Shorter transfers are not possible. Set MemoryRegionOps.impl values to force 32-bit accesses, this way we are sure we do not access the lqspi_buf[] array out of bound. [*] https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf Reviewed-by: Francisco Iglesias <frasse.iglesias@gmail.com> Tested-by: Francisco Iglesias <frasse.iglesias@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-15hw/ssi/xilinx_spips: Avoid AXI writes to the LQSPI linear memoryPhilippe Mathieu-Daudé
Lei Sun found while auditing the code that a CPU write would trigger a NULL pointer dereference. >From UG1085 datasheet [*] AXI writes in this region are ignored and generates an AXI Slave Error (SLVERR). Fix by implementing the write_with_attrs() handler. Return MEMTX_ERROR when the region is accessed (this error maps to an AXI slave error). [*] https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf Reported-by: Lei Sun <slei.casper@gmail.com> Reviewed-by: Francisco Iglesias <frasse.iglesias@gmail.com> Tested-by: Francisco Iglesias <frasse.iglesias@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-15hw/ssi/xilinx_spips: Convert lqspi_read() to read_with_attrsPhilippe Mathieu-Daudé
In the next commit we will implement the write_with_attrs() handler. To avoid using different APIs, convert the read() handler first. Reviewed-by: Francisco Iglesias <frasse.iglesias@gmail.com> Tested-by: Francisco Iglesias <frasse.iglesias@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-15target/arm: report ARMv8-A FP support for AArch32 -cpu maxAlex Bennée
When we converted to using feature bits in 602f6e42cfbf we missed out the fact (dp && arm_dc_feature(s, ARM_FEATURE_V8)) was supported for -cpu max configurations. This caused a regression in the GCC test suite. Fix this by setting the appropriate bits in mvfr1.FPHP to report ARMv8-A with FP support (but not ARMv8.2-FP16). Fixes: https://bugs.launchpad.net/qemu/+bug/1836078 Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20190711103737.10017-1-alex.bennee@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-15Merge remote-tracking branch 'remotes/dgilbert/tags/pull-hmp-20190715' into ↵Peter Maydell
staging HMP pull 2019-07-15 Just Christophe's build fix # gpg: Signature made Mon 15 Jul 2019 12:13:54 BST # gpg: using RSA key 45F5C71B4A0CB7FB977A9FA90516331EBC5BFDE7 # gpg: Good signature from "Dr. David Alan Gilbert (RH2) <dgilbert@redhat.com>" [full] # Primary key fingerprint: 45F5 C71B 4A0C B7FB 977A 9FA9 0516 331E BC5B FDE7 * remotes/dgilbert/tags/pull-hmp-20190715: Fix build error when VNC is configured out Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-15Fix build error when VNC is configured outChristophe de Dinechin
In hmp_change(), the variable hmp_mon is only used by code under #ifdef CONFIG_VNC. This results in a build error when VNC is configured out with the default of treating warnings as errors: monitor/hmp-cmds.c: In function ‘hmp_change’: monitor/hmp-cmds.c:1946:17: error: unused variable ‘hmp_mon’ [-Werror=unused-variable] 1946 | MonitorHMP *hmp_mon = container_of(mon, MonitorHMP, common); | ^~~~~~~ Signed-off-by: Christophe de Dinechin <dinechin@redhat.com> Message-Id: <20190625123905.25434-1-dinechin@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2019-07-15util: merge main-loop.c and iohandler.cPaolo Bonzini
main-loop.c has a dependency on iohandler.c, and everything breaks if that dependency is instead satisfied by stubs/iohandler.c. Just put everything in the same file to avoid strange dependencies on the order of files in util-obj-y. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <1562952875-53702-1-git-send-email-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-07-15Fix broken build with WHPX enabledStefan Weil
Signed-off-by: Stefan Weil <sw@weilnetz.de> Message-Id: <20190712132611.20411-1-sw@weilnetz.de> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-07-15memory: unref the memory region in simplify flatviewKing Wang
The memory region reference is increased when insert a range into flatview range array, then decreased by destroy flatview. If some flat range merged by flatview_simplify, the memory region reference can not be decreased by destroy flatview any more. In this case, start virtual machine by the command line: qemu-system-x86_64 -name guest=ubuntu,debug-threads=on -machine pc,accel=kvm,usb=off,dump-guest-core=off -cpu host -m 16384 -realtime mlock=off -smp 8,sockets=2,cores=4,threads=1 -object memory-backend-file,id=ram-node0,prealloc=yes,mem-path=/dev/hugepages,share=yes,size=8589934592 -numa node,nodeid=0,cpus=0-3,memdev=ram-node0 -object memory-backend-file,id=ram-node1,prealloc=yes,mem-path=/dev/hugepages,share=yes,size=8589934592 -numa node,nodeid=1,cpus=4-7,memdev=ram-node1 -no-user-config -nodefaults -rtc base=utc -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -drive file=ubuntu.qcow2,format=qcow2,if=none,id=drive-virtio-disk0,cache=none,aio=native -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0,bus=usb.0,port=1 -vnc 0.0.0.0:0 -device VGA,id=video0,vgamem_mb=16,bus=pci.0,addr=0x5 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -msg timestamp=on And run the script in guest OS: while true do setpci -s 00:06.0 04.b=03 setpci -s 00:06.0 04.b=07 done I found the reference of node0 HostMemoryBackendFile is a big one. (gdb) p numa_info[0]->node_memdev->parent.ref $6 = 1636278 (gdb) Signed-off-by: King Wang<king.wang@huawei.com> Message-Id: <20190712065241.11784-1-king.wang@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-07-15hw/i386: turn off vmport if CONFIG_VMPORT is disabledJulio Montes
vmport device is not included when CONFIG_VMPORT is disabled, hence QEMU fails with the following error: `Unknown device 'vmport' for bus 'ISA': unknown.` v2: imply VMPORT (Paolo Bonzini ) Signed-off-by: Julio Montes <julio.montes@intel.com> Message-Id: <20190712160257.18270-1-julio.montes@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-07-15rdmacm-mux: fix strcpy string warningMarc-André Lureau
../contrib/rdmacm-mux/main.c: In function ‘parse_args’: ../contrib/rdmacm-mux/main.c:118:13: error: ‘strncpy’ specified bound 3835 equals destination size [-Werror=stringop-truncation] 118 | strncpy(unix_socket_path, optarg, SOCKET_PATH_MAX); Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20190712165154.11504-1-marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-07-15build-sys: remove slirp cflags from main-loop.oMarc-André Lureau
Left over from c2d63650d962612cfa1b21302782d4cd12142c74. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20190712172743.17632-1-marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-07-15iscsi: base all handling of check condition on scsi_sense_to_errnoPaolo Bonzini
Now that scsi-disk is not using scsi_sense_to_errno to separate guest-recoverable sense codes, we can modify it to simplify iscsi's own sense handling. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-07-15iscsi: fix busy/timeout/task set fullPaolo Bonzini
In this case, do_retry was set without calling aio_co_wake, thus never waking up the coroutine. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-07-15scsi: add guest-recoverable ZBC errorsPaolo Bonzini
When running basic operations on zoned storage from the guest via scsi-block, the following ASCs are reported for write or read commands due to unexpected zone status or write pointer status: 21h 04h: UNALIGNED WRITE COMMAND 21h 05h: WRITE BOUNDARY VIOLATION 21h 06h: ATTEMPT TO READ INVALID DATA 55h 0Eh: INSUFFICIENT ZONE RESOURCES Reporting these ASCs to the guest, the user applications can handle them to manage zone/write pointer status, or help the user application developers to understand the failure reason and fix bugs. Reported-by: Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-07-15scsi: explicitly list guest-recoverable sense codesPaolo Bonzini
It's not really possible to fit all sense codes into errno codes, especially in such a way that sense codes can be properly categorized as either guest-recoverable or host-handled. Create a new function that checks for guest recoverable sense, then scsi_sense_buf_to_errno only needs to be called for host handled sense codes. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-07-15scsi-disk: pass sense correctly for guest-recoverable errorsShinichiro Kawasaki
When an error was passed down to the guest because it was recoverable, the sense length was not copied from the SG_IO data. As a result, the guest saw the CHECK CONDITION status but not the sense data. Signed-off-by: Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-07-15Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20190714' into stagingPeter Maydell
Fixes for 3 tcg bugs # gpg: Signature made Sun 14 Jul 2019 12:11:01 BST # gpg: using RSA key 7A481E78868B4DB6A85A05C064DF38E8AF7E215F # gpg: issuer "richard.henderson@linaro.org" # gpg: Good signature from "Richard Henderson <richard.henderson@linaro.org>" [full] # Primary key fingerprint: 7A48 1E78 868B 4DB6 A85A 05C0 64DF 38E8 AF7E 215F * remotes/rth/tags/pull-tcg-20190714: tcg: Release mmap_lock on translation fault tcg: Remove duplicate #if !defined(CODE_ACCESS) tcg: Remove cpu_ld*_code_ra tcg: Introduce set/clear_helper_retaddr include/qemu/atomic.h: Add signal_barrier tcg/aarch64: Fix output of extract2 opcodes tcg: Fix constant folding of INDEX_op_extract2_i32 Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-14tcg: Release mmap_lock on translation faultRichard Henderson
Turn helper_retaddr into a multi-state flag that may now also indicate when we're performing a read on behalf of the translator. In this case, release the mmap_lock before the longjmp back to the main cpu loop, and thereby avoid a failing assert therein. Fixes: https://bugs.launchpad.net/qemu/+bug/1832353 Tested-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2019-07-14tcg: Remove duplicate #if !defined(CODE_ACCESS)Richard Henderson
This code block is already surrounded by #ifndef CODE_ACCESS. Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2019-07-14tcg: Remove cpu_ld*_code_raRichard Henderson
These functions are not used, and are not usable in the context of code generation, because we never have a helper return address to pass in to them. Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2019-07-14tcg: Introduce set/clear_helper_retaddrRichard Henderson
At present we have a potential error in that helper_retaddr contains data for handle_cpu_signal, but we have not ensured that those stores will be scheduled properly before the operation that may fault. It might be that these races are not in practice observable, due to our use of -fno-strict-aliasing, but better safe than sorry. Adjust all of the setters of helper_retaddr. Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2019-07-14include/qemu/atomic.h: Add signal_barrierRichard Henderson
We have some potential race conditions vs our user-exec signal handler that will be solved with this barrier. Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2019-07-14tcg/aarch64: Fix output of extract2 opcodesRichard Henderson
This patch fixes two problems: (1) The inputs to the EXTR insn were reversed, (2) The input constraints use rZ, which means that we need to use the REG0 macro in order to supply XZR for a constant 0 input. Fixes: 464c2969d5d Reported-by: Peter Maydell <peter.maydell@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2019-07-14tcg: Fix constant folding of INDEX_op_extract2_i32Richard Henderson
On a 64-bit host, discard any replications of the 32-bit sign bit when performing the shift and merge. Fixes: https://bugs.launchpad.net/bugs/1834496 Tested-by: Christophe Lyon <christophe.lyon@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2019-07-12Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into stagingPeter Maydell
virtio, pc, pci: fixes, cleanups, tests A bunch of fixes all over the place. ACPI tests will now run on more systems: might introduce new failure reports but that's for the best, isn't it? Signed-off-by: Michael S. Tsirkin <mst@redhat.com> # gpg: Signature made Fri 12 Jul 2019 15:57:40 BST # gpg: using RSA key 281F0DB8D28D5469 # gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [full] # gpg: aka "Michael S. Tsirkin <mst@redhat.com>" [full] # 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: virtio pmem: remove transitional names virtio pmem: remove memdev null check virtio pmem: fix wrong mem region condition tests: acpi: do not skip tests when IASL is not installed tests: acpi: do not require IASL for dumping AML blobs virtio-balloon: fix QEMU 4.0 config size migration incompatibility pcie: consistent names for function args xio3130_downstream: typo fix Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-12virtio pmem: remove transitional namesPankaj Gupta
Remove transitional & non transitional names for virtio pmem. Only virtio 1.0 and up is supported. Signed-off-by: Pankaj Gupta <pagupta@redhat.com> Message-Id: <20190712073554.21918-4-pagupta@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com>
2019-07-12virtio pmem: remove memdev null checkPankaj Gupta
Coverity reports that when we're assigning vi->size we handle the "pmem->memdev is NULL" case; but we then pass it into object_get_canonical_path(), which unconditionally dereferences it and will crash if it is NULL. If this pointer can be NULL then we need to do something else here. We are removing 'pmem->memdev' null check here as memdev will never be null in this function. Signed-off-by: Pankaj Gupta <pagupta@redhat.com> Message-Id: <20190712073554.21918-3-pagupta@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com>
2019-07-12virtio pmem: fix wrong mem region conditionPankaj Gupta
Coverity reported memory region returns zero for non-null value. This is because of wrong arguments to '?:' , fixing this. Signed-off-by: Pankaj Gupta <pagupta@redhat.com> Message-Id: <20190712073554.21918-2-pagupta@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com>
2019-07-12tests: acpi: do not skip tests when IASL is not installedIgor Mammedov
tests do binary comparision so we can check tables without IASL. Move IASL condition right before decompilation step and skip it if IASL is not installed. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190708092410.11167-3-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-15 06:24:04 +0000