aboutsummaryrefslogtreecommitdiff
path: root/target
AgeCommit message (Collapse)Author
2024-01-27target/arm: Fix A64 scalar SQSHRN and SQRSHRNPeter Maydell
In commit 1b7bc9b5c8bf374dd we changed handle_vec_simd_sqshrn() so that instead of starting with a 0 value and depositing in each new element from the narrowing operation, it instead started with the raw result of the narrowing operation of the first element. This is fine in the vector case, because the deposit operations for the second and subsequent elements will always overwrite any higher bits that might have been in the first element's result value in tcg_rd. However in the scalar case we only go through this loop once. The effect is that for a signed narrowing operation, if the result is negative then we will now return a value where the bits above the first element are incorrectly 1 (because the narrowfn returns a sign-extended result, not one that is truncated to the element size). Fix this by using an extract operation to get exactly the correct bits of the output of the narrowfn for element 1, instead of a plain move. Cc: qemu-stable@nongnu.org Fixes: 1b7bc9b5c8bf374dd3 ("target/arm: Avoid tcg_const_ptr in handle_vec_simd_sqshrn") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2089 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20240123153416.877308-1-peter.maydell@linaro.org (cherry picked from commit 6fffc8378562c7fea6290c430b4f653f830a4c1a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-27target/xtensa: fix OOB TLB entry accessMax Filippov
r[id]tlb[01], [iw][id]tlb opcodes use TLB way index passed in a register by the guest. The host uses 3 bits of the index for ITLB indexing and 4 bits for DTLB, but there's only 7 entries in the ITLB array and 10 in the DTLB array, so a malicious guest may trigger out-of-bound access to these arrays. Change split_tlb_entry_spec return type to bool to indicate whether TLB way passed to it is valid. Change get_tlb_entry to return NULL in case invalid TLB way is requested. Add assertion to xtensa_tlb_get_entry that requested TLB way and entry indices are valid. Add checks to the [rwi]tlb helpers that requested TLB way is valid and return 0 or do nothing when it's not. Cc: qemu-stable@nongnu.org Fixes: b67ea0cd7441 ("target-xtensa: implement memory protection options") Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20231215120307.545381-1-jcmvbkbc@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 604927e357c2b292c70826e4ce42574ad126ef32) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-20target/i386: pcrel: store low bits of physical address in data[0]Paolo Bonzini
For PC-relative translation blocks, env->eip changes during the execution of a translation block, Therefore, QEMU must be able to recover an instruction's PC just from the TranslationBlock struct and the instruction data with. Because a TB will not span two pages, QEMU stores all the low bits of EIP in the instruction data and replaces them in x86_restore_state_to_opc. Bits 12 and higher (which may vary between executions of a PCREL TB, since these only use the physical address in the hash key) are kept unmodified from env->eip. The assumption is that these bits of EIP, unlike bits 0-11, will not change as the translation block executes. Unfortunately, this is incorrect when the CS base is not aligned to a page. Then the linear address of the instructions (i.e. the one with the CS base addred) indeed will never span two pages, but bits 12+ of EIP can actually change. For example, if CS base is 0x80262200 and EIP = 0x6FF4, the first instruction in the translation block will be at linear address 0x802691F4. Even a very small TB will cross to EIP = 0x7xxx, while the linear addresses will remain comfortably within a single page. The fix is simply to use the low bits of the linear address for data[0], since those don't change. Then x86_restore_state_to_opc uses tb->cs_base to compute a temporary linear address (referring to some unknown instruction in the TB, but with the correct values of bits 12 and higher); the low bits are replaced with data[0], and EIP is obtained by subtracting again the CS base. Huge thanks to Mark Cave-Ayland for the image and initial debugging, and to Gitlab user @kjliew for help with bisecting another occurrence of (hopefully!) the same bug. It should be relatively easy to write a testcase that performs MMIO on an EIP with different bits 12+ than the first instruction of the translation block; any help is welcome. Fixes: e3a79e0e878 ("target/i386: Enable TARGET_TB_PCREL", 2022-10-11) Cc: qemu-stable@nongnu.org Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Cc: Richard Henderson <richard.henderson@linaro.org> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1759 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1964 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2012 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 729ba8e933f8af5800c3a92b37e630e9bdaa9f1e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-20target/i386: fix incorrect EIP in PC-relative translation blocksguoguangyao
The PCREL patches introduced a bug when updating EIP in the !CF_PCREL case. Using s->pc in func gen_update_eip_next() solves the problem. Cc: qemu-stable@nongnu.org Fixes: b5e0d5d22fbf ("target/i386: Fix 32-bit wrapping of pc/eip computation") Fixes: 5b2fd6cf3735 (b5e0d5d22fbf in 8.1.4) Signed-off-by: guoguangyao <guoguangyao18@mails.ucas.ac.cn> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20240115020804.30272-1-guoguangyao18@mails.ucas.ac.cn> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 2926eab8969908bc068629e973062a0fb6ff3759) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-20target/i386: Do not re-compute new pc with CF_PCRELRichard Henderson
With PCREL, we have a page-relative view of EIP, and an approximation of PC = EIP+CSBASE that is good enough to detect page crossings. If we try to recompute PC after masking EIP, we will mess up that approximation and write a corrupt value to EIP. We already handled masking properly for PCREL, so the fix in b5e0d5d2 was only needed for the !PCREL path. Cc: qemu-stable@nongnu.org Fixes: b5e0d5d22fbf ("target/i386: Fix 32-bit wrapping of pc/eip computation") Fixes: 5b2fd6cf3735 (b5e0d5d22fbf in 8.1.4) Reported-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20240101230617.129349-1-richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit a58506b748b8988a95f4fa1a2420ac5c17038b30) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-13target/s390x: Fix LAE setting a wrong access registerIlya Leoshkevich
LAE should set the access register corresponding to the first operand, instead, it always modifies access register 1. Co-developed-by: Ido Plat <Ido.Plat@ibm.com> Cc: qemu-stable@nongnu.org Fixes: a1c7610a6879 ("target-s390x: implement LAY and LAEY instructions") Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Message-ID: <20240111092328.929421-2-iii@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit e358a25a97c71c39e3513d9b869cdb82052e50b8) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: target/s390x/tcg/translate.c: fixup for v8.1.0-1189-gad75a51e84 "tcg: Rename cpu_env to tcg_env")
2024-01-08target/riscv: Fix mcycle/minstret increment behaviorXu Lu
The mcycle/minstret counter's stop flag is mistakenly updated on a copy on stack. Thus the counter increments even when the CY/IR bit in the mcountinhibit register is set. This commit corrects its behavior. Fixes: 3780e33732f88 (target/riscv: Support mcycle/minstret write operation) Signed-off-by: Xu Lu <luxu.kernel@bytedance.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (cherry picked from commit 5cb0e7abe1635cb82e0033260dac2b910d142f8c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-12-20target/arm/helper: Propagate MDCR_EL2.HPMN into PMCR_EL0.NJean-Philippe Brucker
MDCR_EL2.HPMN allows an hypervisor to limit the number of PMU counters available to EL1 and EL0 (to keep the others to itself). QEMU already implements this split correctly, except for PMCR_EL0.N reads: the number of counters read by EL1 or EL0 should be the one configured in MDCR_EL2.HPMN. Cc: qemu-stable@nongnu.org Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Message-id: 20231215144652.4193815-2-jean-philippe@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 6980c31dec42b6daebf7fec13b2d39ed87bb4766) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-12-14target/i386: Fix 32-bit wrapping of pc/eip computationRichard Henderson
In 32-bit mode, pc = eip + cs_base is also 32-bit, and must wrap. Failure to do so results in incorrect memory exceptions to the guest. Before 732d548732ed, this was implicitly done via truncation to target_ulong but only in qemu-system-i386, not qemu-system-x86_64. To fix this, we must add conditional zero-extensions. Since we have to test for 32 vs 64-bit anyway, note that cs_base is always zero in 64-bit mode. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2022 Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20231212172510.103305-1-richard.henderson@linaro.org> (cherry picked from commit b5e0d5d22fbffc3d8f7d3e86d7a2d05a1a974e27) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: context fix in target/i386/tcg/tcg-cpu.c for v8.1.0-1190-gb77af26e97 "accel/tcg: Replace CPUState.env_ptr with cpu_env()")
2023-12-13target/arm: Disable SME if SVE is disabledPeter Maydell
There is no architectural requirement that SME implies SVE, but our implementation currently assumes it. (FEAT_SME_FA64 does imply SVE.) So if you try to run a CPU with eg "-cpu max,sve=off" you quickly run into an assert when the guest tries to write to SMCR_EL1: #6 0x00007ffff4b38e96 in __GI___assert_fail (assertion=0x5555566e69cb "sm", file=0x5555566e5b24 "../../target/arm/helper.c", line=6865, function=0x5555566e82f0 <__PRETTY_FUNCTION__.31> "sve_vqm1_for_el_sm") at ./assert/assert.c:101 #7 0x0000555555ee33aa in sve_vqm1_for_el_sm (env=0x555557d291f0, el=2, sm=false) at ../../target/arm/helper.c:6865 #8 0x0000555555ee3407 in sve_vqm1_for_el (env=0x555557d291f0, el=2) at ../../target/arm/helper.c:6871 #9 0x0000555555ee3724 in smcr_write (env=0x555557d291f0, ri=0x555557da23b0, value=2147483663) at ../../target/arm/helper.c:6995 #10 0x0000555555fd1dba in helper_set_cp_reg64 (env=0x555557d291f0, rip=0x555557da23b0, value=2147483663) at ../../target/arm/tcg/op_helper.c:839 #11 0x00007fff60056781 in code_gen_buffer () Avoid this unsupported and slightly odd combination by disabling SME when SVE is not present. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2005 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20231127173318.674758-1-peter.maydell@linaro.org (cherry picked from commit f7767ca301796334f74b9b642b395a4bd3e3dbac) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-12-05hw/avr/atmega: Fix wrong initial value of stack pointerGihun Nam
The current implementation initializes the stack pointer of AVR devices to 0. Although older AVR devices used to be like that, newer ones set it to RAMEND. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1525 Signed-off-by: Gihun Nam <gihun.nam@outlook.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <PH0P222MB0010877445B594724D40C924DEBDA@PH0P222MB0010.NAMP222.PROD.OUTLOOK.COM> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 235948bf53860a1e2df5134eae7b0a30a971a124) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-12-05target/arm: Handle overflow in calculation of next timer tickPeter Maydell
In commit edac4d8a168 back in 2015 when we added support for the virtual timer offset CNTVOFF_EL2, we didn't correctly update the timer-recalculation code that figures out when the timer interrupt is next going to change state. We got it wrong in two ways: * for the 0->1 transition, we didn't notice that gt->cval + offset can overflow a uint64_t * for the 1->0 transition, we didn't notice that the transition might now happen before the count rolls over, if offset > count In the former case, we end up trying to set the next interrupt for a time in the past, which results in QEMU hanging as the timer fires continuously. In the latter case, we would fail to update the interrupt status when we are supposed to. Fix the calculations in both cases. The test case is Alex Bennée's from the bug report, and tests the 0->1 transition overflow case. Fixes: edac4d8a168 ("target-arm: Add CNTVOFF_EL2") Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/60 Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20231120173506.3729884-1-peter.maydell@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 8d37a1425b9954d7e445615dcad23456515e24c0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-12-05target/arm: Set IL bit for pauth, SVE access, BTI trap syndromesPeter Maydell
The syndrome register value always has an IL field at bit 25, which is 0 for a trap on a 16 bit instruction, and 1 for a trap on a 32 bit instruction (or for exceptions which aren't traps on a known instruction, like PC alignment faults). This means that our syn_*() functions should always either take an is_16bit argument to determine whether to set the IL bit, or else unconditionally set it. We missed setting the IL bit for the syndrome for three kinds of trap: * an SVE access exception * a pointer authentication check failure * a BTI (branch target identification) check failure All of these traps are AArch64 only, and so the instruction causing the trap is always 64 bit. This means we can unconditionally set the IL bit in the syn_*() function. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20231120150121.3458408-1-peter.maydell@linaro.org Cc: qemu-stable@nongnu.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 11a3c4a286d5dc603582ea0a1fca62c2ec0a1aee) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-11-29target/riscv/cpu_helper.c: Fix mxr bit behaviorIvan Klokov
According to RISCV Specification sect 9.5 on two stage translation when V=1 the vsstatus(mstatus in QEMU's terms) field MXR, which makes execute-only pages readable, only overrides VS-stage page protection. Setting MXR at HS-level(mstatus_hs), however, overrides both VS-stage and G-stage execute-only permissions. The hypervisor extension changes the behavior of MXR\MPV\MPRV bits. Due to RISCV Specification sect. 9.4.1 when MPRV=1, explicit memory accesses are translated and protected, and endianness is applied, as though the current virtualization mode were set to MPV and the current nominal privilege mode were set to MPP. vsstatus.MXR makes readable those pages marked executable at the VS translation stage. Fixes: 36a18664ba ("target/riscv: Implement second stage MMU") Signed-off-by: Ivan Klokov <ivan.klokov@syntacore.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231121071757.7178-3-ivan.klokov@syntacore.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 6bca4d7d1ff2b8857486c3ff31f5c6fc3e3984b4) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-11-29target/riscv/cpu_helper.c: Invalid exception on MMU translation stageIvan Klokov
According to RISCV privileged spec sect. 5.3.2 Virtual Address Translation Process access-fault exceptions may raise only after PMA/PMP check. Current implementation generates an access-fault for mbare mode even if there were no PMA/PMP errors. This patch removes the erroneous MMU mode check and generates an access-fault exception based on the pmp_violation flag only. Fixes: 1448689c7b ("target/riscv: Allow specifying MMU stage") Signed-off-by: Ivan Klokov <ivan.klokov@syntacore.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231121071757.7178-2-ivan.klokov@syntacore.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 82d53adfbb1aa0dbe7dac09b61ad86014efe81a7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-11-22target/arm: Fix SME FMOPA (16-bit), BFMOPARichard Henderson
Perform the loop increment unconditionally, not nested within the predication. Cc: qemu-stable@nongnu.org Fixes: 3916841ac75 ("target/arm: Implement FMOPA, FMOPS (widening)") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1985 Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20231117193135.1180657-1-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 3efd8495735c69b863476e9003e624877382a72d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-11-19target/arm: HVC at EL3 should go to EL3, not EL2Peter Maydell
AArch64 permits code at EL3 to use the HVC instruction; however the exception we take should go to EL3, not down to EL2 (see the pseudocode AArch64.CallHypervisor()). Fix the target EL. Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Edgar E. Iglesias <edgar@zeroasic.com> Message-id: 20231109151917.1925107-1-peter.maydell@linaro.org (cherry picked from commit fc58891d0422607d172a3d6b3158798f2556aef1) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-11-19target/riscv/kvm: support KVM_GET_REG_LISTDaniel Henrique Barboza
KVM for RISC-V started supporting KVM_GET_REG_LIST in Linux 6.6. It consists of a KVM ioctl() that retrieves a list of all available regs for get_one_reg/set_one_reg. Regs that aren't present in the list aren't supported in the host. This simplifies our lives when initing the KVM regs since we don't have to always attempt a KVM_GET_ONE_REG for all regs QEMU knows. We'll only attempt a get_one_reg() if we're sure the reg is supported, i.e. it was retrieved by KVM_GET_REG_LIST. Any error in get_one_reg() will then always considered fatal, instead of having to handle special error codes that might indicate a non-fatal failure. Start by moving the current kvm_riscv_init_multiext_cfg() logic into a new kvm_riscv_read_multiext_legacy() helper. We'll prioritize using KVM_GET_REG_LIST, so check if we have it available and, in case we don't, use the legacy() logic. Otherwise, retrieve the available reg list and use it to check if the host supports our known KVM regs, doing the usual get_one_reg() for the supported regs and setting cpu->cfg accordingly. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20231003132148.797921-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 608bdebb6075b757e5505f6bbc60c45a54a1390b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: trivial context tweak in target/riscv/kvm.c)
2023-11-19target/riscv/kvm: improve 'init_multiext_cfg' error msgDaniel Henrique Barboza
Our error message is returning the value of 'ret', which will be always -1 in case of error, and will not be that useful: qemu-system-riscv64: Unable to read ISA_EXT KVM register ssaia, error -1 Improve the error message by outputting 'errno' instead of 'ret'. Use strerrorname_np() to output the error name instead of the error code. This will give us what we need to know right away: qemu-system-riscv64: Unable to read ISA_EXT KVM register ssaia, error code: ENOENT Given that we're going to exit(1) in this condition instead of attempting to recover, remove the 'kvm_riscv_destroy_scratch_vcpu()' call. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20231003132148.797921-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 082e9e4a58ba80ec056220a2f762a1c6b9a3a96c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-11-19target/s390x: Fix LAALG not updating cc_srcIlya Leoshkevich
LAALG uses op_laa() and wout_addu64(). The latter expects cc_src to be set, but the former does not do it. This can lead to assertion failures if something sets cc_src to neither 0 nor 1 before. Fix by introducing op_laa_addu64(), which sets cc_src, and using it for LAALG. Fixes: 4dba4d6fef61 ("target/s390x: Use atomic operations for LOAD AND OP") Cc: qemu-stable@nongnu.org Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20231106093605.1349201-4-iii@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit bea402482a8c94389638cbd3d7fe3963fb317f4c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-11-19target/s390x: Fix CLC corrupting cc_srcIlya Leoshkevich
CLC updates cc_src before accessing the second operand; if the latter is inaccessible, the former ends up containing a bogus value. Fix by reading cc_src into a temporary first. Fixes: 4f7403d52b1c ("target-s390: Convert CLC") Closes: https://gitlab.com/qemu-project/qemu/-/issues/1865 Cc: qemu-stable@nongnu.org Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Message-ID: <20231106093605.1349201-2-iii@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit aba2ec341c6d20c8dc3e6ecf87fa7c1a71e30c1e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-11-19target/mips: Fix TX79 LQ/SQ opcodesPhilippe Mathieu-Daudé
The base register address offset is *signed*. Cc: qemu-stable@nongnu.org Fixes: aaaa82a9f9 ("target/mips/tx79: Introduce LQ opcode (Load Quadword)") Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20230914090447.12557-1-philmd@linaro.org> (cherry picked from commit 18f86aecd6a1bea0f78af14587a684ad966d8d3a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-11-19target/mips: Fix MSA BZ/BNZ opcodes displacementPhilippe Mathieu-Daudé
The PC offset is *signed*. Cc: qemu-stable@nongnu.org Reported-by: Sergey Evlashev <vectorchiefrocks@gmail.com> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1624 Fixes: c7a9ef7517 ("target/mips: Introduce decode tree bindings for MSA ASE") Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20230914085807.12241-1-philmd@linaro.org> (cherry picked from commit 04591b3ddd9a96b9298a1dd437a6464ab55e62ee) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-11-09target/arm: Fix A64 LDRA immediate decodePeter Maydell
In commit be23a049 in the conversion to decodetree we broke the decoding of the immediate value in the LDRA instruction. This should be a 10 bit signed value that is scaled by 8, but in the conversion we incorrectly ended up scaling it only by 2. Fix the scaling factor. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1970 Fixes: be23a049 ("target/arm: Convert load (pointer auth) insns to decodetree") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20231106113445.1163063-1-peter.maydell@linaro.org (cherry picked from commit 5722fc471296d5f042df4b005a851cc8008df0c9) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-11-09hw/xen: select kernel mode for per-vCPU event channel upcall vectorDavid Woodhouse
A guest which has configured the per-vCPU upcall vector may set the HVM_PARAM_CALLBACK_IRQ param to fairly much anything other than zero. For example, Linux v6.0+ after commit b1c3497e604 ("x86/xen: Add support for HVMOP_set_evtchn_upcall_vector") will just do this after setting the vector: /* Trick toolstack to think we are enlightened. */ if (!cpu) rc = xen_set_callback_via(1); That's explicitly setting the delivery to GSI#1, but it's supposed to be overridden by the per-vCPU vector setting. This mostly works in Qemu *except* for the logic to enable the in-kernel handling of event channels, which falsely determines that the kernel cannot accelerate GSI delivery in this case. Add a kvm_xen_has_vcpu_callback_vector() to report whether vCPU#0 has the vector set, and use that in xen_evtchn_set_callback_param() to enable the kernel acceleration features even when the param *appears* to be set to target a GSI. Preserve the Xen behaviour that when HVM_PARAM_CALLBACK_IRQ is set to *zero* the event channel delivery is disabled completely. (Which is what that bizarre guest behaviour is working round in the first place.) Cc: qemu-stable@nongnu.org Fixes: 91cce756179 ("hw/xen: Add xen_evtchn device for event channel emulation") Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org> (cherry picked from commit 18e83f28bf39ffd2784aeb2e4e229096a86d349b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-11-09i386/xen: fix per-vCPU upcall vector for Xen emulationDavid Woodhouse
The per-vCPU upcall vector support had three problems. Firstly it was using the wrong hypercall argument and would always return -EFAULT when the guest tried to set it up. Secondly it was using the wrong ioctl() to pass the vector to the kernel and thus the *kernel* would always return -EINVAL. Finally, even when delivering the event directly from userspace with an MSI, it put the destination CPU ID into the wrong bits of the MSI address. Linux doesn't (yet) use this mode so it went without decent testing for a while. Cc: qemu-stable@nongnu.org Fixes: 105b47fdf2d0 ("i386/xen: implement HVMOP_set_evtchn_upcall_vector") Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org> (cherry picked from commit e7dbb62ff19ce55548c785d76e814e7b144e6217) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-11-09i386/xen: Don't advertise XENFEAT_supervisor_mode_kernelDavid Woodhouse
This confuses lscpu into thinking it's running in PVH mode. Cc: qemu-stable@nongnu.org Fixes: bedcc139248 ("i386/xen: implement HYPERVISOR_xen_version") Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org> (cherry picked from commit e969f992c6562222e245dd8557f5b132a11ec29c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-11-09target/arm: Correctly propagate stage 1 BTI guarded bit in a two-stage walkPeter Maydell
In a two-stage translation, the result of the BTI guarded bit should be the guarded bit from the first stage of translation, as there is no BTI guard information in stage two. Our code tried to do this, but got it wrong, because we currently have two fields where the GP bit information might live (ARMCacheAttrs::guarded and CPUTLBEntryFull::extra::arm::guarded), and we were storing the GP bit in the latter during the stage 1 walk but trying to copy the former in combine_cacheattrs(). Remove the duplicated storage, and always use the field in CPUTLBEntryFull; correctly propagate the stage 1 value to the output in get_phys_addr_twostage(). Note for stable backports: in v8.0 and earlier the field is named result->f.guarded, not result->f.extra.arm.guarded. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1950 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20231031173723.26582-1-peter.maydell@linaro.org (cherry picked from commit 4c09abeae8704970ff03bf2196973f6bf08ab6f9) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: replace f.extra.arm.guarded -> f.guarded due to v8.1.0-1179-ga81fef4b64)
2023-11-09target/arm: Fix SVE STR incrementRichard Henderson
The previous change missed updating one of the increments and one of the MemOps. Add a test case for all vector lengths. Cc: qemu-stable@nongnu.org Fixes: e6dd5e782be ("target/arm: Use tcg_gen_qemu_{ld, st}_i128 in gen_sve_{ld, st}r") Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20231031143215.29764-1-richard.henderson@linaro.org [PMM: fixed checkpatch nit] Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit b11293c212c2927fcea1befc50dabec9baba4fcc) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: context fix in tests/tcg/aarch64/Makefile.target) Tested-by: Alex Bennée <alex.bennee@linaro.org>
2023-10-31target/arm: Fix syndrome for FGT traps on ERETPeter Maydell
In commit 442c9d682c94fc2 when we converted the ERET, ERETAA, ERETAB instructions to decodetree, the conversion accidentally lost the correct setting of the syndrome register when taking a trap because of the FEAT_FGT HFGITR_EL1.ERET bit. Instead of reporting a correct full syndrome value with the EC and IL bits, we only reported the low two bits of the syndrome, because the call to syn_erettrap() got dropped. Fix the syndrome values for these traps by reinstating the syn_erettrap() calls. Fixes: 442c9d682c94fc2 ("target/arm: Convert ERET, ERETAA, ERETAB to decodetree") Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20231024172438.2990945-1-peter.maydell@linaro.org (cherry picked from commit 307521d6e29e559c89afa9dbd337ae75fe3c436d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-10-29target/sparc: Clear may_lookup for npc == DYNAMIC_PCRichard Henderson
With pairs of jmp+rett, pc == DYNAMIC_PC_LOOKUP and npc == DYNAMIC_PC. Make sure that we exit for interrupts. Cc: qemu-stable@nongnu.org Fixes: 633c42834c7 ("target/sparc: Introduce DYNAMIC_PC_LOOKUP") Tested-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Acked-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit 930f1865cc654b637ffe1207fa5b44bf0a156279) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-10-21target/arm: Fix CNTPCT_EL0 trapping from EL0 when HCR_EL2.E2H is 0Michal Orzel
On an attempt to access CNTPCT_EL0 from EL0 using a guest running on top of Xen, a trap from EL2 was observed which is something not reproducible on HW (also, Xen does not trap accesses to physical counter). This is because gt_counter_access() checks for an incorrect bit (1 instead of 0) of CNTHCTL_EL2 if HCR_EL2.E2H is 0 and access is made to physical counter. Refer ARM ARM DDI 0487J.a, D19.12.2: When HCR_EL2.E2H is 0: - EL1PCTEN, bit [0]: refers to physical counter - EL1PCEN, bit [1]: refers to physical timer registers Drop entire block "if (hcr & HCR_E2H) {...} else {...}" from EL0 case and fall through to EL1 case, given that after fixing checking for the correct bit, the handling is the same. Fixes: 5bc8437136fb ("target/arm: Update timer access for VHE") Signed-off-by: Michal Orzel <michal.orzel@amd.com> Tested-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> Message-id: 20230928094404.20802-1-michal.orzel@amd.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit d01448c79d89cfdc86228081b1dd1dfaf85fb4c3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-10-19target/hexagon: avoid invalid escape in Python stringPaolo Bonzini
This is an error in Python 3.12; fix it by using a raw string literal. Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit e41c40d101fce79af4d679955eb6e0d31e02c47c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-10-13target/riscv: Fix vfwmaccbf16.vfMax Chou
The operator (fwmacc16) of vfwmaccbf16.vf helper function should be replaced by fwmaccbf16. Fixes: adf772b0f7 ("target/riscv: Add support for Zvfbfwma extension") Signed-off-by: Max Chou <max.chou@sifive.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20231005095734.567575-1-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 837570cef237b634eb4c245363470deebea7089d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-10-04target/i386: fix memory operand size for CVTPS2PDPaolo Bonzini
CVTPS2PD only loads a half-register for memory, unlike the other operations under 0x0F 0x5A. "Unpack" the group into separate emission functions instead of using gen_unary_fp_sse. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit abd41884c530aa025ada253bf1a5bd0c2b808219) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-10-04target/i386: generalize operand size "ph" for use in CVTPS2PDPaolo Bonzini
CVTPS2PD only loads a half-register for memory, like CVTPH2PS. It can reuse the "ph" packed half-precision size to load a half-register, but rename it to "xh" because it is now a variation of "x" (it is not used only for half-precision values). Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit a48b26978a090fe1f3f3e54319902d4ab56a6b3a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-10-03target/tricore: Fix RCPW/RRPW_INSERT insns for width = 0Bastian Koppelmann
we would crash if width was 0 for these insns, as tcg_gen_deposit() is undefined for that case. For TriCore, width = 0 is a mov from the src reg to the dst reg, so we special case this here. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> Message-ID: <20230828112651.522058-9-kbastian@mail.uni-paderborn.de> (cherry picked from commit 23fa6f56b33f8fddf86ba4d027fb7d3081440cd9) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-10-03accel/tcg: Always require can_do_ioRichard Henderson
Require i/o as the last insn of a TranslationBlock always, not only with icount. This is required for i/o that alters the address space, such as a pci config space write. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1866 Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit 18a536f1f8d6222e562f59179e837fdfd8b92718) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-10-03target/arm: Don't skip MTE checks for LDRT/STRT at EL0Peter Maydell
The LDRT/STRT "unprivileged load/store" instructions behave like normal ones if executed at EL0. We handle this correctly for the load/store semantics, but get the MTE checking wrong. We always look at s->mte_active[is_unpriv] to see whether we should be doing MTE checks, but in hflags.c when we set the TB flags that will be used to fill the mte_active[] array we only set the MTE0_ACTIVE bit if UNPRIV is true (i.e. we are not at EL0). This means that a LDRT at EL0 will see s->mte_active[1] as 0, and will not do MTE checks even when MTE is enabled. To avoid the translate-time code having to do an explicit check on s->unpriv to see if it is OK to index into the mte_active[] array, duplicate MTE_ACTIVE into MTE0_ACTIVE when UNPRIV is false. (This isn't a very serious bug because generally nobody executes LDRT/STRT at EL0, because they have no use there.) Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20230912140434.1333369-2-peter.maydell@linaro.org (cherry picked from commit 903dbefc2b6918c10d12d9aafa0168cee8d287c7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-21target/riscv: Allocate itrigger timers only onceAkihiko Odaki
riscv_trigger_init() had been called on reset events that can happen several times for a CPU and it allocated timers for itrigger. If old timers were present, they were simply overwritten by the new timers, resulting in a memory leak. Divide riscv_trigger_init() into two functions, namely riscv_trigger_realize() and riscv_trigger_reset() and call them in appropriate timing. The timer allocation will happen only once for a CPU in riscv_trigger_realize(). Fixes: 5a4ae64cac ("target/riscv: Add itrigger support when icount is enabled") Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230818034059.9146-1-akihiko.odaki@daynix.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit a7c272df82af11c568ea83921b04334791dccd5e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-21target/riscv/pmp.c: respect mseccfg.RLB for pmpaddrX changesLeon Schuermann
When the rule-lock bypass (RLB) bit is set in the mseccfg CSR, the PMP configuration lock bits must not apply. While this behavior is implemented for the pmpcfgX CSRs, this bit is not respected for changes to the pmpaddrX CSRs. This patch ensures that pmpaddrX CSR writes work even on locked regions when the global rule-lock bypass is enabled. Signed-off-by: Leon Schuermann <leons@opentitan.org> Reviewed-by: Mayuresh Chitale <mchitale@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230829215046.1430463-1-leon@is.currently.online> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 4e3adce1244e1ca30ec05874c3eca14911dc0825) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-21target/riscv: fix satp_mode_finalize() when satp_mode.supported = 0Daniel Henrique Barboza
In the same emulated RISC-V host, the 'host' KVM CPU takes 4 times longer to boot than the 'rv64' KVM CPU. The reason is an unintended behavior of riscv_cpu_satp_mode_finalize() when satp_mode.supported = 0, i.e. when cpu_init() does not set satp_mode_max_supported(). satp_mode_max_from_map(map) does: 31 - __builtin_clz(map) This means that, if satp_mode.supported = 0, satp_mode_supported_max wil be '31 - 32'. But this is C, so satp_mode_supported_max will gladly set it to UINT_MAX (4294967295). After that, if the user didn't set a satp_mode, set_satp_mode_default_map(cpu) will make cfg.satp_mode.map = cfg.satp_mode.supported So satp_mode.map = 0. And then satp_mode_map_max will be set to satp_mode_max_from_map(cpu->cfg.satp_mode.map), i.e. also UINT_MAX. The guard "satp_mode_map_max > satp_mode_supported_max" doesn't protect us here since both are UINT_MAX. And finally we have 2 loops: for (int i = satp_mode_map_max - 1; i >= 0; --i) { Which are, in fact, 2 loops from UINT_MAX -1 to -1. This is where the extra delay when booting the 'host' CPU is coming from. Commit 43d1de32f8 already set a precedence for satp_mode.supported = 0 in a different manner. We're doing the same here. If supported == 0, interpret as 'the CPU wants the OS to handle satp mode alone' and skip satp_mode_finalize(). We'll also put a guard in satp_mode_max_from_map() to assert out if map is 0 since the function is not ready to deal with it. Cc: Alexandre Ghiti <alexghiti@rivosinc.com> Fixes: 6f23aaeb9b ("riscv: Allow user to set the satp mode") Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230817152903.694926-1-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 3a2fc23563885c219c73c8f24318921daf02f3f2) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-21target/riscv: Fix zfa fleq.d and fltq.dLIU Zhiwei
Commit a47842d ("riscv: Add support for the Zfa extension") implemented the zfa extension. However, it has some typos for fleq.d and fltq.d. Both of them misused the fltq.s helper function. Fixes: a47842d ("riscv: Add support for the Zfa extension") Signed-off-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Message-ID: <20230728003906.768-1-zhiwei_liu@linux.alibaba.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit eda633a534f8af4abe3a88731bba6dacdb973993) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-21target/riscv: Fix page_check_range use in fault-only-firstLIU Zhiwei
Commit bef6f008b98(accel/tcg: Return bool from page_check_range) converts integer return value to bool type. However, it wrongly converted the use of the API in riscv fault-only-first, where page_check_range < = 0, should be converted to !page_check_range. Signed-off-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20230729031618.821-1-zhiwei_liu@linux.alibaba.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 4cc9f284d5971ecd8055d26ef74c23ef0be8b8f5) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-21target/riscv/cpu.c: add zmmul isa stringDaniel Henrique Barboza
zmmul was promoted from experimental to ratified in commit 6d00ffad4e95. Add a riscv,isa string for it. Fixes: 6d00ffad4e95 ("target/riscv: move zmmul out of the experimental properties") Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230720132424.371132-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 50f9464962fb41f04fd5f42e7ee2cb60942aba89) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-21arm64: Restore trapless ptimer accessColton Lewis
Due to recent KVM changes, QEMU is setting a ptimer offset resulting in unintended trap and emulate access and a consequent performance hit. Filter out the PTIMER_CNT register to restore trapless ptimer access. Quoting Andrew Jones: Simply reading the CNT register and writing back the same value is enough to set an offset, since the timer will have certainly moved past whatever value was read by the time it's written. QEMU frequently saves and restores all registers in the get-reg-list array, unless they've been explicitly filtered out (with Linux commit 680232a94c12, KVM_REG_ARM_PTIMER_CNT is now in the array). So, to restore trapless ptimer accesses, we need a QEMU patch to filter out the register. See https://lore.kernel.org/kvmarm/gsntttsonus5.fsf@coltonlewis-kvm.c.googlers.com/T/#m0770023762a821db2a3f0dd0a7dc6aa54e0d0da9 for additional context. Cc: qemu-stable@nongnu.org Signed-off-by: Andrew Jones <andrew.jones@linux.dev> Signed-off-by: Colton Lewis <coltonlewis@google.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Colton Lewis <coltonlewis@google.com> Message-id: 20230831190052.129045-1-coltonlewis@google.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 682814e2a3c883b27f24b9e7cab47313c49acbd4) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-21target/ppc: Fix LQ, STQ register-pair order for big-endianNicholas Piggin
LQ, STQ have the same register-pair ordering as LQARX/STQARX., which is the even (lower) register contains the most significant bits. This is not implemented correctly for big-endian. do_ldst_quad() has variables low_addr_gpr and high_addr_gpr which is confusing because they are low and high addresses, whereas LQARX/STQARX. and most such things use the low and high values for lo/hi variables. The conversion to native 128-bit memory access functions missed this strangeness. Fix this by changing the if condition, and change the variable names to hi/lo to match convention. Cc: qemu-stable@nongnu.org Reported-by: Ivan Warren <ivan@vmfacility.fr> Fixes: 57b38ffd0c6f ("target/ppc: Use tcg_gen_qemu_{ld,st}_i128 for LQARX, LQ, STQ") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1836 Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> (cherry picked from commit 718209358f2e4f231cbacf974c3299c4fe7beb83) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-21target/ppc: Flush inputs to zero with NJ in ppc_store_vscrRichard Henderson
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1779 Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> (cherry picked from commit af03aeb631eeb81a44d2c0ff5b429cd4b5dc2799) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-21target/i386: raise FERR interrupt with iothread lockedPaolo Bonzini
Otherwise tcg_handle_interrupt() triggers an assertion failure: #5 0x0000555555c97369 in tcg_handle_interrupt (cpu=0x555557434cb0, mask=2) at ../accel/tcg/tcg-accel-ops.c:83 #6 tcg_handle_interrupt (cpu=0x555557434cb0, mask=2) at ../accel/tcg/tcg-accel-ops.c:81 #7 0x0000555555b4d58b in pic_irq_request (opaque=<optimized out>, irq=<optimized out>, level=1) at ../hw/i386/x86.c:555 #8 0x0000555555b4f218 in gsi_handler (opaque=0x5555579423d0, n=13, level=1) at ../hw/i386/x86.c:611 #9 0x00007fffa42bde14 in code_gen_buffer () #10 0x0000555555c724bb in cpu_tb_exec (cpu=cpu@entry=0x555557434cb0, itb=<optimized out>, tb_exit=tb_exit@entry=0x7fffe9bfd658) at ../accel/tcg/cpu-exec.c:457 Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1808 Reported-by: NyanCatTW1 <https://gitlab.com/a0939712328> Co-developed-by: Richard Henderson <richard.henderson@linaro.org>' Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit c1f27a0c6ae4059a1d809e9c2bc4d47b823c32a3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-21target/arm: properly document FEAT_CRC32Alex Bennée
This is a mandatory feature for Armv8.1 architectures but we don't state the feature clearly in our emulation list. Also include FEAT_CRC32 comment in aarch64_max_tcg_initfn for ease of grepping. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20230824075406.1515566-1-alex.bennee@linaro.org Cc: qemu-stable@nongnu.org Message-Id: <20230222110104.3996971-1-alex.bennee@linaro.org> [PMM: pluralize 'instructions' in docs] Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 9e771a2fc68d98c5719b877e008d1dca64e6896e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
generated by cgit v1.2.3 (git 2.26.2) at 2025-02-27 02:45:10 +0000