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-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-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>
2019-07-12tests: acpi: do not require IASL for dumping AML blobsIgor Mammedov
IASL isn't needed when dumping ACPI tables from guest for rebuild purposes. So move this part out from IASL branch. Makes rebuild-expected-aml.sh work without IASL installed on host. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-Id: <20190708092410.11167-2-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-07-12virtio-balloon: fix QEMU 4.0 config size migration incompatibilityStefan Hajnoczi
The virtio-balloon config size changed in QEMU 4.0 even for existing machine types. Migration from QEMU 3.1 to 4.0 can fail in some circumstances with the following error: qemu-system-x86_64: get_pci_config_device: Bad config data: i=0x10 read: a1 device: 1 cmask: ff wmask: c0 w1cmask:0 This happens because the virtio-balloon config size affects the VIRTIO Legacy I/O Memory PCI BAR size. Introduce a qdev property called "qemu-4-0-config-size" and enable it only for the QEMU 4.0 machine types. This way <4.0 machine types use the old size, 4.0 uses the larger size, and >4.0 machine types use the appropriate size depending on enabled virtio-balloon features. Live migration to and from old QEMUs to QEMU 4.1 works again as long as a versioned machine type is specified (do not use just "pc"!). Originally-by: Wolfgang Bumiller <w.bumiller@proxmox.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20190710141440.27635-1-stefanha@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Tested-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Tested-by: Wolfgang Bumiller <w.bumiller@proxmox.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-07-12pcie: consistent names for function argsMichael S. Tsirkin
The function declarations for pci_cap_slot_get and pci_cap_slot_write_config call the argument "slot_ctl", but the function definitions and all the call sites drop the 'o' and call it "slt_ctl". Let's be consistent. Reported-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
2019-07-12xio3130_downstream: typo fixMichael S. Tsirkin
slt ctl/status are passed in incorrect order. Fix this up. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reported-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
2019-07-12Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into stagingPeter Maydell
Block layer patches: - file-posix: Fix max transfer length for non-SCSI-passthrough - iotests: Fix 082 reference output # gpg: Signature made Fri 12 Jul 2019 14:49:14 BST # gpg: using RSA key 7F09B272C88F2FD6 # gpg: Good signature from "Kevin Wolf <kwolf@redhat.com>" [full] # Primary key fingerprint: DC3D EB15 9A9A F95D 3D74 56FE 7F09 B272 C88F 2FD6 * remotes/kevin/tags/for-upstream: file-posix: Use max transfer length/segment count only for SCSI passthrough iotests: Update 082 expected output Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-12file-posix: Use max transfer length/segment count only for SCSI passthroughMaxim Levitsky
Regular kernel block devices (/dev/sda*, /dev/nvme*, etc) don't have max segment size/max segment count hardware requirements exposed to the userspace, but rather the kernel block layer takes care to split the incoming requests that violate these requirements. Allowing the kernel to do the splitting allows qemu to avoid various overheads that arise otherwise from this. This is especially visible in nbd server, exposing as a raw file, a mostly empty qcow2 image over the net. In this case most of the reads by the remote user won't even hit the underlying kernel block device, and therefore most of the overhead will be in the nbd traffic which increases significantly with lower max transfer size. In addition to that even for local block device access the peformance improves a bit due to less traffic between qemu and the kernel when large transfer sizes are used (e.g for image conversion) More info can be found at: https://bugzilla.redhat.com/show_bug.cgi?id=1647104 Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Pankaj Gupta <pagupta@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2019-07-12iotests: Update 082 expected outputEric Blake
A recent tweak to the '-o help' output for qemu-img needs to be reflected into the iotests expected outputs. Fixes: f7077c98 Reported-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2019-07-12Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-4.1-20190712' ↵Peter Maydell
into staging ppc patch queue for 2019-07-12 First 4.1 hard freeze pull request. Not much here, just a bug fix for the XICS interrupt controller and a SLOF firmware update to fix a bug with IP discovery when there are multiple NICs. # gpg: Signature made Fri 12 Jul 2019 06:51:24 BST # gpg: using RSA key 75F46586AE61A66CC44E87DC6C38CACA20D9B392 # gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>" [full] # gpg: aka "David Gibson (Red Hat) <dgibson@redhat.com>" [full] # gpg: aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>" [full] # gpg: aka "David Gibson (kernel.org) <dwg@kernel.org>" [unknown] # Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392 * remotes/dgibson/tags/ppc-for-4.1-20190712: xics/kvm: Always set the MASKED bit if interrupt is masked pseries: Update SLOF firmware image Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-12xics/kvm: Always set the MASKED bit if interrupt is maskedGreg Kurz
The ics_set_kvm_state_one() function is called either to restore the state of an interrupt source during migration or to set the interrupt source to a default state during reset. Since always, ie. 2013, the code only sets the MASKED bit if the 'current priority' and the 'saved priority' are different. This is likely true when restoring an interrupt that had been previously masked with the ibm,int-off RTAS call. However this is always false in the case of reset since both 'current priority' and 'saved priority' are equal to 0xff, and the MASKED bit is never set. The legacy KVM XICS device gets away with that because it ends updating its internal structure the same way, whether the MASKED bit is set or the priority is 0xff. The XICS-on-XIVE device for POWER9 is different. It sticks to the KVM documentation [1] and _really_ relies on the MASKED bit to correctly set. If not, it will configure the interrupt source in the XIVE HW, even though the guest hasn't configured the interrupt yet. This disturbs the complex logic implemented in XICS-on-XIVE and may result in the loss of subsequent queued events. Always set the MASKED bit if interrupt is masked as expected by the KVM XICS-on-XIVE device. This has no impact on the legacy KVM XICS. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/virtual/kvm/devices/xics.txt Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <156217454083.559957.7359208229523652842.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-07-12pseries: Update SLOF firmware imageAlexey Kardashevskiy
This only has a fix for ipv4-after-ipv6 booting problem. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-07-11Merge remote-tracking branch 'remotes/jnsnow/tags/bitmaps-pull-request' into ↵Peter Maydell
staging Pull request # gpg: Signature made Wed 10 Jul 2019 20:21:58 BST # gpg: using RSA key F9B7ABDBBCACDF95BE76CBD07DEF8106AAFC390E # gpg: Good signature from "John Snow (John Huston) <jsnow@redhat.com>" [full] # Primary key fingerprint: FAEB 9711 A12C F475 812F 18F2 88A9 064D 1835 61EB # Subkey fingerprint: F9B7 ABDB BCAC DF95 BE76 CBD0 7DEF 8106 AAFC 390E * remotes/jnsnow/tags/bitmaps-pull-request: docs/bitmaps: use QMP lexer instead of json sphinx: add qmp_lexer docs/interop/bitmaps.rst: Fix typos Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-11Merge remote-tracking branch ↵Peter Maydell
'remotes/stsquad/tags/pull-testing-and-gdbstub-100719-1' into staging Testing and gdbstub fixes: - fix diff-out pass in check-tcg - ensure generation of fprem reference - fix gdb set_reg fallback # gpg: Signature made Wed 10 Jul 2019 11:24:28 BST # gpg: using RSA key 6685AE99E75167BCAFC8DF35FBD0DB095A9E2A44 # gpg: Good signature from "Alex Bennée (Master Work Key) <alex.bennee@linaro.org>" [full] # Primary key fingerprint: 6685 AE99 E751 67BC AFC8 DF35 FBD0 DB09 5A9E 2A44 * remotes/stsquad/tags/pull-testing-and-gdbstub-100719-1: gdbstub: revert to previous set_reg behaviour gdbstub: add some notes to the header comment tests/tcg: fix diff-out pass to properly report failure tests/tcg: fix up test-i386-fprem.ref generation Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-10docs/bitmaps: use QMP lexer instead of jsonJohn Snow
The annotated style json we use in QMP documentation is not strict json and depending on the version of Sphinx (2.0+) or Pygments installed, might cause the build to fail. Use the new QMP lexer. Further, some versions of Sphinx can not apply custom lexers to "code" directives and require the use of "code-block" directives instead, so make that change at this time as well. Tested under: - Sphinx 1.3.6 and Pygments 2.4 - Sphinx 1.7.6 and Pygments 2.2 (Fedora 29 packages) - Sphinx 2.0.1 and Pygments 2.4 - Sphinx 3.0.0+/f396b3a783 and Pygments 2.4 (From Sphinx git c4f44bdd) Reported-by: Aarushi Mehta <mehta.aaru20@gmail.com> Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Message-id: 20190603214653.29369-4-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2019-07-10sphinx: add qmp_lexerJohn Snow
Sphinx, through Pygments, does not like annotated json examples very much. In some versions of Sphinx (1.7), it will render the non-json portions of code blocks in red, but in newer versions (2.0) it will throw an exception and not highlight the block at all. Though we can suppress this warning, it doesn't bring back highlighting on non-strict json blocks. We can alleviate this by creating a custom lexer for QMP examples that allows us to properly highlight these examples in a robust way, keeping our directionality and elision notations. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: John Snow <jsnow@redhat.com> Reported-by: Aarushi Mehta <mehta.aaru20@gmail.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20190603214653.29369-3-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2019-07-10docs/interop/bitmaps.rst: Fix typosJohn Snow
Pygments and Sphinx get pickier all the time; Sphinx 2.1+ now catches these errors. Signed-off-by: John Snow <jsnow@redhat.com> Reported-by: Aarushi Mehta <mehta.aaru20@gmail.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-id: 20190603214653.29369-2-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2019-07-10gdbstub: revert to previous set_reg behaviourAlex Bennée
The refactoring of handle_set_reg missed the fact we previously had responded with an empty packet when we were not using XML based protocols. This broke the fallback behaviour for architectures that don't have registers defined in QEMU's gdb-xml directory. Revert to the previous behaviour and clean up the commentary for what is going on. Fixes: 62b3320bddd Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Cc: Jon Doron <arilou@gmail.com>
2019-07-10gdbstub: add some notes to the header commentAlex Bennée
Add a link to the remote protocol spec and an SPDX tag. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-07-10tests/tcg: fix diff-out pass to properly report failureAlex Bennée
A side effect of piping the output to head is squash the exit status of the diff command. Fix this by only doing the pipe if the diff failed and then ensuring the status is non-zero. Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
2019-07-10tests/tcg: fix up test-i386-fprem.ref generationAlex Bennée
We never shipped the reference data in the source tree because it's quite big (64M). As a result the only option is to generate it locally. Although we have a rule to generate the reference file we missed the dependency and location changes, probably because it's only run for SLOW test runs. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2019-07-09Update version for v4.1.0-rc0 releasev4.1.0-rc0Peter Maydell
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-09Merge remote-tracking branch ↵Peter Maydell
'remotes/philmd-gitlab/tags/pflash-next-20190709' into staging Restore 32-bit I/O accesses on AMD flashes (precautionary revert). # gpg: Signature made Tue 09 Jul 2019 16:18:10 BST # gpg: using RSA key E3E32C2CDEADC0DE # gpg: Good signature from "Philippe Mathieu-Daudé (F4BUG) <f4bug@amsat.org>" [full] # Primary key fingerprint: FAAB E75E 1291 7221 DCFD 6BB2 E3E3 2C2C DEAD C0DE * remotes/philmd-gitlab/tags/pflash-next-20190709: Revert "hw/block/pflash_cfi02: Reduce I/O accesses to 16-bit" Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
generated by cgit v1.2.3 (git 2.26.2) at 2024-12-26 15:34:40 +0000