- 01 7月, 2017 3 次提交
-
-
由 Emilio G. Cota 提交于
Some code paths can lead to atomic accesses racing with memset() on cpu->tb_jmp_cache, which can result in torn reads/writes and is undefined behaviour in C11. These torn accesses are unlikely to show up as bugs, but from code inspection they seem possible. For example, tb_phys_invalidate does: /* remove the TB from the hash list */ h = tb_jmp_cache_hash_func(tb->pc); CPU_FOREACH(cpu) { if (atomic_read(&cpu->tb_jmp_cache[h]) == tb) { atomic_set(&cpu->tb_jmp_cache[h], NULL); } } Here atomic_set might race with a concurrent memset (such as the ones scheduled via "unsafe" async work, e.g. tlb_flush_page) and therefore we might end up with a torn pointer (or who knows what, because we are under undefined behaviour). This patch converts parallel accesses to cpu->tb_jmp_cache to use atomic primitives, thereby bringing these accesses back to defined behaviour. The price to pay is to potentially execute more instructions when clearing cpu->tb_jmp_cache, but given how infrequently they happen and the small size of the cache, the performance impact I have measured is within noise range when booting debian-arm. Note that under "safe async" work (e.g. do_tb_flush) we could use memset because no other vcpus are running. However I'm keeping these accesses atomic as well to keep things simple and to avoid confusing analysis tools such as ThreadSanitizer. Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NRichard Henderson <rth@twiddle.net> Signed-off-by: NEmilio G. Cota <cota@braap.org> Message-Id: <1497486973-25845-1-git-send-email-cota@braap.org> Signed-off-by: NRichard Henderson <rth@twiddle.net>
-
由 Emilio G. Cota 提交于
We are relying on cpu_env being defined as a global, yet most targets (i.e. all but arm/a64) have it defined as a local variable. Luckily all of them use the same "cpu_env" name, but really compilation shouldn't break if the name of that local variable changed. Fix it by using tcg_ctx.tcg_env, which all targets set in their translate_init function. This change also helps paving the way for the upcoming "translation loop common to all targets" work. Reviewed-by: NRichard Henderson <rth@twiddle.net> Signed-off-by: NEmilio G. Cota <cota@braap.org> Message-Id: <1497639397-19453-3-git-send-email-cota@braap.org> Signed-off-by: NRichard Henderson <rth@twiddle.net>
-
由 Emilio G. Cota 提交于
Reviewed-by: NRichard Henderson <rth@twiddle.net> Signed-off-by: NEmilio G. Cota <cota@braap.org> Message-Id: <1497639397-19453-2-git-send-email-cota@braap.org> Signed-off-by: NRichard Henderson <rth@twiddle.net>
-
- 30 6月, 2017 37 次提交
-
-
由 Peter Maydell 提交于
# gpg: Signature made Fri 30 Jun 2017 15:08:45 BST # gpg: using RSA key 0xCA35624C6A9171C6 # gpg: Good signature from "Fam Zheng <famz@redhat.com>" # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 5003 7CB7 9706 0F76 F021 AD56 CA35 624C 6A91 71C6 * remotes/famz/tags/block-pull-request: block: Exploit BDRV_BLOCK_EOF for larger zero blocks block: Add BDRV_BLOCK_EOF to bdrv_get_block_status() Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Peter Maydell 提交于
# gpg: Signature made Fri 30 Jun 2017 13:30:44 BST # gpg: using RSA key 0xF30C38BD3F2FBE3C # gpg: Good signature from "Laurent Vivier <lvivier@redhat.com>" # gpg: aka "Laurent Vivier <laurent@vivier.eu>" # gpg: aka "Laurent Vivier (Red Hat) <lvivier@redhat.com>" # Primary key fingerprint: CD2F 75DD C8E3 A4DC 2E4F 5173 F30C 38BD 3F2F BE3C * remotes/vivier/tags/m68k-for-2.10-pull-request: target/m68k: add fmovem target/m68k: add explicit single and double precision operations (part 2) target/m68k: add fsglmul and fsgldiv softfloat: define floatx80_round() target/m68k: add explicit single and double precision operations target/m68k: add fmovecr target/m68k: add fscc. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Eric Blake 提交于
When we have a BDS with unallocated clusters, but asking the status of its underlying bs->file or backing layer encounters an end-of-file condition, we know that the rest of the unallocated area will read as zeroes. However, pre-patch, this required two separate calls to bdrv_get_block_status(), as the first call stops at the point where the underlying file ends. Thanks to BDRV_BLOCK_EOF, we can now widen the results of the primary status if the secondary status already includes BDRV_BLOCK_ZERO. In turn, this fixes a TODO mentioned in iotest 154, where we can now see that all sectors in a partial cluster at the end of a file read as zero when coupling the shorter backing file's status along with our knowledge that the remaining sectors came from an unallocated cluster. Also, note that the loop in bdrv_co_get_block_status_above() had an inefficent exit: in cases where the active layer sets BDRV_BLOCK_ZERO but does NOT set BDRV_BLOCK_ALLOCATED (namely, where we know we read zeroes merely because our unallocated clusters lie beyond the backing file's shorter length), we still ended up probing the backing layer even though we already had a good answer. Signed-off-by: NEric Blake <eblake@redhat.com> Message-Id: <20170505021500.19315-3-eblake@redhat.com> Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com> Signed-off-by: NFam Zheng <famz@redhat.com>
-
由 Eric Blake 提交于
Just as the block layer already sets BDRV_BLOCK_ALLOCATED as a shortcut for subsequent operations, there are also some optimizations that are made easier if we can quickly tell that *pnum will advance us to the end of a file, via a new BDRV_BLOCK_EOF which gets set by the block layer. This just plumbs up the new bit; subsequent patches will make use of it. Signed-off-by: NEric Blake <eblake@redhat.com> Message-Id: <20170505021500.19315-2-eblake@redhat.com> Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com> Signed-off-by: NFam Zheng <famz@redhat.com>
-
由 Peter Maydell 提交于
# gpg: Signature made Fri 30 Jun 2017 12:46:17 BST # gpg: using RSA key 0x9CA4ABB381AB73C8 # gpg: Good signature from "Stefan Hajnoczi <stefanha@redhat.com>" # gpg: aka "Stefan Hajnoczi <stefanha@gmail.com>" # Primary key fingerprint: 8695 A8BF D3F9 7CDA AC35 775A 9CA4 ABB3 81AB 73C8 * remotes/stefanha/tags/block-pull-request: virtio-pci: use ioeventfd even when KVM is disabled tests: fix virtio-net-test ISR dependence tests: fix virtio-blk-test ISR dependence tests: fix virtio-scsi-test ISR dependence libqos: add virtio used ring support libqos: fix typo in virtio.h QVirtQueue->used comment virtio-blk: trace vdev so devices can be distinguished Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Peter Maydell 提交于
ppc patch queue 2017-06-30 * More DRC cleanups, these now actually fix a few bugs * Properly implements the openpic timers (they now count and generate interrupts) * Fixes for XICS migration * Fixes for migration of POWER9 RPT guests * The last of the compatibility mode rework # gpg: Signature made Fri 30 Jun 2017 10:52:25 BST # gpg: using RSA key 0x6C38CACA20D9B392 # gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>" # gpg: aka "David Gibson (Red Hat) <dgibson@redhat.com>" # gpg: aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>" # gpg: aka "David Gibson (kernel.org) <dwg@kernel.org>" # Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392 * remotes/dgibson/tags/ppc-for-2.10-20170630: (21 commits) spapr: Clean up DRC set_isolation_state() path spapr: Clean up DRC set_allocation_state path spapr: Make DRC reset force DRC into known state spapr: Split DRC release from DRC detach spapr: Eliminate DRC 'signalled' state variable spapr: Start hotplugged PCI devices in ISOLATED state target-ppc: Enable open-pic timers to count and generate interrupts hw/ppc/spapr.c: consecutive 'spapr->patb_entry = 0' statements spapr: prevent QEMU crash when CPU realization fails target/ppc: Proper cleanup when ppc_cpu_realizefn fails spapr: fix migration of ICPState objects from/to older QEMU xics: directly register ICPState objects to vmstate target/ppc: Fix return value in tcg radix mmu fault handler target/ppc/excp_helper: Take BQL before calling cpu_interrupt() spapr: Fix migration of Radix guests spapr: Add a "no HPT" encoding to HTAB migration stream ppc: Rework CPU compatibility testing across migration pseries: Reset CPU compatibility mode pseries: Move CPU compatibility property to machine qapi: add explicit null to string input and output visitors ... Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Stefan Hajnoczi 提交于
Old kvm.ko versions only supported a tiny number of ioeventfds so virtio-pci avoids ioeventfds when kvm_has_many_ioeventfds() returns 0. Do not check kvm_has_many_ioeventfds() when KVM is disabled since it always returns 0. Since commit 8c56c1a5 ("memory: emulate ioeventfd") it has been possible to use ioeventfds in qtest or TCG mode. This patch makes -device virtio-blk-pci,iothread=iothread0 work even when KVM is disabled. I have tested that virtio-blk-pci works under TCG both with and without iothread. This patch fixes qemu-iotests 068, which was accidentally merged early despite the dependency on ioeventfd. Cc: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Reviewed-by: NFam Zheng <famz@redhat.com> Tested-by: NEric Blake <eblake@redhat.com> Tested-by: NKevin Wolf <kwolf@redhat.com> Message-id: 20170628184724.21378-7-stefanha@redhat.com Message-id: 20170615163813.7255-2-stefanha@redhat.com Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
-
由 Stefan Hajnoczi 提交于
Use the new used ring APIs instead of assuming ISR being set means the request has completed. Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Reviewed-by: NFam Zheng <famz@redhat.com> Tested-by: NEric Blake <eblake@redhat.com> Tested-by: NKevin Wolf <kwolf@redhat.com> Message-id: 20170628184724.21378-6-stefanha@redhat.com Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
-
由 Stefan Hajnoczi 提交于
Use the new used ring APIs instead of assuming ISR being set means the request has completed. Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Reviewed-by: NFam Zheng <famz@redhat.com> Tested-by: NEric Blake <eblake@redhat.com> Tested-by: NKevin Wolf <kwolf@redhat.com> Message-id: 20170628184724.21378-5-stefanha@redhat.com Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
-
由 Stefan Hajnoczi 提交于
Use the new used ring APIs instead of assuming ISR being set means the request has completed. Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Reviewed-by: NFam Zheng <famz@redhat.com> Tested-by: NEric Blake <eblake@redhat.com> Tested-by: NKevin Wolf <kwolf@redhat.com> Message-id: 20170628184724.21378-4-stefanha@redhat.com Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
-
由 Stefan Hajnoczi 提交于
Existing tests do not touch the virtqueue used ring. Instead they poll the virtqueue ISR register and peek into their request's device-specific status field. It turns out that the virtqueue ISR register can be set to 1 more than once for a single notification (see commit 83d768b5 "virtio: set ISR on dataplane notifications"). This causes problems for tests that assume a 1:1 correspondence between the ISR being 1 and request completion. Peeking at device-specific status fields is also problematic if the device has no field that can be abused for EINPROGRESS polling semantics. This is the case if all the field's values may be set by the device; there's no magic constant left for polling. It's time to process the used ring for completed requests, just like a real virtio guest driver. This patch adds the necessary APIs. Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Reviewed-by: NFam Zheng <famz@redhat.com> Tested-by: NEric Blake <eblake@redhat.com> Tested-by: NKevin Wolf <kwolf@redhat.com> Message-id: 20170628184724.21378-3-stefanha@redhat.com Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
-
由 Stefan Hajnoczi 提交于
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Reviewed-by: NFam Zheng <famz@redhat.com> Tested-by: NEric Blake <eblake@redhat.com> Tested-by: NKevin Wolf <kwolf@redhat.com> Message-id: 20170628184724.21378-2-stefanha@redhat.com Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
-
由 David Gibson 提交于
There are substantial differences in the various paths through set_isolation_state(), both for setting to ISOLATED versus UNISOLATED state and for logical versus physical DRCs. So, split the set_isolation_state() method into isolate() and unisolate() methods, and give it different implementations for the two DRC types. Factor some minimal common checks, including for valid indicator values (which we weren't previously checking) into rtas_set_isolation_state(). Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 David Gibson 提交于
The allocation-state indicator should only actually be implemented for "logical" DRCs, not physical ones. Factor a check for this, and also for valid indicator state values into rtas_set_allocation_state(). Because they don't exist for physical DRCs, there's no reason that we'd ever want more than one method implementation, so it can just be a plain function. In addition, the setting to USABLE and setting to UNUSABLE paths in set_allocation_state() don't actually have much in common. So, split the method separate functions for each parameter value (drc_set_usable() and drc_set_unusable()). Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 David Gibson 提交于
The reset handler for DRCs attempts several state transitions which are subject to various checks and restrictions. But at reset time we know there is no guest, so we can ignore most of the usual sequencing rules and just set the DRC back to a known state. In fact, it's safer to do so. The existing code also has several redundant checks for drc->awaiting_release inside a block which has already tested that. This patch removes those and sets the DRC to a fixed initial state based only on whether a device is currently plugged or not. With DRCs correctly reset to a state based on device presence, we don't need to force state transitions as cold plugged devices are processed. This allows us to remove all the callers of the set_*_state() methods from outside spapr_drc.c. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 David Gibson 提交于
spapr_drc_detach() is called when qemu generic code requests a device be unplugged. It makes a number of tests, which could well delay further action until later, before actually detach the device from the DRC. This splits out the part which actually removes the device from the DRC into spapr_drc_release(). This will be useful for further cleanups. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 David Gibson 提交于
The 'signalled' field in the DRC appears to be entirely a torturous workaround for the fact that PCI devices were started in UNISOLATED state for unclear reasons. 1) 'signalled' is already meaningless for logical (so far, all non PCI) DRCs. It's always set to true (at least at any point it might be tested), and can't be assigned any real meaning due to the way signalling works for logical DRCs. 2) For PCI DRCs, the only time signalled would be false is when non-zero functions of a multifunction device are hotplugged, followed by function zero (the other way around is explicitly not permitted). In that case the secondary function DRCs are attached, but the notification isn't sent to the guest until function 0 is plugged. 3) signalled being false is used to allow a DRC detach to switch mode back to ISOLATED state, which allows a secondary function to be hotplugged then unplugged with function 0 never inserted. Without this a secondary function starting in UNISOLATED state couldn't be detached again without function 0 being inserted, all the functions configured by the guest, then sent back to ISOLATED state. 4) But now that PCI DRCs start in ISOLATED state, there's nothing to be done. If the guest doesn't get the notification, it won't switch the device to UNISOLATED state, so nothing prevents it from being unplugged. If the guest does move it to UNISOLATED state without the signal (due to a manual drmgr call, for instance) then it really isn't safe to unplug it. So, this patch removes the signalled variable and all code related to it. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 David Gibson 提交于
PCI DRCs, and only PCI DRCs, are immediately moved to UNISOLATED isolation state once the device is attached. This has been there from the initial implementation, and it's not clear why. The state diagram in PAPR 13.4 suggests PCI devices should start in ISOLATED state until the guest moves them into UNISOLATED, and the code in the guest-side drmgr tool seems to work that way too. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NMichael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: NGreg Kurz <groug@kaod.org>
-
由 Aaron Larson 提交于
Previously QEMU open-pic implemented the 4 open-pic timers including all timer registers, but the timers did not "count" or generate any interrupts. The patch makes the timers both count and generate interrupts. The timer clock frequency is fixed at 25MHZ. -- Responding to V2 patch comments. - Simplify clock frequency logic and commentary. - Remove camelCase variables. - Timer objects now created at init rather than lazily. Signed-off-by: NAaron Larson <alarson@ddci.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Daniel Henrique Barboza 提交于
In ppc_spapr_reset(), if the guest is using HPT, the code was executing: } else { spapr->patb_entry = 0; spapr_setup_hpt_and_vrma(spapr); } And, at the end of spapr_setup_hpt_and_vrma: /* We're setting up a hash table, so that means we're not radix */ spapr->patb_entry = 0; Resulting in spapr->patb_entry being assigned to 0 twice in a row. Given that 'spapr_setup_hpt_and_vrma' is also called inside 'spapr_check_setup_free_hpt' of spapr_hcall.c, this trivial patch removes the 'patb_entry = 0' assignment from the 'else' clause inside ppc_spapr_reset to avoid this behavior. Signed-off-by: NDaniel Henrique Barboza <danielhb@linux.vnet.ibm.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Bharata B Rao 提交于
ICPState objects were being allocated before CPU thread realization. However commit 9ed65663 (xics: setup cpu at realize time) reversed it by allocating ICPState objects after CPU thread is realized. But it didn't take care to fix the error path because of which we observe a SIGSEGV when CPU thread realization fails during cold/hotplug. Fix this by ensuring that we do object_unparent() of ICPState object only in case when is was created earlier. Signed-off-by: NBharata B Rao <bharata@linux.vnet.ibm.com> Reviewed-by: NGreg Kurz <groug@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Bharata B Rao 提交于
If ppc_cpu_realizefn() fails after cpu_exec_realizefn() has been called, we will have to undo whatever cpu_exec_realizefn() did by explicitly calling cpu_exec_unrealizeffn() which is currently missing. Failure to do this proper cleanup will result in CPU which was never fully realized to linger on the cpus list causing SIGSEGV later (for eg when running "info cpus"). Signed-off-by: NBharata B Rao <bharata@linux.vnet.ibm.com> Reviewed-by: NGreg Kurz <groug@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Greg Kurz 提交于
Commit 5bc8d26d ("spapr: allocate the ICPState object from under sPAPRCPUCore") moved ICPState objects from the machine to CPU cores. This is an improvement since we no longer allocate ICPState objects that will never be used. But it has the side-effect of breaking migration of older machine types from older QEMU versions. This patch allows spapr to register dummy "icp/server" entries to vmstate. These entries use a dedicated VMStateDescription that can swallow and discard state of an incoming migration stream, and that don't send anything on outgoing migration. As for real ICPState objects, the instance_id is the cpu_index of the corresponding vCPU, which happens to be equal to the generated instance_id of older machine types. The machine can unregister/register these entries when CPUs are dynamically plugged/unplugged. This is only available for pseries-2.9 and older machines, thanks to a compat property. Signed-off-by: NGreg Kurz <groug@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Greg Kurz 提交于
The ICPState objects are currently registered to vmstate as qdev objects. Their instance ids are hence computed automatically in the migration code, and thus depends on the order the CPU cores were plugged. If the destination had its CPU cores plugged in a different order than the source, then ICPState objects will have different instance_ids and load the wrong state. Since CPU objects have a reliable cpu_index which is already used as instance_id in vmstate, let's use it for ICPState as well. Please note that this doesn't break migration. Older machine types used to allocate and realize all ICPState objects at machine init time, for the whole lifetime of the machine. The qdev instance ids are thus 0,1,2... nr_servers and happen to map to the vCPU indexes. Signed-off-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NLaurent Vivier <lvivier@redhat.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Suraj Jitindar Singh 提交于
The mmu fault handler should return 0 if it was able to successfully handle the fault and a positive value otherwise. Currently the tcg radix mmu fault handler will return 1 after successfully handling a fault in virtual mode. This is incorrect so fix it so that it returns 0 in this case. The handler already correctly returns 0 when a fault was handled in real mode and 1 if an interrupt was generated. Fixes: d5fee0bb ("target/ppc: Implement ISA V3.00 radix page fault handler") Signed-off-by: NSuraj Jitindar Singh <sjitindarsingh@gmail.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Thomas Huth 提交于
Since the introduction of MTTCG, using the msgsnd instruction abort()s if being called without holding the BQL. So let's protect that part of the code now with qemu_mutex_lock_iothread(). Buglink: https://bugs.launchpad.net/qemu/+bug/1694998Signed-off-by: NThomas Huth <thuth@redhat.com> Reviewed-by: NAlex Bennée <alex.bennee@linaro.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Bharata B Rao 提交于
Fix migration of radix guests by ensuring that we issue KVM_PPC_CONFIGURE_V3_MMU for radix case post migration. Reported-by: NNageswara R Sastry <rnsastry@linux.vnet.ibm.com> Signed-off-by: NBharata B Rao <bharata@linux.vnet.ibm.com> Reviewed-by: NSuraj Jitindar Singh <sjitindarsingh@gmail.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Bharata B Rao 提交于
Add a "no HPT" encoding (using value -1) to the HTAB migration stream (in the place of HPT size) when the guest doesn't allocate HPT. This will help the target side to match target HPT with the source HPT and thus enable successful migration. Suggested-by: NDavid Gibson <david@gibson.dropbear.id.au> Signed-off-by: NBharata B Rao <bharata@linux.vnet.ibm.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 David Gibson 提交于
Migrating between different CPU versions is a bit complicated for ppc. A long time ago, we ensured identical CPU versions at either end by checking the PVR had the same value. However, this breaks under KVM HV, because we always have to use the host's PVR - it's not virtualized. That would mean we couldn't migrate between hosts with different PVRs, even if the CPUs are close enough to compatible in practice (sometimes identical cores with different surrounding logic have different PVRs, so this happens in practice quite often). So, we removed the PVR check, but instead checked that several flags indicating supported instructions matched. This turns out to be a bad idea, because those instruction masks are not architected information, but essentially a TCG implementation detail. So changes to qemu internal CPU modelling can break migration - this happened between qemu-2.6 and qemu-2.7. That was addressed by 146c11f1 "target-ppc: Allow eventual removal of old migration mistakes". Now, verification of CPU compatibility across a migration basically doesn't happen. We simply ignore the PVR of the incoming migration, and hope the cpu on the destination is close enough to work. Now that we've cleaned up handling of processor compatibility modes for pseries machine type, we can do better. For new machine types (pseries-2.10+) We allow migration if: * The source and destination PVRs are for the same type of CPU, as determined by CPU class's pvr_match function OR * When the source was in a compatibility mode, and the destination CPU supports the same compatibility mode For older machine types we retain the existing behaviour - current CAS code will usually set a compat mode which would break backwards migration if we made them use the new behaviour. [Fixed from an earlier version by Greg Kurz]. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Signed-off-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NSuraj Jitindar Singh <sjitindarsingh@gmail.com> Tested-by: NAndrea Bolognani <abologna@redhat.com>
-
由 David Gibson 提交于
Currently, the CPU compatibility mode is set when the cpu is initialized, then again when the guest negotiates features. This means if a guest negotiates a compatibility mode, then reboots, that compatibility mode will be retained across the reset. Usually that will get overridden when features are negotiated on the next boot, but it's still not really correct. This patch moves the initial set up of the compatibility mode from cpu init to reset time. The mode *is* retained if the reboot was caused by the feature negotiation (it might be important in that case, though it's unlikely). Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NAlexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by: NMichael Roth <mdroth@linux.vnet.ibm.com> Tested-by: NAndrea Bolognani <abologna@redhat.com>
-
由 David Gibson 提交于
Server class POWER CPUs have a "compat" property, which is used to set the backwards compatibility mode for the processor. However, this only makes sense for machine types which don't give the guest access to hypervisor privilege - otherwise the compatibility level is under the guest's control. To reflect this, this removes the CPU 'compat' property and instead creates a 'max-cpu-compat' property on the pseries machine. Strictly speaking this breaks compatibility, but AFAIK the 'compat' option was never (directly) used with -device or device_add. The option was used with -cpu. So, to maintain compatibility, this patch adds a hack to the cpu option parsing to strip out any compat options supplied with -cpu and set them on the machine property instead of the now deprecated cpu property. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Tested-by: NSuraj Jitindar Singh <sjitindarsingh@gmail.com> Reviewed-by: NGreg Kurz <groug@kaod.org> Tested-by: NGreg Kurz <groug@kaod.org> Tested-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Greg Kurz 提交于
This may be used for deprecated object properties that are kept for backwards compatibility. Signed-off-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Tested-by: NAndrea Bolognani <abologna@redhat.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Thomas Huth 提交于
When using the 40p machine, soundhw_init() is currently called twice, one time from vl.c and one time from ibm_40p_init(). The call in ibm_40p_init() was likely just a copy-and-paste from a old version of the prep machine - but there the call to audio_init() (which was the previous name of this function) has been removed many years ago already, with commit b3e6d591 ("audio: enable PCI audio cards for all PCI-enabled targets"), so we certainly also do not need the soundhw_init() in the 40p function anymore nowadays. Signed-off-by: NThomas Huth <thuth@redhat.com> Reviewed-by: NSahid Ferdjaoui <sferdjao@redhat.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Reviewed-by: NHervé Poussineau <hpoussin@reactos.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Laurent Vivier 提交于
Signed-off-by: NLaurent Vivier <laurent@vivier.eu> Reviewed-by: NRichard Henderson <rth@twiddle.net> Message-Id: <20170628204241.32106-8-laurent@vivier.eu>
-
由 Laurent Vivier 提交于
Add fsabs, fdabs, fsneg, fdneg, fsmove and fdmove. The value is converted using the new floatx80_round() function. Signed-off-by: NLaurent Vivier <laurent@vivier.eu> Reviewed-by: NRichard Henderson <rth@twiddle.net> Message-Id: <20170628204241.32106-7-laurent@vivier.eu>
-
由 Laurent Vivier 提交于
fsglmul and fsgldiv truncate data to single precision before computing results. Signed-off-by: NLaurent Vivier <laurent@vivier.eu> Reviewed-by: NRichard Henderson <rth@twiddle.net> Message-Id: <20170628204241.32106-6-laurent@vivier.eu>
-
由 Laurent Vivier 提交于
Add a function to round a floatx80 to the defined precision (floatx80_rounding_precision) Signed-off-by: NLaurent Vivier <laurent@vivier.eu> Reviewed-by: NRichard Henderson <rth@twiddle.net> Reviewed-by: NAurelien Jarno <aurelien@aurel32.net> Message-Id: <20170628204241.32106-5-laurent@vivier.eu>
-