aboutsummaryrefslogtreecommitdiff
path: root/target/ppc
AgeCommit message (Collapse)Author
2022-05-26target/ppc: Implemented xvf16ger*Lucas Mateus Castro (alqotel)
Implement the following PowerISA v3.1 instructions: xvf16ger2: VSX Vector 16-bit Floating-Point GER (rank-2 update) xvf16ger2nn: VSX Vector 16-bit Floating-Point GER (rank-2 update) Negative multiply, Negative accumulate xvf16ger2np: VSX Vector 16-bit Floating-Point GER (rank-2 update) Negative multiply, Positive accumulate xvf16ger2pn: VSX Vector 16-bit Floating-Point GER (rank-2 update) Positive multiply, Negative accumulate xvf16ger2pp: VSX Vector 16-bit Floating-Point GER (rank-2 update) Positive multiply, Positive accumulate Signed-off-by: Lucas Mateus Castro (alqotel) <lucas.araujo@eldorado.org.br> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220524140537.27451-6-lucas.araujo@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-26target/ppc: Implemented xvf*ger*Lucas Mateus Castro (alqotel)
Implement the following PowerISA v3.1 instructions: xvf32ger: VSX Vector 32-bit Floating-Point GER (rank-1 update) xvf32gernn: VSX Vector 32-bit Floating-Point GER (rank-1 update) Negative multiply, Negative accumulate xvf32gernp: VSX Vector 32-bit Floating-Point GER (rank-1 update) Negative multiply, Positive accumulate xvf32gerpn: VSX Vector 32-bit Floating-Point GER (rank-1 update) Positive multiply, Negative accumulate xvf32gerpp: VSX Vector 32-bit Floating-Point GER (rank-1 update) Positive multiply, Positive accumulate xvf64ger: VSX Vector 64-bit Floating-Point GER (rank-1 update) xvf64gernn: VSX Vector 64-bit Floating-Point GER (rank-1 update) Negative multiply, Negative accumulate xvf64gernp: VSX Vector 64-bit Floating-Point GER (rank-1 update) Negative multiply, Positive accumulate xvf64gerpn: VSX Vector 64-bit Floating-Point GER (rank-1 update) Positive multiply, Negative accumulate xvf64gerpp: VSX Vector 64-bit Floating-Point GER (rank-1 update) Positive multiply, Positive accumulate Signed-off-by: Lucas Mateus Castro (alqotel) <lucas.araujo@eldorado.org.br> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220524140537.27451-5-lucas.araujo@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-26target/ppc: Implemented pmxvi*ger* instructionsLucas Mateus Castro (alqotel)
Implement the following PowerISA v3.1 instructions: pmxvi4ger8: Prefixed Masked VSX Vector 8-bit Signed/Unsigned Integer GER (rank-4 update) pmxvi4ger8pp: Prefixed Masked VSX Vector 8-bit Signed/Unsigned Integer GER (rank-4 update) Positive multiply, Positive accumulate pmxvi8ger4: Prefixed Masked VSX Vector 4-bit Signed Integer GER (rank-8 update) pmxvi8ger4pp: Prefixed Masked VSX Vector 4-bit Signed Integer GER (rank-8 update) Positive multiply, Positive accumulate pmxvi8ger4spp: Prefixed Masked VSX Vector 8-bit Signed/Unsigned Integer GER (rank-4 update) with Saturate Positive multiply, Positive accumulate pmxvi16ger2: Prefixed Masked VSX Vector 16-bit Signed Integer GER (rank-2 update) pmxvi16ger2pp: Prefixed Masked VSX Vector 16-bit Signed Integer GER (rank-2 update) Positive multiply, Positive accumulate pmxvi16ger2s: Prefixed Masked VSX Vector 16-bit Signed Integer GER (rank-2 update) with Saturation pmxvi16ger2spp: Prefixed Masked VSX Vector 16-bit Signed Integer GER (rank-2 update) with Saturation Positive multiply, Positive accumulate Signed-off-by: Lucas Mateus Castro (alqotel) <lucas.araujo@eldorado.org.br> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220524140537.27451-4-lucas.araujo@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-26target/ppc: Implemented xvi*ger* instructionsLucas Mateus Castro (alqotel)
Implement the following PowerISA v3.1 instructions: xvi4ger8: VSX Vector 8-bit Signed/Unsigned Integer GER (rank-4 update) xvi4ger8pp: VSX Vector 8-bit Signed/Unsigned Integer GER (rank-4 update) Positive multiply, Positive accumulate xvi8ger4: VSX Vector 4-bit Signed Integer GER (rank-8 update) xvi8ger4pp: VSX Vector 4-bit Signed Integer GER (rank-8 update) Positive multiply, Positive accumulate xvi8ger4spp: VSX Vector 8-bit Signed/Unsigned Integer GER (rank-4 update) with Saturate Positive multiply, Positive accumulate xvi16ger2: VSX Vector 16-bit Signed Integer GER (rank-2 update) xvi16ger2pp: VSX Vector 16-bit Signed Integer GER (rank-2 update) Positive multiply, Positive accumulate xvi16ger2s: VSX Vector 16-bit Signed Integer GER (rank-2 update) with Saturation xvi16ger2spp: VSX Vector 16-bit Signed Integer GER (rank-2 update) with Saturation Positive multiply, Positive accumulate Signed-off-by: Lucas Mateus Castro (alqotel) <lucas.araujo@eldorado.org.br> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220524140537.27451-3-lucas.araujo@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-26target/ppc: Implement xxm[tf]acc and xxsetacczLucas Mateus Castro (alqotel)
Implement the following PowerISA v3.1 instructions: xxmfacc: VSX Move From Accumulator xxmtacc: VSX Move To Accumulator xxsetaccz: VSX Set Accumulator to Zero The PowerISA 3.1 mentions that for the current version of the architecture, "the hardware implementation provides the effect of ACC[i] and VSRs 4*i to 4*i + 3 logically containing the same data" and "The Accumulators introduce no new logical state at this time" (page 501). For now it seems unnecessary to create new structures, so this patch just uses ACC[i] as VSRs 4*i to 4*i+3 and therefore move to and from accumulators are no-ops. Signed-off-by: Lucas Mateus Castro (alqotel) <lucas.araujo@eldorado.org.br> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220524140537.27451-2-lucas.araujo@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-26target/ppc: Implement lwsync with weaker memory orderingNicholas Piggin
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-26target/ppc: Fix eieio memory ordering semanticsNicholas Piggin
The generated eieio memory ordering semantics do not match the instruction definition in the architecture. Add a big comment to explain this strange instruction and correct the memory ordering behaviour. Signed-off: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220519135908.21282-2-npiggin@gmail.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-26target/ppc: declare vmsumsh[ms] helper with call flagsMatheus Ferst
Move vmsumshm and vmsumshs to decodetree, declare vmsumshm helper with TCG_CALL_NO_RWG, and drop the unused env argument. Signed-off-by: Matheus Ferst <matheus.ferst@eldorado.org.br> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220517123929.284511-13-matheus.ferst@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-26target/ppc: declare vmsumuh[ms] helper with call flagsMatheus Ferst
Move vmsumuhm and vmsumuhs to decodetree, declare vmsumuhm helper with TCG_CALL_NO_RWG, and drop the unused env argument. Signed-off-by: Matheus Ferst <matheus.ferst@eldorado.org.br> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220517123929.284511-12-matheus.ferst@eldorado.org.br> [danielhb: added #undef VMSUMUHM to fix ppc64 build] Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-26target/ppc: declare vmsum[um]bm helpers with call flagsMatheus Ferst
Move vmsumubm and vmsummbm to decodetree, declare both helpers with TCG_CALL_NO_RWG, and drop the unused env argument. Signed-off-by: Matheus Ferst <matheus.ferst@eldorado.org.br> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220517123929.284511-11-matheus.ferst@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-26target/ppc: introduce do_va_helperMatheus Ferst
Signed-off-by: Matheus Ferst <matheus.ferst@eldorado.org.br> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220517123929.284511-10-matheus.ferst@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-26target/ppc: declare xxextractuw and xxinsertw helpers with call flagsMatheus Ferst
Move xxextractuw and xxinsertw to decodetree, declare both helpers with TCG_CALL_NO_RWG, and drop the unused env argument. Signed-off-by: Matheus Ferst <matheus.ferst@eldorado.org.br> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220517123929.284511-9-matheus.ferst@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-26target/ppc: declare xvxsigsp helper with call flagsMatheus Ferst
Move xvxsigsp to decodetree, declare helper_xvxsigsp with TCG_CALL_NO_RWG, and drop the unused env argument. Signed-off-by: Matheus Ferst <matheus.ferst@eldorado.org.br> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220517123929.284511-8-matheus.ferst@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-26target/ppc: declare xscvspdpn helper with call flagsMatheus Ferst
Move xscvspdpn to decodetree, declare helper_xscvspdpn with TCG_CALL_NO_RWG_SE and drop the unused env argument. Signed-off-by: Matheus Ferst <matheus.ferst@eldorado.org.br> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220517123929.284511-7-matheus.ferst@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-26target/ppc: Use TCG_CALL_NO_RWG_SE in fsel helperMatheus Ferst
fsel doesn't change FPSCR and CR1 is handled by gen_set_cr1_from_fpscr, so helper_fsel doesn't need the env argument and can be declared with TCG_CALL_NO_RWG_SE. We also take this opportunity to move the insn to decodetree. Signed-off-by: Matheus Ferst <matheus.ferst@eldorado.org.br> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220517123929.284511-6-matheus.ferst@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-26target/ppc: use TCG_CALL_NO_RWG in VSX helpers without envMatheus Ferst
Helpers of VSX instructions without cpu_env as an argument do not access globals. Signed-off-by: Matheus Ferst <matheus.ferst@eldorado.org.br> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220517123929.284511-5-matheus.ferst@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-26target/ppc: use TCG_CALL_NO_RWG in BCD helpersMatheus Ferst
Helpers of BCD instructions only access the VSRs supplied by the TCGv_ptr arguments, no globals are accessed. Signed-off-by: Matheus Ferst <matheus.ferst@eldorado.org.br> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220517123929.284511-4-matheus.ferst@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-26target/ppc: use TCG_CALL_NO_RWG in vector helpers without envMatheus Ferst
Helpers of vector instructions without cpu_env as an argument do not access globals. Signed-off-by: Matheus Ferst <matheus.ferst@eldorado.org.br> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220517123929.284511-3-matheus.ferst@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-26target/ppc: declare darn32/darn64 helpers with TCG_CALL_NO_RWGMatheus Ferst
Signed-off-by: Matheus Ferst <matheus.ferst@eldorado.org.br> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220517123929.284511-2-matheus.ferst@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-26target/ppc: Rename sfprf to sfifprf where it's also used as set fi flagVíctor Colombo
The bit FI fix used the sfprf flag as a flag for the set_fi parameter in do_float_check_status where applicable. Now, this patch rename this flag to sfifprf to state this dual usage. Signed-off-by: Víctor Colombo <victor.colombo@eldorado.org.br> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Rashmica Gupta <rashmica.g@gmail.com> Message-Id: <20220517161522.36132-4-victor.colombo@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-26target/ppc: Fix FPSCR.FI changing in float_overflow_excp()Víctor Colombo
This patch fixes another not-so-clear situation in Power ISA regarding the inexact bits in FPSCR. The ISA states that: """ When Overflow Exception is disabled (OE=0) and an Overflow Exception occurs, the following actions are taken: ... 2. Inexact Exception is set XX <- 1 ... FI is set to 1 ... """ However, when tested on a Power 9 hardware, some instructions that trigger an OX don't set the FI bit: xvcvdpsp(0x4050533fcdb7b95ff8d561c40bf90996) = FI: CLEARED -> CLEARED xvnmsubmsp(0xf3c0c1fc8f3230, 0xbeaab9c5) = FI: CLEARED -> CLEARED (just a few examples. Other instructions are also affected) The root cause for this seems to be that only instructions that list the bit FI in the "Special Registers Altered" should modify it. QEMU is, today, not working like the hardware: xvcvdpsp(0x4050533fcdb7b95ff8d561c40bf90996) = FI: CLEARED -> SET xvnmsubmsp(0xf3c0c1fc8f3230, 0xbeaab9c5) = FI: CLEARED -> SET (all tests assume FI is cleared beforehand) Fix this by making float_overflow_excp() return float_flag_inexact if it should update the inexact flags. Signed-off-by: Víctor Colombo <victor.colombo@eldorado.org.br> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Rashmica Gupta <rashmica.g@gmail.com> Message-Id: <20220517161522.36132-3-victor.colombo@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-26target/ppc: Fix FPSCR.FI bit being cleared when it shouldn'tVíctor Colombo
According to Power ISA, the FI bit in FPSCR is non-sticky. This means that if an instruction is said to modify the FI bit, then it should be set or cleared depending on the result of the instruction. Otherwise, it should be kept as was before. However, the following inconsistency was found when comparing results from the hardware (tested on both a Power 9 processor and in Power 10 Mambo): (FI bit is set before the execution of the instruction) Hardware: xscmpeqdp(0xff..ff, 0xff..ff) = FI: SET -> SET QEMU: xscmpeqdp(0xff..ff, 0xff..ff) = FI: SET -> CLEARED As the FI bit is non-sticky, and xscmpeqdp does not list it as a field that is changed by the instruction, it should not be changed after its execution. This is happening to multiple instructions in the vsx implementations. If the ISA does not list the FI bit as altered for a particular instruction, then it should be kept as it was before the instruction. QEMU is not following this behavior. Affected instructions include: - xv* (all vsx-vector instructions); - xscmp*, xsmax*, xsmin*; - xstdivdp and similars; (to identify the affected instructions, just search in the ISA for the instructions that does not list FI in "Special Registers Altered") Most instructions use the function do_float_check_status() to commit changes in the inexact flag. So the fix is to add a parameter to it that will control if the bit FI should be changed or not. All users of do_float_check_status() are then modified to provide this argument, controlling if that specific instruction changes bit FI or not. Some macro helpers are responsible for both instructions that change and instructions that aren't suposed to change FI. This seems to always overlap with the sfprf flag. So, reuse this flag for this purpose when applicable. Signed-off-by: Víctor Colombo <victor.colombo@eldorado.org.br> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220517161522.36132-2-victor.colombo@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-26target/ppc: Fix tlbieLeandro Lupori
Commit 74c4912f097bab98 changed check_tlb_flush() to use tlb_flush_all_cpus_synced() instead of calling tlb_flush() on each CPU. However, as side effect of this, a CPU executing a ptesync after a tlbie will have its TLB flushed only after exiting its current Translation Block (TB). This causes memory accesses to invalid pages to succeed, if they happen to be on the same TB as the ptesync. To fix this, use tlb_flush_all_cpus() instead, that immediately flushes the TLB of the CPU executing the ptesync instruction. Fixes: 74c4912f097bab98 ("target/ppc: Fix synchronization of mttcg with broadcast TLB flushes") Signed-off-by: Leandro Lupori <leandro.lupori@eldorado.org.br> Reviewed-by: Fabiano Rosas <farosas@linux.ibm.com> Message-Id: <20220503163904.22575-1-leandro.lupori@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-11Normalize header guard symbol definitionMarkus Armbruster
We commonly define the header guard symbol without an explicit value. Normalize the exceptions. Done with scripts/clean-header-guards.pl. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20220506134911.2856099-4-armbru@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2022-05-11Clean up ill-advised or unusual header guardsMarkus Armbruster
Leading underscores are ill-advised because such identifiers are reserved. Trailing underscores are merely ugly. Strip both. Our header guards commonly end in _H. Normalize the exceptions. Macros should be ALL_CAPS. Normalize the exception. Done with scripts/clean-header-guards.pl. include/hw/xen/interface/ and tools/virtiofsd/ left alone, because these were imported from Xen and libfuse respectively. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20220506134911.2856099-3-armbru@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2022-05-09disas: Remove old libopcode ppc disassemblerThomas Huth
Capstone should be superior to the old libopcode disassembler, so we can drop the old file nowadays. Message-Id: <20220505173619.488350-1-thuth@redhat.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
2022-05-05target/ppc: Change MSR_* to follow POWER ISA numbering conventionVíctor Colombo
Today we have the issue where MSR_* values are the 'inverted order' bit numbers from what the ISA specifies. e.g. MSR_LE is bit 63 but is defined as 0 in QEMU. Add a macro to be used to convert from QEMU order to ISA order. This solution requires less changes than to use the already defined PPC_BIT macro, which would turn MSR_* in masks instead of the numbers itself. Signed-off-by: Víctor Colombo <victor.colombo@eldorado.org.br> Acked-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220504210541.115256-23-victor.colombo@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-05target/ppc: Add unused msr bits FIELDsVíctor Colombo
Add FIELDs macros for msr bits that had an unused msr_* before. Signed-off-by: Víctor Colombo <victor.colombo@eldorado.org.br> Acked-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220504210541.115256-22-victor.colombo@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-05target/ppc: Remove msr_de macroVíctor Colombo
msr_de 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-21-victor.colombo@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-05target/ppc: Remove msr_hv macroVíctor Colombo
msr_hv 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-20-victor.colombo@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-05target/ppc: Remove msr_ts macroVíctor Colombo
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-05-05target/ppc: Remove msr_fe0 and msr_fe1 macrosVíctor Colombo
msr_fe0 and msr_fe1 macros hide 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-18-victor.colombo@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-05target/ppc: Remove msr_ep macroVíctor Colombo
msr_ep 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-17-victor.colombo@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-05target/ppc: Remove msr_dr macroVíctor Colombo
msr_dr 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-16-victor.colombo@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-05target/ppc: Remove msr_ir macroVíctor Colombo
msr_ir 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-15-victor.colombo@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-05target/ppc: Remove msr_cm macroVíctor Colombo
msr_cm 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-14-victor.colombo@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-05target/ppc: Remove msr_fp macroVíctor Colombo
msr_fp 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-13-victor.colombo@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-05target/ppc: Remove msr_gs macroVíctor Colombo
msr_gs 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-12-victor.colombo@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-05target/ppc: Remove msr_me macroVíctor Colombo
msr_me 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-11-victor.colombo@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-05target/ppc: Remove msr_pow macroVíctor Colombo
msr_pow 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-10-victor.colombo@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-05target/ppc: Remove msr_ce macroVíctor Colombo
msr_ce 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-9-victor.colombo@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-05target/ppc: Remove msr_ee macroVíctor Colombo
msr_ee 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-8-victor.colombo@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-05target/ppc: Remove msr_ile macroVíctor Colombo
msr_ile 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-7-victor.colombo@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-05target/ppc: Remove msr_ds macroVíctor Colombo
msr_ds 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-6-victor.colombo@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-05target/ppc: Remove msr_le macroVíctor Colombo
msr_le 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-5-victor.colombo@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-05target/ppc: Remove msr_pr macroVíctor Colombo
msr_pr 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-4-victor.colombo@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-05target/ppc: Remove unused msr_* macrosVíctor Colombo
Some msr_* macros are not used anywhere. Remove them as part of the work to remove all hidden usage of *env. Suggested-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Víctor Colombo <victor.colombo@eldorado.org.br> Message-Id: <20220504210541.115256-3-victor.colombo@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-05target/ppc: Remove fpscr_* macros from cpu.hVíctor Colombo
fpscr_* defined macros are hiding the usage of *env behind them. Substitute the usage of these macros with `env->fpscr & FP_*` to make the code cleaner. Suggested-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Víctor Colombo <victor.colombo@eldorado.org.br> Message-Id: <20220504210541.115256-2-victor.colombo@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-05target/ppc: Fix BookE debug interrupt generationBin Meng
Per E500 core reference manual [1], chapter 8.4.4 "Branch Taken Debug Event" and chapter 8.4.5 "Instruction Complete Debug Event": "A branch taken debug event occurs if both MSR[DE] and DBCR0[BRT] are set ... Branch taken debug events are not recognized if MSR[DE] is cleared when the branch instruction executes." "An instruction complete debug event occurs when any instruction completes execution so long as MSR[DE] and DBCR0[ICMP] are both set ... Instruction complete debug events are not recognized if MSR[DE] is cleared at the time of the instruction execution." Current codes do not check MSR.DE bit before setting HFLAGS_SE and HFLAGS_BE flag, which would cause the immediate debug interrupt to be generated, e.g.: when DBCR0.ICMP bit is set by guest software and MSR.DE is not set. [1] https://www.nxp.com/docs/en/reference-manual/E500CORERM.pdf Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Fabiano Rosas <farosas@linux.ibm.com> Reviewed-by: Lucas Mateus Castro <lucas.araujo@eldorado.org.br> Message-Id: <20220421011729.1148727-1-bmeng.cn@gmail.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-05target/ppc: init 'rmmu_info' in kvm_get_radix_page_info()Daniel Henrique Barboza
Init the struct to avoid Valgrind complaints about unitialized bytes, such as this one: ==39549== Syscall param ioctl(generic) points to uninitialised byte(s) ==39549== at 0x55864E4: ioctl (in /usr/lib64/libc.so.6) ==39549== by 0xD1F7EF: kvm_vm_ioctl (kvm-all.c:3035) ==39549== by 0xAF8F5B: kvm_get_radix_page_info (kvm.c:276) ==39549== by 0xB00533: kvmppc_host_cpu_class_init (kvm.c:2369) ==39549== by 0xD3DCE7: type_initialize (object.c:366) ==39549== by 0xD3FACF: object_class_foreach_tramp (object.c:1071) ==39549== by 0x502757B: g_hash_table_foreach (in /usr/lib64/libglib-2.0.so.0.7000.5) ==39549== by 0xD3FC1B: object_class_foreach (object.c:1093) ==39549== by 0xB0141F: kvm_ppc_register_host_cpu_type (kvm.c:2613) ==39549== by 0xAF87E7: kvm_arch_init (kvm.c:157) ==39549== by 0xD1E2A7: kvm_init (kvm-all.c:2595) ==39549== by 0x8E6E93: accel_init_machine (accel-softmmu.c:39) ==39549== Address 0x1fff00e208 is on thread 1's stack ==39549== in frame #2, created by kvm_get_radix_page_info (kvm.c:267) ==39549== Uninitialised value was created by a stack allocation ==39549== at 0xAF8EE8: kvm_get_radix_page_info (kvm.c:267) Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220331001717.616938-5-danielhb413@gmail.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>