aboutsummaryrefslogtreecommitdiff
path: root/hw/intc
AgeCommit message (Collapse)Author
2022-07-28hw/intc: sifive_plic: Fix multi-socket plic configuraitonAtish Patra
Since commit 40244040a7ac, multi-socket configuration with plic is broken as the hartid for second socket is calculated incorrectly. The hartid stored in addr_config already includes the offset for the base hartid for that socket. Adding it again would lead to segfault while creating the plic device for the virt machine. qdev_connect_gpio_out was also invoked with incorrect number of gpio lines. Fixes: 40244040a7ac (hw/intc: sifive_plic: Avoid overflowing the addr_config buffer) Signed-off-by: Atish Patra <atishp@rivosinc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20220723090335.671105-1-atishp@rivosinc.com> [ Changes by AF: - Change the qdev_connect_gpio_out() numbering ] Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-07-19hw/intc/loongarch_pch_pic: Fix bugs for update_irq functionXiaojuan Yang
Fix such errors: 1. We should not use 'unsigned long' type as argument when we use find_first_bit(), and we use ctz64() to replace find_first_bit() to fix this bug. 2. It is not standard to use '1ULL << irq' to generate a irq mask. So, we replace it with 'MAKE_64BIT_MASK(irq, 1)'. Fix coverity CID: 1489761 1489764 1489765 Signed-off-by: Xiaojuan Yang <yangxiaojuan@loongson.cn> Message-Id: <20220715060740.1500628-3-yangxiaojuan@loongson.cn> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2022-07-18ppc64: Allocate IRQ lines with qdev_init_gpio_in()Cédric Le Goater
This replaces the IRQ array 'irq_inputs' with GPIO lines, the goal being to remove 'irq_inputs' when all CPUs have been converted. Signed-off-by: Cédric Le Goater <clg@kaod.org> Acked-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20220705145814.461723-2-clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-07-18hw/intc/armv7m_nvic: ICPRn must not unpend an IRQ that is being held highPeter Maydell
In the M-profile Arm ARM, rule R_CVJS defines when an interrupt should be set to the Pending state: A) when the input line is high and the interrupt is not Active B) when the input line transitions from low to high and the interrupt is Active (Note that the first of these is an ongoing condition, and the second is a point-in-time event.) This can be rephrased as: 1 when the line goes from low to high, set Pending 2 when Active goes from 1 to 0, if line is high then set Pending 3 ignore attempts to clear Pending when the line is high and Active is 0 where 1 covers both B and one of the "transition into condition A" cases, 2 deals with the other "transition into condition A" possibility, and 3 is "don't drop Pending if we're already in condition A". Transitions out of condition A don't affect Pending state. We handle case 1 in set_irq_level(). For an interrupt (as opposed to other kinds of exception) the only place where we clear Active is in armv7m_nvic_complete_irq(), where we handle case 2 by checking for whether we need to re-pend the exception. For case 3, the only places where we clear Pending state on an interrupt are in armv7m_nvic_acknowledge_irq() (where we are setting Active so it doesn't count) and for writes to NVIC_ICPRn. It is the "write to NVIC_ICPRn" case that we missed: we must ignore this if the input line is high and the interrupt is not Active. (This required behaviour is differently and perhaps more clearly stated in the v7M Arm ARM, which has pseudocode in section B3.4.1 that implies it.) Reported-by: Igor Kotrasiński <i.kotrasinsk@samsung.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20220628154724.3297442-1-peter.maydell@linaro.org
2022-07-06ppc: Define SETFIELD for the ppc targetAlexey Kardashevskiy
It keeps repeating, move it to the header. This uses __builtin_ffsll() to allow using the macros in #define. This is not using the QEMU's FIELD macros as this would require changing all such macros found in skiboot (the PPC PowerNV firmware). Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220628080544.1509428-1-aik@ozlabs.ru> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-07-05hw/intc/loongarch_ipi: Fix mail send and any send functionXiaojuan Yang
By the document of ipi mailsend device, byte is written only when the mask bit is 0. The original code discards mask bit and overwrite the data always, this patch fixes the issue. Signed-off-by: Xiaojuan Yang <yangxiaojuan@loongson.cn> Message-Id: <20220705064901.2353349-3-yangxiaojuan@loongson.cn> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2022-07-05hw/intc/loongarch_ipi: Fix ipi device access of 64bitsXiaojuan Yang
In general loongarch ipi device, 32bit registers is emulated, however for anysend/mailsend device only 64bit register access is supported. So separate the ipi memory region into two regions, including 32 bits and 64 bits. Signed-off-by: Xiaojuan Yang <yangxiaojuan@loongson.cn> Message-Id: <20220705064901.2353349-2-yangxiaojuan@loongson.cn> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2022-07-04hw/intc/loongarch_pch_msi: Fix msi vector convertionMao Bibo
Loongarch pch msi intc connects to extioi controller, the range of irq number is 64-255. Add a property for irqbase, so that we can compute the irq offset from the view of pch_msi controller with the method: msi vector (from view of upper extioi intc) - irqbase Signed-off-by: Mao Bibo <maobibo@loongson.cn> Message-Id: <20220701030740.2469162-1-maobibo@loongson.cn> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2022-06-28Trivial: 3 char repeat typosDr. David Alan Gilbert
Inspired by Julia Lawall's fixing of Linux kernel comments, I looked at qemu, although I did it manually. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Klaus Jensen <k.jensen@samsung.com> Message-Id: <20220614104045.85728-2-dgilbert@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2022-06-20pnv/xive2: Access direct mapped thread contexts from all chipsFrederic Barrat
When accessing a thread context through the IC BAR, the offset of the page in the BAR identifies the CPU. From that offset, we can compute the PIR (processor ID register) of the CPU to do the data structure lookup. On P10, the current code assumes an access for node 0 when computing the PIR. Everything is almost in place to allow access for other nodes though. So this patch reworks how the PIR value is computed so that we can access all thread contexts through the IC BAR. The PIR is already correct on P9, so no need to modify anything there. Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220602165310.558810-1-fbarrat@linux.ibm.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-06-10hw/intc: sifive_plic: Avoid overflowing the addr_config bufferAlistair Francis
Since commit ad40be27 "target/riscv: Support start kernel directly by KVM" we have been overflowing the addr_config on "M,MS..." configurations, as reported https://gitlab.com/qemu-project/qemu/-/issues/1050. This commit changes the loop in sifive_plic_create() from iterating over the number of harts to just iterating over the addr_config. The addr_config is based on the hart_config, and will contain interrup details for all harts. This way we can't iterate past the end of addr_config. Fixes: ad40be27084536 ("target/riscv: Support start kernel directly by KVM") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1050 Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220601013631.196854-1-alistair.francis@opensource.wdc.com>
2022-06-08Fix 'writeable' typosPeter Maydell
We have about 30 instances of the typo/variant spelling 'writeable', and over 500 of the more common 'writable'. Standardize on the latter. Change produced with: sed -i -e 's/\([Ww][Rr][Ii][Tt]\)[Ee]\([Aa][Bb][Ll][Ee]\)/\1\2/g' $(git grep -il writeable) and then hand-undoing the instance in linux-headers/linux/kvm.h. Most of these changes are in comments or documentation; the exceptions are: * a local variable in accel/hvf/hvf-accel-ops.c * a local variable in accel/kvm/kvm-all.c * the PMCR_WRITABLE_MASK macro in target/arm/internals.h * the EPT_VIOLATION_GPA_WRITABLE macro in target/i386/hvf/vmcs.h (which is never used anywhere) * the AR_TYPE_WRITABLE_MASK macro in target/i386/hvf/vmx.h (which is never used anywhere) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Stefan Weil <sw@weilnetz.de> Message-id: 20220505095015.2714666-1-peter.maydell@linaro.org
2022-06-06hw/intc: Add LoongArch extioi interrupt controller(EIOINTC)Xiaojuan Yang
This patch realize the EIOINTC interrupt controller. Signed-off-by: Xiaojuan Yang <yangxiaojuan@loongson.cn> Signed-off-by: Song Gao <gaosong@loongson.cn> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220606124333.2060567-35-yangxiaojuan@loongson.cn> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2022-06-06hw/intc: Add LoongArch ls7a msi interrupt controller support(PCH-MSI)Xiaojuan Yang
This patch realize PCH-MSI interrupt controller. Signed-off-by: Xiaojuan Yang <yangxiaojuan@loongson.cn> Signed-off-by: Song Gao <gaosong@loongson.cn> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220606124333.2060567-34-yangxiaojuan@loongson.cn> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2022-06-06hw/intc: Add LoongArch ls7a interrupt controller support(PCH-PIC)Xiaojuan Yang
This patch realize the PCH-PIC interrupt controller. Signed-off-by: Xiaojuan Yang <yangxiaojuan@loongson.cn> Signed-off-by: Song Gao <gaosong@loongson.cn> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220606124333.2060567-33-yangxiaojuan@loongson.cn> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2022-06-06hw/loongarch: Add LoongArch ipi interrupt support(IPI)Xiaojuan Yang
This patch realize the IPI interrupt controller. Signed-off-by: Xiaojuan Yang <yangxiaojuan@loongson.cn> Signed-off-by: Song Gao <gaosong@loongson.cn> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220606124333.2060567-32-yangxiaojuan@loongson.cn> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2022-05-26pnv/xive2: Don't overwrite PC registers when writing TCTXT registersFrederic Barrat
When writing a register from the TCTXT memory region (4th page within the IC BAR), we were overwriting the Presentation Controller (PC) register at the same offset. It looks like a silly cut and paste error. We were somehow lucky: the TCTXT registers being touched are TCTXT_ENx/_SET/_RESET to enable physical threads and the PC registers at the same offset are either not used by our model or the update was harmless. Found through code inspection. Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220523151859.72283-1-fbarrat@linux.ibm.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-24hw/intc: Pass correct hartid while updating mtimecmpAtish Patra
timecmp update function should be invoked with hartid for which timecmp is being updated. The following patch passes the incorrect hartid to the update function. Fixes: e2f01f3c2e13 ("hw/intc: Make RISC-V ACLINT mtime MMIO register writable") Signed-off-by: Atish Patra <atishp@rivosinc.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Anup Patel <anup@brainfault.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20220513221458.1192933-1-atishp@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-05-19hw/intc/arm_gicv3: Provide ich_num_aprs()Peter Maydell
We previously open-coded the expression for the number of virtual APR registers and the assertion that it was not going to cause us to overflow the cs->ich_apr[] array. Factor this out into a new ich_num_aprs() function, for consistency with the icc_num_aprs() function we just added for the physical APR handling. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220512151457.3899052-7-peter.maydell@linaro.org Message-id: 20220506162129.2896966-6-peter.maydell@linaro.org
2022-05-19hw/intc/arm_gicv3: Use correct number of priority bits for the CPUPeter Maydell
Make the GICv3 set its number of bits of physical priority from the implementation-specific value provided in the CPU state struct, in the same way we already do for virtual priority bits. Because this would be a migration compatibility break, we provide a property force-8-bit-prio which is enabled for 7.0 and earlier versioned board models to retain the legacy "always use 8 bits" behaviour. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220512151457.3899052-6-peter.maydell@linaro.org Message-id: 20220506162129.2896966-5-peter.maydell@linaro.org
2022-05-19hw/intc/arm_gicv3: Support configurable number of physical priority bitsPeter Maydell
The GICv3 code has always supported a configurable number of virtual priority and preemption bits, but our implementation currently hardcodes the number of physical priority bits at 8. This is not what most hardware implementations provide; for instance the Cortex-A53 provides only 5 bits of physical priority. Make the number of physical priority/preemption bits driven by fields in the GICv3CPUState, the way that we already do for virtual priority/preemption bits. We set cs->pribits to 8, so there is no behavioural change in this commit. A following commit will add the machinery for CPUs to set this to the correct value for their implementation. Note that changing the number of priority bits would be a migration compatibility break, because the semantics of the icc_apr[][] array changes. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220512151457.3899052-5-peter.maydell@linaro.org Message-id: 20220506162129.2896966-4-peter.maydell@linaro.org
2022-05-19hw/intc/arm_gicv3_kvm.c: Stop using GIC_MIN_BPR constantPeter Maydell
The GIC_MIN_BPR constant defines the minimum BPR value that the TCG emulated GICv3 supports. We're currently using this also as the value we reset the KVM GICv3 ICC_BPR registers to, but this is only right by accident. We want to make the emulated GICv3 use a configurable number of priority bits, which means that GIC_MIN_BPR will no longer be a constant. Replace the uses in the KVM reset code with literal 0, plus a constant explaining why this is reasonable. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220512151457.3899052-4-peter.maydell@linaro.org Message-id: 20220506162129.2896966-3-peter.maydell@linaro.org
2022-05-19hw/intc/arm_gicv3: report correct PRIbits field in ICV_CTLR_EL1Peter Maydell
As noted in the comment, the PRIbits field in ICV_CTLR_EL1 is supposed to match the ICH_VTR_EL2 PRIbits setting; that is, it is the virtual priority bit setting, not the physical priority bit setting. (For QEMU currently we always implement 8 bits of physical priority, so the PRIbits field was previously 7, since it is defined to be "priority bits - 1".) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220512151457.3899052-3-peter.maydell@linaro.org Message-id: 20220506162129.2896966-2-peter.maydell@linaro.org
2022-05-19hw/intc/arm_gicv3_cpuif: Handle CPUs that don't specify GICv3 parametersPeter Maydell
We allow a GICv3 to be connected to any CPU, but we don't do anything to handle the case where the CPU type doesn't in hardware have a GICv3 CPU interface and so the various GIC configuration fields (gic_num_lrs, vprebits, vpribits) are not specified. The current behaviour is that we will add the EL1 CPU interface registers, but will not put in the EL2 CPU interface registers, even if the CPU has EL2, which will leave the GIC in a broken state and probably result in the guest crashing as it tries to set it up. This only affects the virt board when using the cortex-a15 or cortex-a7 CPU types (both 32-bit) with -machine gic-version=3 (or 'max') and -machine virtualization=on. Instead of failing to set up the EL2 registers, if the CPU doesn't define the GIC configuration set it to a reasonable default, matching the standard configuration for most Arm CPUs. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220512151457.3899052-2-peter.maydell@linaro.org
2022-05-05ppc/xive: Update the state of the External interrupt signalFrederic Barrat
When pulling or pushing an OS context from/to a CPU, we should re-evaluate the state of the External interrupt signal. Otherwise, we can end up catching the External interrupt exception in hypervisor mode, which is unexpected. The problem is best illustrated with the following scenario: 1. an External interrupt is raised while the guest is on the CPU. 2. before the guest can ack the External interrupt, an hypervisor interrupt is raised, for example the Hypervisor Decrementer or Hypervisor Virtualization interrupt. The hypervisor interrupt forces the guest to exit while the External interrupt is still pending. 3. the hypervisor handles the hypervisor interrupt. At this point, the External interrupt is still pending. So it's very likely to be delivered while the hypervisor is running. That's unexpected and can result in an infinite loop where the hypervisor catches the External interrupt, looks for an interrupt in its hypervisor queue, doesn't find any, exits the interrupt handler with the External interrupt still raised, repeat... The fix is simply to always lower the External interrupt signal when pulling an OS context. It means it needs to be raised again when re-pushing the OS context. Fortunately, it's already the case, as we now always call xive_tctx_ipb_update(), which will raise the signal if needed. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220429071620.177142-3-fbarrat@linux.ibm.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-05ppc/xive: Always recompute the PIPR when pushing an OS contextFrederic Barrat
The Post Interrupt Priority Register (PIPR) is not restored like the other OS-context related fields of the TIMA when pushing an OS context on the CPU. It's not needed because it can be calculated from the Interrupt Pending Buffer (IPB), which is saved and restored. The PIPR must therefore always be recomputed when pushing an OS context. This patch fixes a path on P9 and P10 where it was not done. If there was a pending interrupt when the OS context was pulled, the IPB was saved correctly. When pushing back the context, the code in xive_tctx_need_resend() was checking for a interrupt raised while the context was not on the CPU, saved in the NVT. If one was found, then it was merged with the saved IPB and the PIPR updated and everything was fine. However, if there was no interrupt found in the NVT, then xive_tctx_ipb_update() was not being called and the PIPR was not updated. This patch fixes it by always calling xive_tctx_ipb_update(). Note that on P10 (xive2.c) and because of the above, there's no longer any need to check the CPPR value so it can go away. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220429071620.177142-2-fbarrat@linux.ibm.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-05target/arm: Replace sentinels with ARRAY_SIZE in cpregs.hRichard Henderson
Remove a possible source of error by removing REGINFO_SENTINEL and using ARRAY_SIZE (convinently hidden inside a macro) to find the end of the set of regs being registered or modified. The space saved by not having the extra array element reduces the executable's .data.rel.ro section by about 9k. Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220501055028.646596-4-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-05-05target/arm: Split out cpregs.hRichard Henderson
Move ARMCPRegInfo and all related declarations to a new internal header, out of the public cpu.h. Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220501055028.646596-2-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-04-26hw/intc: Vectored Interrupt Controller (VIC)Amir Gonnen
Implement nios2 Vectored Interrupt Controller (VIC). VIC is connected to EIC. It needs to update rha, ril, rrs and rnmi fields on Nios2CPU before raising an IRQ. For that purpose, VIC has a "cpu" property which should refer to the nios2 cpu and set by the board that connects VIC. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Amir Gonnen <amir.gonnen@neuroblade.ai> Message-Id: <20220303153906.2024748-5-amir.gonnen@neuroblade.ai> [rth: Split out nios2_vic.h] Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220421151735.31996-60-richard.henderson@linaro.org>
2022-04-22Merge tag 'pull-target-arm-20220422-1' of ↵Richard Henderson
https://git.linaro.org/people/pmaydell/qemu-arm into staging target-arm queue: * Implement GICv4 emulation * Some cleanup patches in target/arm * hw/arm/smmuv3: Pass the actual perm to returned IOMMUTLBEntry in smmuv3_translate() # -----BEGIN PGP SIGNATURE----- # # iQJNBAABCAA3FiEE4aXFk81BneKOgxXPPCUl7RQ2DN4FAmJisasZHHBldGVyLm1h # eWRlbGxAbGluYXJvLm9yZwAKCRA8JSXtFDYM3vcdEACIcvC8E93tFfeKwDQHSdPx # 7dPCdq+EZc/xEA2U/q282PFtvNBP6zo65RzWKXTkyfE5exLkCmqJqXSIUVfiuTyT # IAx9mL++StpBJMiqAebzEp2n8gwG7JymFeGuHYGet/nRrcwQYacBNxSl+BIVqZAm # mUy2UOlqJDlzMAVOcs/Ikfhj0z3qa52aZ8eF6sQI3mbSggiSIWOhyzNYo7jMB1x7 # UuHlYpvYDltKT7PveA5JSuBP9OmV5RrqqO4s5c22Y+o4k+La/NURDPdegblMfRA9 # MfWAEHqjA1WQaxh/Tb4Bex1u875mFMOXMZk3P910wSeqxMLhTCmjTA2g4p1KhfcA # LQJ5G2IvSA7HN660NLhZAqL601/1tS7Qcl387TfcU7WCDbgmzv2RCvH6UACF2hVl # CH4bC3lKvemT324aOBs/TCnvdu54qR6hkJZ57XSn59QHvrRvrREVdYNfQnl/g751 # GTp8aMcmvTkZ8I7k2t4Tx+CoFO38+rv7PupLN+Eq4k97ovXmAWxekizv8KYu5itY # emg63kItorwCgRwkKP28RKWLS/7dEpoF8sg5jBiBtGBGNG0AWPq4GZdrhaL58cr4 # lr4nSseN2IRsrp3SgM2203RjdghFM8ey1Dq+x2mRp+Q21vVTltI/VSiUSz0c2Vpo # JgbC4Jo+jufMkav31zOCAg== # =jqHX # -----END PGP SIGNATURE----- # gpg: Signature made Fri 22 Apr 2022 06:46:19 AM PDT # gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE # gpg: issuer "peter.maydell@linaro.org" # gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [full] # gpg: aka "Peter Maydell <pmaydell@gmail.com>" [full] # gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [full] * tag 'pull-target-arm-20220422-1' of https://git.linaro.org/people/pmaydell/qemu-arm: (61 commits) hw/arm/smmuv3: Pass the actual perm to returned IOMMUTLBEntry in smmuv3_translate() target/arm: Use tcg_constant_i32 in translate.h target/arm: Use tcg_constant in translate-vfp.c target/arm: Use smin/smax for do_sat_addsub_32 target/arm: Use tcg_constant in translate-neon.c target/arm: Use tcg_constant in translate-m-nocp.c target/arm: Simplify aa32 DISAS_WFI target/arm: Simplify gen_sar target/arm: Simplify GEN_SHIFT in translate.c target/arm: Split out gen_rebuild_hflags target/arm: Split out set_btype_raw target/arm: Remove fpexc32_access target/arm: Change CPUArchState.thumb to bool target/arm: Change DisasContext.thumb to bool target/arm: Extend store_cpu_offset to take field size target/arm: Change CPUArchState.aarch64 to bool target/arm: Change DisasContext.aarch64 to bool target/arm: Update SCTLR bits to ARMv9.2 target/arm: Update SCR_EL3 bits to ARMv8.8 target/arm: Update ISAR fields for ARMv8.8 ... Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2022-04-22hw/intc/arm_gicv3: Allow 'revision' property to be set to 4Peter Maydell
Now that we have implemented all the GICv4 requirements, relax the error-checking on the GIC object's 'revision' property to allow a TCG GIC to be a GICv4, whilst still constraining the KVM GIC to GICv3. Our 'revision' property doesn't consider the possibility of wanting to specify the minor version of the GIC -- for instance there is a GICv3.1 which adds support for extended SPI and PPI ranges, among other things, and also GICv4.1. But since the QOM property is internal to QEMU, not user-facing, we can cross that bridge when we come to it. Within the GIC implementation itself code generally checks against the appropriate ID register feature bits, and the only use of s->revision is for setting those ID register bits. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220408141550.1271295-39-peter.maydell@linaro.org
2022-04-22hw/intc/arm_gicv3: Update ID and feature registers for GICv4Peter Maydell
Update the various GIC ID and feature registers for GICv4: * PIDR2 [7:4] is the GIC architecture revision * GICD_TYPER.DVIS is 1 to indicate direct vLPI injection support * GICR_TYPER.VLPIS is 1 to indicate redistributor support for vLPIs * GITS_TYPER.VIRTUAL is 1 to indicate vLPI support * GITS_TYPER.VMOVP is 1 to indicate that our VMOVP implementation handles cross-ITS synchronization for the guest * ICH_VTR_EL2.nV4 is 0 to indicate direct vLPI injection support Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220408141550.1271295-38-peter.maydell@linaro.org
2022-04-22hw/intc/arm_gicv3_redist: Implement gicv3_redist_inv_vlpi()Peter Maydell
Implement the function gicv3_redist_inv_vlpi(), which was previously left as a stub. This is the function that does the work of the INV command for a virtual interrupt. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220408141550.1271295-37-peter.maydell@linaro.org
2022-04-22hw/intc/arm_gicv3_redist: Implement gicv3_redist_vinvall()Peter Maydell
Implement the gicv3_redist_vinvall() function (previously left as a stub). This function handles the work of a VINVALL command: it must invalidate any cached information associated with a specific vCPU. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220408141550.1271295-36-peter.maydell@linaro.org
2022-04-22hw/intc/arm_gicv3_redist: Implement gicv3_redist_mov_vlpi()Peter Maydell
Implement the gicv3_redist_mov_vlpi() function (previously left as a stub). This function handles the work of a VMOVI command: it marks the vLPI not-pending on the source and pending on the destination. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220408141550.1271295-35-peter.maydell@linaro.org
2022-04-22hw/intc/arm_gicv3_redist: Use set_pending_table_bit() in mov handlingPeter Maydell
We can use our new set_pending_table_bit() utility function in gicv3_redist_mov_lpi() to clear the bit in the source pending table, rather than doing the "load, clear bit, store" ourselves. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220408141550.1271295-34-peter.maydell@linaro.org
2022-04-22hw/intc/arm_gicv3_redist: Implement gicv3_redist_vlpi_pending()Peter Maydell
Implement the function gicv3_redist_vlpi_pending(), which was previously left as a stub. This is the function that is called by the CPU interface when it changes the state of a vLPI. It's similar to gicv3_redist_process_vlpi(), but we know that the vCPU is definitely resident on the redistributor and the irq is in range, so it is a bit simpler. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220408141550.1271295-33-peter.maydell@linaro.org
2022-04-22hw/intc/arm_gicv3_redist: Implement gicv3_redist_process_vlpi()Peter Maydell
Implement the function gicv3_redist_process_vlpi(), which was left as just a stub earlier. This function deals with being handed a VLPI by the ITS. It must set the bit in the pending table. If the vCPU is currently resident we must recalculate the highest priority pending vLPI; otherwise we may need to ring a "doorbell" interrupt to let the hypervisor know it might want to reschedule the vCPU. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220408141550.1271295-32-peter.maydell@linaro.org
2022-04-22hw/intc/arm_gicv3_redist: Factor out "update bit in pending table" codePeter Maydell
Factor out the code which sets a single bit in an LPI pending table. We're going to need this for handling vLPI tables, not just the physical LPI table. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220408141550.1271295-31-peter.maydell@linaro.org
2022-04-22hw/intc/arm_gicv3_redist: Recalculate hppvlpi on VPENDBASER writesPeter Maydell
The guest uses GICR_VPENDBASER to tell the redistributor when it is scheduling or descheduling a vCPU. When it writes and changes the VALID bit from 0 to 1, it is scheduling a vCPU, and we must update our view of the current highest priority pending vLPI from the new Pending and Configuration tables. When it writes and changes the VALID bit from 1 to 0, it is descheduling, which means that there is no longer a highest priority pending vLPI. The specification allows the implementation to use part of the vLPI Pending table as an IMPDEF area where it can cache information when a vCPU is descheduled, so that it can avoid having to do a full rescan of the tables when the vCPU is scheduled again. For now, we don't take advantage of this, and simply do a complete rescan. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220408141550.1271295-30-peter.maydell@linaro.org
2022-04-22hw/intc/arm_gicv3_redist: Factor out "update hpplpi for all LPIs" logicPeter Maydell
Factor out the common part of gicv3_redist_update_lpi_only() into a new function update_for_all_lpis(), which does a full rescan of an LPI Pending table and sets the specified PendingIrq struct with the highest priority pending enabled LPI it finds. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220408141550.1271295-29-peter.maydell@linaro.org
2022-04-22hw/intc/arm_gicv3_redist: Factor out "update hpplpi for one LPI" logicPeter Maydell
Currently the functions which update the highest priority pending LPI information by looking at the LPI Pending and Configuration tables are hard-coded to use the physical LPI tables addressed by GICR_PENDBASER and GICR_PROPBASER. To support virtual LPIs we will need to do essentially the same job, but looking at the current virtual LPI Pending and Configuration tables and updating cs->hppvlpi instead of cs->hpplpi. Factor out the common part of the gicv3_redist_check_lpi_priority() function into a new update_for_one_lpi() function, which updates a PendingIrq struct if the specified LPI is higher priority than what is currently recorded there. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220408141550.1271295-28-peter.maydell@linaro.org
2022-04-22hw/intc/arm_gicv3_cpuif: Don't recalculate maintenance irq unnecessarilyPeter Maydell
The maintenance interrupt state depends only on: * ICH_HCR_EL2 * ICH_LR<n>_EL2 * ICH_VMCR_EL2 fields VENG0 and VENG1 Now we have a separate function that updates only the vIRQ and vFIQ lines, use that in places that only change state that affects vIRQ and vFIQ but not the maintenance interrupt. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220408141550.1271295-27-peter.maydell@linaro.org
2022-04-22hw/intc/arm_gicv3_cpuif: Support vLPIsPeter Maydell
The CPU interface changes to support vLPIs are fairly minor: in the parts of the code that currently look at the list registers to determine the highest priority pending virtual interrupt, we must also look at the highest priority pending vLPI. To do this we change hppvi_index() to check the vLPI and return a special-case value if that is the right virtual interrupt to take. The callsites (which handle HPPIR and IAR registers and the "raise vIRQ and vFIQ lines" code) then have to handle this special-case value. This commit includes two interfaces with the as-yet-unwritten redistributor code: * the new GICv3CPUState::hppvlpi will be set by the redistributor (in the same way as the existing hpplpi does for physical LPIs) * when the CPU interface acknowledges a vLPI it needs to set it to non-pending; the new gicv3_redist_vlpi_pending() function (which matches the existing gicv3_redist_lpi_pending() used for physical LPIs) is a stub that will be filled in later Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220408141550.1271295-26-peter.maydell@linaro.org
2022-04-22hw/intc/arm_gicv3_cpuif: Split "update vIRQ/vFIQ" from gicv3_cpuif_virt_update()Peter Maydell
The function gicv3_cpuif_virt_update() currently sets all of vIRQ, vFIQ and the maintenance interrupt. This implies that it has to be used quite carefully -- as the comment notes, setting the maintenance interrupt will typically cause the GIC code to be re-entered recursively. For handling vLPIs, we need the redistributor to be able to tell the cpuif to update the vIRQ and vFIQ lines when the highest priority pending vLPI changes. Since that change can't cause the maintenance interrupt state to change, we can pull the "update vIRQ/vFIQ" parts of gicv3_cpuif_virt_update() out into a separate function, which the redistributor can then call without having to worry about the reentrancy issue. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220408141550.1271295-25-peter.maydell@linaro.org
2022-04-22hw/intc/arm_gicv3: Implement new GICv4 redistributor registersPeter Maydell
Implement the new GICv4 redistributor registers: GICR_VPROPBASER and GICR_VPENDBASER; for the moment we implement these as simple reads-as-written stubs, together with the necessary migration and reset handling. We don't put ID-register checks on the handling of these registers, because they are all in the only-in-v4 extra register frames, so they're not accessible in a GICv3. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220408141550.1271295-24-peter.maydell@linaro.org
2022-04-22hw/intc/arm_gicv3: Implement GICv4's new redistributor framePeter Maydell
The GICv4 extends the redistributor register map -- where GICv3 had two 64KB frames per CPU, GICv4 has four frames. Add support for the extra frame by using a new gicv3_redist_size() function in the places in the GIC implementation which currently use a fixed constant size for the redistributor register block. (Until we implement the extra registers they will RAZ/WI.) Any board that wants to use a GICv4 will need to also adjust to handle the different sized redistributor register block; that will be done separately. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220408141550.1271295-23-peter.maydell@linaro.org
2022-04-22hw/intc/arm_gicv3_its: Implement VINVALLPeter Maydell
The VINVALL command should cause any cached information in the ITS or redistributor for the specified vCPU to be dropped or otherwise made consistent with the in-memory LPI configuration tables. Here we implement the command and table parsing, leaving the redistributor part as a stub for the moment, as usual. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220408141550.1271295-22-peter.maydell@linaro.org
2022-04-22hw/intc/arm_gicv3_its: Implement VMOVIPeter Maydell
Implement the GICv4 VMOVI command, which moves the pending state of a virtual interrupt from one redistributor to another. As with MOVI, we handle the "parse and validate command arguments and table lookups" part in the ITS source file, and pass the final results to a function in the redistributor which will do the actual operation. As with the "make a VLPI pending" change, for the moment we leave that redistributor function as a stub, to be implemented in a later commit. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220408141550.1271295-21-peter.maydell@linaro.org
2022-04-22hw/intc/arm_gicv3_its: Implement INV for virtual interruptsPeter Maydell
Implement the ITS side of the handling of the INV command for virtual interrupts; as usual this calls into a redistributor function which we leave as a stub to fill in later. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220408141550.1271295-20-peter.maydell@linaro.org