aboutsummaryrefslogtreecommitdiff
path: root/target/ppc/machine.c
AgeCommit message (Collapse)AuthorFilesLines
2024-09-03target/ppc: Fix migration of CPUs with TLB_EMB TLB typeArman Nabiev1-1/+1
In vmstate_tlbemb a cut-and-paste error meant we gave this vmstate subsection the same "cpu/tlb6xx" name as the vmstate_tlb6xx subsection. This breaks migration load for any CPU using the TLB_EMB CPU type, because when we see the "tlb6xx" name in the incoming data we try to interpret it as a vmstate_tlb6xx subsection, which it isn't the right format for: $ qemu-system-ppc -drive if=none,format=qcow2,file=/home/petmay01/test-images/virt/dummy.qcow2 -monitor stdio -M bamboo QEMU 9.0.92 monitor - type 'help' for more information (qemu) savevm foo (qemu) loadvm foo Missing section footer for cpu Error: Error -22 while loading VM state Correct the incorrect vmstate section name. Since migration for these CPU types was completely broken before, we don't need to care that this is a migration compatibility break. This affects the PPC 405, 440, 460 and e200 CPU families. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2522 Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Arman Nabiev <nabiev.arman13@gmail.com> Signed-off-by: Fabiano Rosas <farosas@suse.de>
2024-05-24target/ppc: Add migration support for BHRBGlenn Miles1-0/+21
Adds migration support for Branch History Rolling Buffer (BHRB) internal state. Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Glenn Miles <milesg@linux.vnet.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
2024-05-24target/ppc: Add new hflags to support BHRBGlenn Miles1-1/+1
This commit is preparatory to the addition of Branch History Rolling Buffer (BHRB) functionality, which is being provided today starting with the P8 processor. BHRB uses several SPR register fields to control whether or not a branch instruction's address (and sometimes target address) should be recorded. Checking each of these fields with each branch instruction using jitted code would lead to a significant decrease in performance. Therefore, it was decided that BHRB configuration bits that are not expected to change frequently should have their state summarized in an hflag so that the amount of checking done by jitted code can be reduced. This commit contains the changes for summarizing the state of the following register fields in the HFLAGS_BHRB_ENABLE hflag: MMCR0[FCP] - Determines if BHRB recording is frozen in the problem state MMCR0[FCPC] - A modifier for MMCR0[FCP] MMCRA[BHRBRD] - Disables all BHRB recording for a thread Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Glenn Miles <milesg@linux.vnet.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
2023-12-29target/ppc: Constify VMState in machine.cRichard Henderson1-16/+16
Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20231221031652.119827-15-richard.henderson@linaro.org>
2023-09-06target/ppc: Fix CPU reservation migration for record-replayNicholas Piggin1-2/+24
ppc only migrates reserve_addr, so the destination machine can get a valid reservation with an incorrect reservation value of 0. Prior to commit 392d328abe753 ("target/ppc: Ensure stcx size matches larx"), this could permit a stcx. to incorrectly succeed. That commit inadvertently fixed that bug because the target machine starts with an impossible reservation size of 0, so any stcx. will fail. This behaviour is permitted by the ISA because reservation loss may have implementation-dependent cause. What's more, with KVM machines it is impossible save or reasonably restore reservation state. However if the vmstate is being used for record-replay, the reservation must be saved and restored exactly in order for execution from snapshot to match the record. This patch deprecates the existing incomplete reserve_addr vmstate, and adds a new vmstate subsection with complete reservation state. The new vmstate is needed only when record-replay mode is active. Acked-by: Pavel Dovgalyuk <Pavel.Dovgalyuk@ispras.ru> Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2023-09-06target/ppc: Migrate DECR SPRNicholas Piggin1-0/+14
TCG does not maintain the DEC reigster in the SPR array, so it does get migrated. TCG also needs to re-start the decrementer timer on the destination machine. Load and store the decrementer into the SPR when migrating. This works for the level-triggered (book3s) decrementer, and should be compatible with existing KVM machines that do keep the DEC value there. This fixes lost decrementer interrupt on migration that can cause hangs, as well as other problems including record-replay bugs. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2023-09-06target/ppc: Implement watchpoint debug facility for v2.07SNicholas Piggin1-0/+1
ISA v2.07S introduced the watchpoint facility based on the DAWR0 and DAWRX0 SPRs. Implement this in TCG. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2023-09-06target/ppc: Implement breakpoint debug facility for v2.07SNicholas Piggin1-0/+4
ISA v2.07S introduced the breakpoint facility based on the CIABR SPR. Implement this in TCG. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2023-08-31target/helpers: Remove unnecessary 'qemu/main-loop.h' headerPhilippe Mathieu-Daudé1-1/+0
"qemu/main-loop.h" declares functions related to QEMU's main loop mutex, which these files don't access. Remove the unused "qemu/main-loop.h" header. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20230828221314.18435-8-philmd@linaro.org>
2023-06-10target/ppc: Fix PMU hflags calculationNicholas Piggin1-4/+4
Some of the PMU hflags bits can go out of synch, for example a store to MMCR0 with PMCjCE=1 fails to update hflags correctly and results in hflags mismatch: qemu: fatal: TCG hflags mismatch (current:0x2408003d rebuilt:0x240a003d) This can be reproduced by running perf on a recent machine. Some of the fragility here is the duplication of PMU hflags calculations. This change consolidates that in a single place to update pmu-related hflags, to be called after a well defined state changes. The post-load PMU update is pulled out of the MSR update because it does not depend on the MSR value. Fixes: 8b3d1c49a9f0 ("target/ppc: Add new PMC HFLAGS") Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20230530130447.372617-1-npiggin@gmail.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-08-30target/ppc: Fix host PVR matching for KVMNicholas Piggin1-1/+1
ppc_cpu_compare_class_pvr_mask() should match the best CPU class in the family, because it is used by the KVM subsystem to find the host CPU class. Since commit 03ae4133ab8 ("target-ppc: Add pvr_match() callback"), it matches any class in the family (the first one in the comparison list). Since commit f30c843ced5 ("ppc/pnv: Introduce PowerNV machines with fixed CPU models"), pnv has relied on pnv_match having these new semantics to check machine compatibility with a CPU family. Resolve this by adding a parameter to the pvr_match function to select the best or any match, and restore the old behaviour for the KVM case. Prior to this fix, e.g., a POWER9 DD2.3 KVM host matches to the power9_v1.0 class (because that happens to be the first POWER9 family CPU compared). After the patch, it matches the power9_v2.0 class. This approach requires pnv_match contain knowledge of the CPU classes implemented in the same family, which feels ugly. But pushing the 'best' match down to the class would still require they know about one another which is not obviously much better. For now this gets things working. Fixes: 03ae4133ab8 ("target-ppc: Add pvr_match() callback") Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220731013358.170187-1-npiggin@gmail.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-26target/ppc: Implement lwsync with weaker memory orderingNicholas Piggin1-1/+2
This allows an x86 host to no-op lwsyncs, and ppc host can use lwsync rather than sync. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220519135908.21282-5-npiggin@gmail.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-05target/ppc: Remove msr_ts macroVíctor Colombo1-1/+1
msr_ts macro hides the usage of env->msr, which is a bad behavior. Substitute it with FIELD_EX64 calls that explicitly use env->msr as a parameter. Suggested-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Víctor Colombo <victor.colombo@eldorado.org.br> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220504210541.115256-19-victor.colombo@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-03-02target/ppc: make power8-pmu.c CONFIG_TCG onlyDaniel Henrique Barboza1-1/+5
This is an exclusive TCG helper. Gating it with CONFIG_TCG and changing meson.build accordingly will prevent problems --disable-tcg and --disable-linux-user later on. We're also changing the uses of !kvm_enabled() to tcg_enabled() to avoid adding "defined(CONFIG_TCG)" ifdefs, since tcg_enabled() will be defaulted to false with --disable-tcg and the block will always be skipped. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220225101140.1054160-2-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-02-09target/ppc: Remove PowerPC 601 CPUsCédric Le Goater1-3/+2
The PowerPC 601 processor is the first generation of processors to implement the PowerPC architecture. It was designed as a bridge processor and also could execute most of the instructions of the previous POWER architecture. It was found on the first Macs and IBM RS/6000 workstations. There is not much interest in keeping the CPU model of this POWER-PowerPC bridge processor. We have the 603 and 604 CPU models of the 60x family which implement the complete PowerPC instruction set. Cc: "Hervé Poussineau" <hpoussin@reactos.org> Cc: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Fabiano Rosas <farosas@linux.ibm.com> Message-Id: <20220203142756.1302515-1-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-28Remove unnecessary minimum_version_id_old fieldsPeter Maydell1-2/+0
The migration code will not look at a VMStateDescription's minimum_version_id_old field unless that VMSD has set the load_state_old field to something non-NULL. (The purpose of minimum_version_id_old is to specify what migration version is needed for the code in the function pointed to by load_state_old to be able to handle it on incoming migration.) We have exactly one VMSD which still has a load_state_old, in the PPC CPU; every other VMSD which sets minimum_version_id_old is doing so unnecessarily. Delete all the unnecessary ones. Commit created with: sed -i '/\.minimum_version_id_old/d' $(git grep -l '\.minimum_version_id_old') with the one legitimate use then hand-edited back in. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> --- It missed vmstate_ppc_cpu.
2022-01-18target/ppc: Finish removal of 401/403 CPUsCédric Le Goater1-24/+0
Commit c8f49e6b938e ("target/ppc: remove 401/403 CPUs") left a few things behind. Reviewed-by: Fabiano Rosas <farosas@linux.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20220117091541.1615807-1-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220118104150.1899661-3-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-18target/ppc: Remove last user of .load_state_oldCédric Le Goater1-112/+0
This breaks migration compatibility from (very) old versions of QEMU. This should not be a problem for the pseries machine for which migration is only supported on recent QEMUs ( > 2.x). There is no clear status on what is supported or not for the other machines. Let's move forward and remove the .load_state_old handler. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20220118104150.1899661-2-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-04target/ppc: Cache per-pmc insn and cycle count settingsRichard Henderson1-0/+2
This is the combination of frozen bit and counter type, on a per counter basis. So far this is only used by HFLAGS_INSN_CNT, but will be used more later. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> [danielhb: fixed PMC4 cyc_cnt shift, insn run latch code, MMCR0_FC handling, "PMC[1-6]" comment] Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220103224746.167831-2-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-05-19target/ppc: updated vscr manipulation in machine.cBruno Larsen (billionai)1-4/+3
Updated the code in machine.c to use the generic ppc_{store,get}_vscr instead of helper style functions, so it can build without TCG Signed-off-by: Bruno Larsen (billionai) <bruno.larsen@eldorado.org.br> Message-Id: <20210512140813.112884-7-bruno.larsen@eldorado.org.br> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-05-04target/ppc: Remove env->immu_idx and env->dmmu_idxRichard Henderson1-1/+1
We weren't recording MSR_GS in hflags, which means that BookE memory accesses were essentially random vs Guest State. Instead of adding this bit directly, record the completed mmu indexes instead. This makes it obvious that we are recording exactly the information that we need. This also means that we can stop directly recording MSR_IR. Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210323184340.619757-9-richard.henderson@linaro.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-05-04target/ppc: Extract post_load_update_msrRichard Henderson1-16/+14
Extract post_load_update_msr to share between cpu_load_old and cpu_post_load in updating the msr. Suggested-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210323184340.619757-2-richard.henderson@linaro.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-05-04target/ppc: Retain hflags_nmsr only for migrationRichard Henderson1-3/+6
We have eliminated all normal uses of hflags_nmsr. We need not even compute it except when we want to migrate. Rename the field to emphasize this. Remove the fixme comment for migrating access_type. This value is only ever used with the current executing instruction, and is never live when the cpu is halted for migration. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210315184615.1985590-6-richard.henderson@linaro.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-05-04target/ppc: Do not call hreg_compute_mem_idx after ppc_store_msrRichard Henderson1-6/+1
In ppc_store_msr we call hreg_compute_hflags, which itself calls hreg_compute_mem_idx. Rely on ppc_store_msr to update everything required by the msr update. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210315184615.1985590-5-richard.henderson@linaro.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-05-04target/ppc: Properly sync cpu state with new msr in cpu_load_oldRichard Henderson1-2/+11
Match cpu_post_load in using ppc_store_msr to set all of the cpu state implied by the value of msr. Do not restore hflags or hflags_nmsr, as we recompute them in ppc_store_msr. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210315184615.1985590-4-richard.henderson@linaro.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-12-19migration: Replace migration's JSON writer by the general oneMarkus Armbruster1-5/+5
Commit 8118f0950f "migration: Append JSON description of migration stream" needs a JSON writer. The existing qobject_to_json() wasn't a good fit, because it requires building a QObject to convert. Instead, migration got its very own JSON writer, in commit 190c882ce2 "QJSON: Add JSON writer". It tacitly limits numbers to int64_t, and strings contents to characters that don't need escaping, unlike qobject_to_json(). The previous commit factored the JSON writer out of qobject_to_json(). Replace migration's JSON writer by it. Cc: Juan Quintela <quintela@redhat.com> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20201211171152.146877-17-armbru@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2020-12-14target/ppc: Introduce an mmu_is_64bit() helperGreg Kurz1-2/+2
Callers don't really need to know how 64-bit MMU model enums are computed. Hide this in a helper. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <20201209173536.1437351-3-groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-10-28ppc/: fix some comment spelling errorszhaolichang1-1/+1
I found that there are many spelling errors in the comments of qemu/target/ppc. I used spellcheck to check the spelling errors and found some errors in the folder. Signed-off-by: zhaolichang <zhaolichang@huawei.com> Reviewed-by: David Edmondson <david.edmondson@oracle.com> Message-Id: <20201009064449.2336-3-zhaolichang@huawei.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-10-09ppc: Fix return value in cpu_post_load() error pathGreg Kurz1-4/+5
VMState handlers are supposed to return negative errno values on failure. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <20200914123505.612812-4-groug@kaod.org> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-08-16Include hw/boards.h a bit lessMarkus Armbruster1-1/+0
hw/boards.h pulls in almost 60 headers. The less we include it into headers, the better. As a first step, drop superfluous inclusions, and downgrade some more to what's actually needed. Gets rid of just one inclusion into a header. Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20190812052359.30071-23-armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
2019-08-16Include qemu/main-loop.h lessMarkus Armbruster1-0/+1
In my "build everything" tree, changing qemu/main-loop.h triggers a recompile of some 5600 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). It includes block/aio.h, which in turn includes qemu/event_notifier.h, qemu/notify.h, qemu/processor.h, qemu/qsp.h, qemu/queue.h, qemu/thread-posix.h, qemu/thread.h, qemu/timer.h, and a few more. Include qemu/main-loop.h only where it's needed. Touching it now recompiles only some 1700 objects. For block/aio.h and qemu/event_notifier.h, these numbers drop from 5600 to 2800. For the others, they shrink only slightly. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190812052359.30071-21-armbru@redhat.com> Reviewed-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-08-16Include hw/hw.h exactly where neededMarkus Armbruster1-1/+0
In my "build everything" tree, changing hw/hw.h triggers a recompile of some 2600 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). The previous commits have left only the declaration of hw_error() in hw/hw.h. This permits dropping most of its inclusions. Touching it now recompiles less than 200 objects. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20190812052359.30071-19-armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-07-02target/ppc/machine: Add kvmppc_pvr_workaround_required() stubGreg Kurz1-2/+0
This allows to drop the CONFIG_KVM guard from the code. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <156051056289.224162.15553539098911498678.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-06-12Include qemu-common.h exactly where neededMarkus Armbruster1-1/+0
No header includes qemu-common.h after this commit, as prescribed by qemu-common.h's file comment. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190523143508.25387-5-armbru@redhat.com> [Rebased with conflicts resolved automatically, except for include/hw/arm/xlnx-zynqmp.h hw/arm/nrf51_soc.c hw/arm/msf2-soc.c block/qcow2-refcount.c block/qcow2-cluster.c block/qcow2-cache.c target/arm/cpu.h target/lm32/cpu.h target/m68k/cpu.h target/mips/cpu.h target/moxie/cpu.h target/nios2/cpu.h target/openrisc/cpu.h target/riscv/cpu.h target/tilegx/cpu.h target/tricore/cpu.h target/unicore32/cpu.h target/xtensa/cpu.h; bsd-user/main.c and net/tap-bsd.c fixed up]
2019-04-26target/ppc: Style fixes for machine.cDavid Gibson1-43/+63
Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org>
2019-03-12target/ppc: switch fpr/vsrl registers so all VSX registers are in host ↵Mark Cave-Ayland1-4/+4
endian order When VSX support was initially added, the fpr registers were added at offset 0 of the VSR register and the vsrl registers were added at offset 1. This is in contrast to the VMX registers (the last 32 VSX registers) which are stored in host-endian order. Switch the fpr/vsrl registers so that the lower 32 VSX registers are now also stored in host endian order to match the VMX registers. This ensures that TCG vector operations involving mixed VMX and VSX registers will function correctly. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20190307180520.13868-7-mark.cave-ayland@ilande.co.uk> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-18target/ppc: Use mtvscr/mfvscr for vmstateRichard Henderson1-3/+41
This is required before changing the representation of the register. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Acked-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20190215100058.20015-14-mark.cave-ayland@ilande.co.uk> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-01-09target/ppc: move FP and VMX registers into aligned vsr register arrayMark Cave-Ayland1-5/+67
The VSX register array is a block of 64 128-bit registers where the first 32 registers consist of the existing 64-bit FP registers extended to 128-bit using new VSR registers, and the last 32 registers are the VMX 128-bit registers as show below: 64-bit 64-bit +--------------------+--------------------+ | FP0 | | VSR0 +--------------------+--------------------+ | FP1 | | VSR1 +--------------------+--------------------+ | ... | ... | ... +--------------------+--------------------+ | FP30 | | VSR30 +--------------------+--------------------+ | FP31 | | VSR31 +--------------------+--------------------+ | VMX0 | VSR32 +-----------------------------------------+ | VMX1 | VSR33 +-----------------------------------------+ | ... | ... +-----------------------------------------+ | VMX30 | VSR62 +-----------------------------------------+ | VMX31 | VSR63 +-----------------------------------------+ In order to allow for future conversion of VSX instructions to use TCG vector operations, recreate the same layout using an aligned version of the existing vsr register array. Since the old fpr and avr register arrays are removed, the existing callers must also be updated to use the correct offset in the vsr register array. This also includes switching the relevant VMState fields over to using subarrays to make sure that migration is preserved. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Acked-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2018-11-27vmstate: constify VMStateFieldMarc-André Lureau1-6/+8
Because they are supposed to remain const. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20181114132931.22624-1-marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-05-29ppc: Rename 2.13 machines to 3.0Peter Maydell1-4/+4
Rename the 2.13 machines to match the number we're going to use for the next release. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> Message-id: 20180522104000.9044-5-peter.maydell@linaro.org
2018-05-04target/ppc: always set PPC_MEM_TLBIE in pre 2.8 migration hackGreg Kurz1-0/+5
The pseries-2.7 and older machine types require CPUPPCState::insns_flags to be strictly equal between source and destination. This checking is abusive and breaks migration of KVM guests when the host CPU models are different, even if they are compatible enough to allow the guest to run transparently. This buggy behaviour was fixed for pseries-2.8 and we added some hacks to allow backward migration of older machine types. These hacks assume that the CPU belongs to the POWER8 family, which was true for most KVM based setup we cared about at the time. But now POWER9 systems are coming, and backward migration of pre 2.8 guests running in POWER8 architected mode from a POWER9 host to a POWER8 host is broken: qemu-system-ppc64: error while loading state for instance 0x0 of device 'cpu' qemu-system-ppc64: load of migration failed: Invalid argument This happens because POWER9 doesn't set PPC_MEM_TLBIE in insns_flags, while POWER8 does. Let's force PPC_MEM_TLBIE in the migration hack to fix the issue. This is an acceptable hack because these old machine types only support CPU models that do set PPC_MEM_TLBIE. Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2018-04-27target/ppc: Fold slb_nr into PPCHash64OptionsDavid Gibson1-3/+20
The env->slb_nr field gives the size of the SLB (Segment Lookaside Buffer). This is another static-after-initialization parameter of the specific version of the 64-bit hash MMU in the CPU. So, this patch folds the field into PPCHash64Options with the other hash MMU options. This is a bit more complicated that the things previously put in there, because slb_nr was foolishly included in the migration stream. So we need some of the usual dance to handle backwards compatible migration. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org>
2018-04-10target/ppc: Fix backwards migration of msr_maskDavid Gibson1-1/+9
21b786f "PowerPC: Add TS bits into msr_mask" added the transaction states to msr_mask for recent POWER CPUs to allow correct migration of machines that are in certain interim transactional memory states. This was correct, but unfortunately breaks backwards of pseries-2.7 and earlier machine types which (stupidly) transferred the msr_mask in the migration stream and failed if it wasn't equal on each end. This works around the problem by masking out the new MSR bits in the compatibility code to send the msr_mask on old machine types. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Tested-by: Greg Kurz <groug@kaod.org> Tested-by: Lukáš Doktor <ldoktor@redhat.com>
2017-11-30target-ppc: Don't invalidate non-supported msr bitsKurban Mallachiev1-2/+2
The msr invalidation code (commits 993eb and 2360b) inverts all bits except MSR_TGPR and MSR_HVB. On non PowerPC 601 processors this leads to incorrect change of excp_prefix in hreg_store_msr() function. The problem is that new msr value get multiplied by msr_mask and inverted msr does not, thus values of MSR_EP bit in new msr value and inverted msr are distinct, so that excp_prefix changes but should not. Signed-off-by: Kurban Mallachiev <mallachiev@ispras.ru> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-11-27target/ppc: Fix setting of cpu->compat_pvr on incoming migrationSuraj Jitindar Singh1-1/+3
cpu->compat_pvr is used to store the current compat mode of the cpu. On the receiving side during incoming migration we check compatibility with the compat mode by calling ppc_set_compat(). However we fail to set the compat mode with the hypervisor since the "new" compat mode doesn't differ from the current (due to a "cpu->compat_pvr != compat_pvr" check). This means that kvm runs the vcpus without a compat mode, which is the incorrect behaviour. The implication being that a compatibility mode will never be in effect after migration. To fix this so that the compat mode is correctly set with the hypervisor, store the desired compat mode and reset cpu->compat_pvr to zero before calling ppc_set_compat(). Fixes: 5dfaa532 ("ppc: fix ppc_set_compat() with KVM PR") Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-09-27migration: pre_save return intDr. David Alan Gilbert1-1/+3
Modify the pre_save method on VMStateDescription to return an int rather than void so that it potentially can fail. Changed zillions of devices to make them return 0; the only case I've made it return non-0 is hw/intc/s390_flic_kvm.c that already had an error_report/return case. Note: If you add an error exit in your pre_save you must emit an error_report to say why. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20170925112917.21340-2-dgilbert@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2017-08-22target/ppc: 'PVR != host PVR' in KVM_SET_SREGS workaroundDaniel Henrique Barboza1-0/+22
Commit d5fc133eed ("ppc: Rework CPU compatibility testing across migration") changed the way cpu_post_load behaves with the PVR setting, causing an unexpected bug in KVM-HV migrations between hosts that are compatible (POWER8 and POWER8E, for example). Even with pvr_match() returning true, the guest freezes right after cpu_post_load. The reason is that the guest kernel can't handle a different PVR value other that the running host in KVM_SET_SREGS. In [1] it was discussed the possibility of a new KVM capability that would indicate that the guest kernel can handle a different PVR in KVM_SET_SREGS. Even if such feature is implemented, there is still the problem with older kernels that will not have this capability and will fail to migrate. This patch implements a workaround for that scenario. If running with KVM, check if the guest kernel does not have the capability (named here as 'cap_ppc_pvr_compat'). If it doesn't, calls kvmppc_is_pr() to see if the guest is running in KVM-HV. If all this happens, set env->spr[SPR_PVR] to the same value as the current host PVR. This ensures that we allow migrations with 'close enough' PVRs to still work in KVM-HV but also makes the code ready for this new KVM capability when it is done. A new function called 'kvmppc_pvr_workaround_required' was created to encapsulate the conditions said above and to avoid calling too many kvm.c internals inside cpu_post_load. [1] https://lists.gnu.org/archive/html/qemu-ppc/2017-06/msg00503.html Signed-off-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com> [dwg: Fix for the case of using TCG on a PPC host] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-08-09ppc: fix double-free in cpu_post_load()Greg Kurz1-1/+0
When running nested with KVM PR, ppc_set_compat() fails and QEMU crashes because of "double free or corruption (!prev)". The crash happens because error_report_err() has already called error_free(). Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-06-30ppc: Rework CPU compatibility testing across migrationDavid Gibson1-3/+66
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: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Tested-by: Andrea Bolognani <abologna@redhat.com>
2017-06-28vmstate: error hint for failed equal checksHalil Pasic1-4/+4
In some cases a failing VMSTATE_*_EQUAL does not mean we detected a bug, but it's actually the best we can do. Especially in these cases a verbose error message is required. Let's introduce infrastructure for specifying a error hint to be used if equal check fails. Let's do this by adding a parameter to the _EQUAL macros called _err_hint. Also change all current users to pass NULL as last parameter so nothing changes for them. Signed-off-by: Halil Pasic <pasic@linux.vnet.ibm.com> Message-Id: <20170623144823.42936-1-pasic@linux.vnet.ibm.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
generated by cgit v1.1 at 2024-11-20 11:13:59 +0000