summary refs log tree commit diff stats
path: root/hw/intc/arm_gicv3_cpuif.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* hw/intc/arm_gicv3: Introduce a 'first-cpu-index' propertyFrancisco Iglesias2025-10-071-1/+1
| | | | | | | | | | | | | | | | | | Introduce a 'first-cpu-index' property for specifying the first QEMU CPU connected to the GICv3. This makes it possible to have multiple instances of the GICv3 connected to different CPU clusters. For KVM, mark this property has unsupported. It probably does not make much sense as it is intented to be used to model non-SMP systems. Signed-off-by: Luc Michel <luc.michel@amd.com> Signed-off-by: Francisco Iglesias <francisco.iglesias@amd.com> Reviewed-by: Sai Pavan Boddu <sai.pavan.boddu@amd.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20250926070806.292065-24-luc.michel@amd.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm: Drop define_one_arm_cp_reg_with_opaqueRichard Henderson2025-09-251-9/+1
| | | | | | | | | | | | | The last use of this interface was removed in 603bc048a27f ("hw/arm: Remove pxa2xx_pic"). As the comment in gicv3 stated, keeping pointer references to cpregs has SMP issues, so avoid future temptation by removing the interface. Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* cleanup: Drop pointless return at end of functionMarkus Armbruster2025-04-241-1/+0
| | | | | | | | | | | A few functions now end with a label. The next commit will clean them up. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20250407082643.2310002-3-armbru@redhat.com> [Straightforward conflict with commit 988ad4ccebb6 (hw/loongarch/virt: Fix cpuslot::cpu set at last in virt_cpu_plug()) resolved]
* target/arm: Move arm_current_el() and arm_el_is_aa64() to internals.hPeter Maydell2025-03-141-0/+1
| | | | | | | | | | | | | | | | | | | The functions arm_current_el() and arm_el_is_aa64() are used only in target/arm and in hw/intc/arm_gicv3_cpuif.c. They're functions that query internal state of the CPU. Move them out of cpu.h and into internals.h. This means we need to include internals.h in arm_gicv3_cpuif.c, but this is justifiable because that file is implementing the GICv3 CPU interface, which really is part of the CPU proper; we just ended up implementing it in code in hw/intc/ for historical reasons. The motivation for this move is that we'd like to change arm_el_is_aa64() to add a condition that uses cpu_isar_feature(); but we don't want to include cpu-features.h in cpu.h. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
* hw/intc/arm_gicv3_cpuif(): Remove redundant tests of is_a64()Peter Maydell2025-02-201-3/+3
| | | | | | | | | | | | | | | | | | | In the gicv3_{irq,fiq,irqfiq}_access() functions, in the arm_current_el(env) == 3 case we do the following test: if (!is_a64(env) && !arm_is_el3_or_mon(env)) { r = CP_ACCESS_TRAP_EL3; } In this check, the "!is_a64(env)" is redundant, because if we are at EL3 and in AArch64 then arm_is_el3_or_mon() will return true and we will skip the if() body anyway. Remove the unnecessary tests. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20250130182309.717346-9-peter.maydell@linaro.org
* hw/intc/arm_gicv3_cpuif: Don't downgrade monitor traps for AArch32 EL3Peter Maydell2025-02-201-9/+0
| | | | | | | | | | | | | | | | | | | | | | | | In the gicv3_{irq,fiq,irqfiq}_access() functions, there is a check which downgrades a CP_ACCESS_TRAP_EL3 to CP_ACCESS_TRAP if EL3 is not AArch64. This has been there since the GIC was first implemented, but it isn't right: if we are trapping because of SCR.IRQ or SCR.FIQ then we definitely want to be going to EL3 (doing AArch32.TakeMonitorTrapException() in pseudocode terms). We might want to not take a trap at all, but we don't ever want to go to the default target EL, because that would mean, for instance, taking a trap to Hyp mode if the trapped access was made from Hyp mode. (This might have been an attempt to work around our failure to properly implement Monitor Traps.) Remove the bogus check. Cc: qemu-stable@nongnu.org Fixes: 359fbe65e01e ("hw/intc/arm_gicv3: Implement GICv3 CPU interface registers") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20250130182309.717346-7-peter.maydell@linaro.org
* include: Rename sysemu/ -> system/Philippe Mathieu-Daudé2024-12-201-2/+2
| | | | | | | | | | | | | Headers in include/sysemu/ are not only related to system *emulation*, they are also used by virtualization. Rename as system/ which is clearer. Files renamed manually then mechanical change using sed tool. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Lei Yang <leiyang@redhat.com> Message-Id: <20241203172445.28576-1-philmd@linaro.org>
* hw/intc/arm_gicv3_cpuif: Add cast to match the documentationAlexandra Diupina2024-10-151-1/+1
| | | | | | | | | | | | | | | | | The result of 1 << regbit with regbit==31 has a 1 in the 32nd bit. When cast to uint64_t (for further bitwise OR), the 32 most significant bits will be filled with 1s. However, the documentation states that the upper 32 bits of ICH_AP[0/1]R<n>_EL2 are reserved. Add an explicit cast to match the documentation. Found by Linux Verification Center (linuxtesting.org) with SVACE. Cc: qemu-stable@nongnu.org Fixes: c3f21b065a ("hw/intc/arm_gicv3_cpuif: Support vLPIs") Signed-off-by: Alexandra Diupina <adiupina@astralinux.ru> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* hw/intc/arm_gicv3: Add cast to match the documentationAlexandra Diupina2024-10-151-1/+1
| | | | | | | | | | | | | | | | | The result of 1 << regbit with regbit==31 has a 1 in the 32nd bit. When cast to uint64_t (for further bitwise OR), the 32 most significant bits will be filled with 1s. However, the documentation states that the upper 32 bits of ICC_AP[0/1]R<n>_EL2 are reserved. Add an explicit cast to match the documentation. Found by Linux Verification Center (linuxtesting.org) with SVACE. Cc: qemu-stable@nongnu.org Fixes: 28cca59c46 ("hw/intc/arm_gicv3: Add NMI handling CPU interface registers") Signed-off-by: Alexandra Diupina <adiupina@astralinux.ru> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* hw/intc/arm_gicv3: Add cast to match the documentationAlexandra Diupina2024-10-151-1/+1
| | | | | | | | | | | | | | | | | The result of 1 << regbit with regbit==31 has a 1 in the 32nd bit. When cast to uint64_t (for further bitwise OR), the 32 most significant bits will be filled with 1s. However, the documentation states that the upper 32 bits of ICH_AP[0/1]R<n>_EL2 are reserved. Add an explicit cast to match the documentation. Found by Linux Verification Center (linuxtesting.org) with SVACE. Cc: qemu-stable@nongnu.org Fixes: d2c0c6aab6 ("hw/intc/arm_gicv3: Handle icv_nmiar1_read() for icc_nmiar1_read()") Signed-off-by: Alexandra Diupina <adiupina@astralinux.ru> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* hw/intc/arm_gicv3: Report the VINMI interruptJinjie Ruan2024-04-251-2/+12
| | | | | | | | | | | In vCPU Interface, if the vIRQ has the non-maskable property, report vINMI to the corresponding vPE. Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20240407081733.3231820-23-ruanjinjie@huawei.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* hw/intc/arm_gicv3: Report the NMI interrupt in gicv3_cpuif_update()Jinjie Ruan2024-04-251-0/+4
| | | | | | | | | | | In CPU Interface, if the IRQ has the non-maskable property, report NMI to the corresponding PE. Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20240407081733.3231820-22-ruanjinjie@huawei.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* hw/intc/arm_gicv3: Handle icv_nmiar1_read() for icc_nmiar1_read()Peter Maydell2024-04-251-12/+93
| | | | | | | | | | | | | | | | | | | | | | Implement icv_nmiar1_read() for icc_nmiar1_read(), so add definition for ICH_LR_EL2.NMI and ICH_AP1R_EL2.NMI bit. If FEAT_GICv3_NMI is supported, ich_ap_write() should consider ICV_AP1R_EL1.NMI bit. In icv_activate_irq() and icv_eoir_write(), the ICV_AP1R_EL1.NMI bit should be set or clear according to the Non-maskable property. And the RPR priority should also update the NMI bit according to the APR priority NMI bit. By the way, add gicv3_icv_nmiar1_read trace event. If the hpp irq is a NMI, the icv iar read should return 1022 and trap for NMI again Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> [PMM: use cs->nmi_support instead of cs->gic->nmi_support] Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20240407081733.3231820-20-ruanjinjie@huawei.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* hw/intc/arm_gicv3: Add NMI handling CPU interface registersPeter Maydell2024-04-251-5/+142
| | | | | | | | | | | | | | | | | | | | | Add the NMIAR CPU interface registers which deal with acknowledging NMI. When introduce NMI interrupt, there are some updates to the semantics for the register ICC_IAR1_EL1 and ICC_HPPIR1_EL1. For ICC_IAR1_EL1 register, it should return 1022 if the intid has non-maskable property. And for ICC_NMIAR1_EL1 register, it should return 1023 if the intid do not have non-maskable property. Howerever, these are not necessary for ICC_HPPIR1_EL1 register. And the APR and RPR has NMI bits which should be handled correctly. Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> [PMM: Separate out whether cpuif supports NMI from whether the GIC proper (IRI) supports NMI] Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20240407081733.3231820-19-ruanjinjie@huawei.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* hw/intc/arm_gicv3: ICC_HPPIR* return SPURIOUS if int group is disabledPeter Maydell2024-04-021-2/+2
| | | | | | | | | | | | | | | | If the group of the highest priority pending interrupt is disabled via ICC_IGRPEN*, the ICC_HPPIR* registers should return INTID_SPURIOUS, not the interrupt ID. (See the GIC architecture specification pseudocode functions ICC_HPPIR1_EL1[] and HighestPriorityPendingInterrupt().) Make HPPIR reads honour the group disable, the way we already do when determining whether to preempt in icc_hppi_can_preempt(). Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20240328153333.2522667-1-peter.maydell@linaro.org
* hw/intc/arm_gicv3_cpuif: Mark up VNCR offsets for GIC CPU registersPeter Maydell2024-01-091-0/+11
| | | | | | | | | | Mark up the cpreginfo structs for the GIC CPU registers to indicate the offsets from VNCR_EL2, as defined in table D8-66 in rule R_CSRPQ in the Arm ARM. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Miguel Luis <miguel.luis@oracle.com>
* hw/intc/arm_gicv3_cpuif: handle LPIs in in the list registersPeter Maydell2024-01-091-4/+13
| | | | | | | | | | | | | | | | | | | | | | | | The hypervisor can deliver (virtual) LPIs to a guest by setting up a list register to have an intid which is an LPI. The GIC has to treat these a little differently to standard interrupt IDs, because LPIs have no Active state, and so the guest will only EOI them, it will not also deactivate them. So icv_eoir_write() must do two things: * if the LPI ID is not in any list register, we drop the priority but do not increment the EOI count * if the LPI ID is in a list register, we immediately deactivate it, regardless of the split-drop-and-deactivate control This can be seen in the VirtualWriteEOIR0() and VirtualWriteEOIR1() pseudocode in the GICv3 architecture specification. Without this fix, potentially a hypervisor guest might stall because LPIs get stuck in a bogus Active+Pending state. Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Miguel Luis <miguel.luis@oracle.com>
* system/cpus: rename qemu_mutex_lock_iothread() to bql_lock()Stefan Hajnoczi2024-01-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Big QEMU Lock (BQL) has many names and they are confusing. The actual QemuMutex variable is called qemu_global_mutex but it's commonly referred to as the BQL in discussions and some code comments. The locking APIs, however, are called qemu_mutex_lock_iothread() and qemu_mutex_unlock_iothread(). The "iothread" name is historic and comes from when the main thread was split into into KVM vcpu threads and the "iothread" (now called the main loop thread). I have contributed to the confusion myself by introducing a separate --object iothread, a separate concept unrelated to the BQL. The "iothread" name is no longer appropriate for the BQL. Rename the locking APIs to: - void bql_lock(void) - void bql_unlock(void) - bool bql_locked(void) There are more APIs with "iothread" in their names. Subsequent patches will rename them. There are also comments and documentation that will be updated in later patches. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Paul Durrant <paul@xen.org> Acked-by: Fabiano Rosas <farosas@suse.de> Acked-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Cédric Le Goater <clg@kaod.org> Acked-by: Peter Xu <peterx@redhat.com> Acked-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Acked-by: Hyman Huang <yong.huang@smartx.com> Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-id: 20240102153529.486531-2-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
* hw/intc/arm_gicv3: ICC_PMR_EL1 high bits should be RAZBen Dooks2023-11-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ICC_PMR_ELx and ICV_PMR_ELx bit masks returned from ic{c,v}_fullprio_mask should technically also remove any bit above 7 as these are marked reserved (read 0) and should therefore should not be written as anything other than 0. This was noted during a run of a proprietary test system and discused on the mailing list [1] and initially thought not to be an issue due to RES0 being technically allowed to be written to and read back as long as the implementation does not use the RES0 bits. It is very possible that the values are used in comparison without masking, as pointed out by Peter in [2], if (cs->hppi.prio >= cs->icc_pmr_el1) may well do the wrong thing. Masking these values in ic{c,v}_fullprio_mask() should fix this and prevent any future problems with playing with the values. [1]: https://lists.nongnu.org/archive/html/qemu-arm/2023-11/msg00607.html [2]: https://lists.nongnu.org/archive/html/qemu-arm/2023-11/msg00737.html Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Message-id: 20231116172818.792364-1-ben.dooks@codethink.co.uk Suggested-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm: Mark up sysregs for HFGRTR bits 36..63Peter Maydell2023-02-031-0/+2
| | | | | | | | | | | | | | | | | | | Mark up the sysreg definitions for the registers trapped by HFGRTR/HFGWTR bits 36..63. Of these, some correspond to RAS registers which we implement as always-UNDEF: these don't need any extra handling for FGT because the UNDEF-to-EL1 always takes priority over any theoretical FGT-trap-to-EL2. Bit 50 (NACCDATA_EL1) is for the ACCDATA_EL1 register which is part of the FEAT_LS64_ACCDATA feature which we don't yet implement. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Fuad Tabba <tabba@google.com> Message-id: 20230130182459.3309057-14-peter.maydell@linaro.org Message-id: 20230127175507.2895013-14-peter.maydell@linaro.org
* hvf: arm: Add support for GICv3Alexander Graf2023-02-031-1/+15
| | | | | | | | | | | | | | | | | | | | We currently only support GICv2 emulation. To also support GICv3, we will need to pass a few system registers into their respective handler functions. This patch adds support for HVF to call into the TCG callbacks for GICv3 system register handlers. This is safe because the GICv3 TCG code is generic as long as we limit ourselves to EL0 and EL1 - which are the only modes supported by HVF. To make sure nobody trips over that, we also annotate callbacks that don't work in HVF mode, such as EL state change hooks. With GICv3 support in place, we can run with more than 8 vCPUs. Signed-off-by: Alexander Graf <agraf@csgraf.de> Message-id: 20230128224459.70676-1-agraf@csgraf.de Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* hw/intc/arm_gicv3: fix prio masking on pmr writeJens Wiklander2022-11-141-2/+1
| | | | | | | | | | | | | | | | | | | | | | | With commit 39f29e599355 ("hw/intc/arm_gicv3: Use correct number of priority bits for the CPU") the number of priority bits was changed from the maximum value 8 to typically 5. As a consequence a few of the lowest bits in ICC_PMR_EL1 becomes RAZ/WI. However prior to this patch one of these bits was still used since the supplied priority value is masked before it's eventually right shifted with one bit. So the bit is not lost as one might expect when the register is read again. The Linux kernel depends on lowest valid bit to be reset to zero, see commit 33625282adaa ("irqchip/gic-v3: Probe for SCR_EL3 being clear before resetting AP0Rn") for details. So fix this by masking the priority value after it may have been right shifted by one bit. Cc: qemu-stable@nongnu.org Fixes: 39f29e599355 ("hw/intc/arm_gicv3: Use correct number of priority bits for the CPU") Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* Fix 'writeable' typosPeter Maydell2022-06-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* hw/intc/arm_gicv3: Provide ich_num_aprs()Peter Maydell2022-05-191-6/+10
| | | | | | | | | | | | | 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
* hw/intc/arm_gicv3: Use correct number of priority bits for the CPUPeter Maydell2022-05-191-4/+11
| | | | | | | | | | | | | | 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
* hw/intc/arm_gicv3: Support configurable number of physical priority bitsPeter Maydell2022-05-191-54/+128
| | | | | | | | | | | | | | | | | | | | | | | | 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
* hw/intc/arm_gicv3: report correct PRIbits field in ICV_CTLR_EL1Peter Maydell2022-05-191-1/+1
| | | | | | | | | | | | | | 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
* hw/intc/arm_gicv3_cpuif: Handle CPUs that don't specify GICv3 parametersPeter Maydell2022-05-191-5/+13
| | | | | | | | | | | | | | | | | | | | | | | 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
* target/arm: Replace sentinels with ARRAY_SIZE in cpregs.hRichard Henderson2022-05-051-5/+0
| | | | | | | | | | | | | | | 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>
* target/arm: Split out cpregs.hRichard Henderson2022-05-051-0/+1
| | | | | | | | | | | 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>
* hw/intc/arm_gicv3: Update ID and feature registers for GICv4Peter Maydell2022-04-221-1/+5
| | | | | | | | | | | | | | | 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
* hw/intc/arm_gicv3_cpuif: Don't recalculate maintenance irq unnecessarilyPeter Maydell2022-04-221-5/+5
| | | | | | | | | | | | | | | 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
* hw/intc/arm_gicv3_cpuif: Support vLPIsPeter Maydell2022-04-221-5/+114
| | | | | | | | | | | | | | | | | | | | | | | | 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
* hw/intc/arm_gicv3_cpuif: Split "update vIRQ/vFIQ" from gicv3_cpuif_virt_update()Peter Maydell2022-04-221-24/+40
| | | | | | | | | | | | | | | | | | 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
* hw/intc/arm_gicv3_cpuif: Fix register names in ICV_HPPIR read trace eventPeter Maydell2022-03-071-1/+2
| | | | | | | | | | | | | | | | | The trace_gicv3_icv_hppir_read trace event takes an integer value which it uses to form the register name, which should be either ICV_HPPIR0 or ICV_HPPIR1. We were passing in the 'grp' variable for this, but that is either GICV3_G0 or GICV3_G1NS, which happen to be 0 and 2, which meant that tracing for the ICV_HPPIR1 register was incorrectly printed as ICV_HPPIR2. Use the same approach we do for all the other similar trace events, and pass in 'ri->crm == 8 ? 0 : 1', deriving the index value directly from the ARMCPRegInfo struct. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220303202341.2232284-6-peter.maydell@linaro.org
* hw/intc/arm_gicv3: Extract gicv3_set_gicv3state from arm_gicv3_cpuif.cPhilippe Mathieu-Daudé2021-12-151-9/+1
| | | | | | | | | | | | | gicv3_set_gicv3state() is used by arm_gicv3_common.c in arm_gicv3_common_realize(). Since we want to restrict arm_gicv3_cpuif.c to TCG, extract gicv3_set_gicv3state() to a new file. Add this file to the meson 'specific' source set, since it needs access to "cpu.h". Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20211115223619.2599282-2-philmd@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* gicv3: fix ICH_MISR's LRENP computationDamien Hedde2021-12-071-1/+2
| | | | | | | | | | | | | | | | | | | | | | | According to the "Arm Generic Interrupt Controller Architecture Specification GIC architecture version 3 and 4" (version G: page 345 for aarch64 or 509 for aarch32): LRENP bit of ICH_MISR is set when ICH_HCR.LRENPIE==1 and ICH_HCR.EOIcount is non-zero. When only LRENPIE was set (and EOI count was zero), the LRENP bit was wrongly set and MISR value was wrong. As an additional consequence, if an hypervisor set ICH_HCR.LRENPIE, the maintenance interrupt was constantly fired. It happens since patch 9cee1efe92 ("hw/intc: Set GIC maintenance interrupt level to only 0 or 1") which fixed another bug about maintenance interrupt (most significant bits of misr, including this one, were ignored in the interrupt trigger). Fixes: 83f036fe3d ("hw/intc/arm_gicv3: Add accessors for ICH_ system registers") Signed-off-by: Damien Hedde <damien.hedde@greensocs.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20211207094427.3473-1-damien.hedde@greensocs.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* hw/intc/arm_gicv3: fix handling of LPIs in list registersPeter Maydell2021-11-291-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is valid for an OS to put virtual interrupt ID values into the list registers ICH_LR<n> which are greater than 1023. This corresponds to (for example) KVM using the in-kernel emulated ITS to give a (nested) guest an ITS. LPIs are delivered by the L1 kernel to the L2 guest via the list registers in the same way as non-LPI interrupts. QEMU's code for handling writes to ICV_IARn (which happen when the L2 guest acknowledges an interrupt) and to ICV_EOIRn (which happen at the end of the interrupt) did not consider LPIs, so it would incorrectly treat interrupt IDs above 1023 as invalid. Fix this by using the correct condition, which is gicv3_intid_is_special(). Note that the condition in icv_dir_write() is correct -- LPIs are not valid there and so we want to ignore both "special" ID values and LPIs. (In the pseudocode this logic is in: - VirtualReadIAR0(), VirtualReadIAR1(), which call IsSpecial() - VirtualWriteEOIR0(), VirtualWriteEOIR1(), which call VirtualIdentifierValid(data, TRUE) meaning "LPIs OK" - VirtualWriteDIR(), which calls VirtualIdentifierValid(data, FALSE) meaning "LPIs not OK") This bug doesn't seem to have any visible effect on Linux L2 guests most of the time, because the two bugs cancel each other out: we neither mark the interrupt active nor deactivate it. However it does mean that the L2 vCPU priority while the LPI handler is running will not be correct, so the interrupt handler could be unexpectedly interrupted by a different interrupt. (NB: this has nothing to do with using QEMU's emulated ITS.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Marc Zyngier <maz@kernel.org>
* hw/intc/arm_gicv3: Add new gicv3_intid_is_special() functionPeter Maydell2021-11-261-2/+2
| | | | | | | | | | | The GICv3/v4 pseudocode has a function IsSpecial() which returns true if passed a "special" interrupt ID number (anything between 1020 and 1023 inclusive). We open-code this condition in a couple of places, so abstract it out into a new function gicv3_intid_is_special(). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
* hw/intc: Set GIC maintenance interrupt level to only 0 or 1Shashi Mallela2021-09-201-2/+3
| | | | | | | | | | | | | | | | | | | | During sbsa acs level 3 testing, it is seen that the GIC maintenance interrupts are not triggered and the related test cases fail. This is because we were incorrectly passing the value of the MISR register (from maintenance_interrupt_state()) to qemu_set_irq() as the level argument, whereas the device on the other end of this irq line expects a 0/1 value. Fix the logic to pass a 0/1 level indication, rather than a 0/not-0 value. Fixes: c5fc89b36c0 ("hw/intc/arm_gicv3: Implement gicv3_cpuif_virt_update()") Signed-off-by: Shashi Mallela <shashi.mallela@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20210915205809.59068-1-shashi.mallela@linaro.org [PMM: tweaked commit message; collapsed nested if()s into one] Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* hw/intc: GICv3 redistributor ITS processingShashi Mallela2021-09-131-2/+5
| | | | | | | | | | | | | | | Implemented lpi processing at redistributor to get lpi config info from lpi configuration table,determine priority,set pending state in lpi pending table and forward the lpi to cpuif.Added logic to invoke redistributor lpi processing with translated LPI which set/clear LPI from ITS device as part of ITS INT,CLEAR,DISCARD command and GITS_TRANSLATER processing. Signed-off-by: Shashi Mallela <shashi.mallela@linaro.org> Tested-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20210910143951.92242-7-shashi.mallela@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* hw/intc/arm_gicv3_cpuif: Fix virtual irq number check in icv_[dir|eoir]_writeRicardo Koller2021-07-091-2/+2
| | | | | | | | | | | | | | | | | | | icv_eoir_write() and icv_dir_write() ignore invalid virtual IRQ numbers (like LPIs). The issue is that these functions check against the number of implemented IRQs (QEMU's default is num_irq=288) which can be lower than the maximum virtual IRQ number (1020 - 1). The consequence is that if a hypervisor creates an LR for an IRQ between 288 and 1020, then the guest is unable to deactivate the resulting IRQ. Note that other functions that deal with large IRQ numbers, like icv_iar_read, check against 1020 and not against num_irq. Fix the checks by using GICV3_MAXIRQ (1020) instead of the number of implemented IRQs. Signed-off-by: Ricardo Koller <ricarkol@google.com> Message-id: 20210702233701.3369-1-ricarkol@google.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* hw/intc/arm_gicv3_cpuif: Tolerate spurious EOIR writesJean-Philippe Brucker2021-06-151-1/+4
| | | | | | | | | | | | | | | | | | | | | | | Commit 382c7160d1cd ("hw/intc/arm_gicv3_cpuif: Fix EOIR write access check logic") added an assert_not_reached() if the guest writes the EOIR register while no interrupt is active. It turns out some software does this: EDK2, in GicV3ExitBootServicesEvent(), unconditionally write EOIR for all interrupts that it manages. This now causes QEMU to abort when running UEFI on a VM with GICv3. Although it is UNPREDICTABLE behavior and EDK2 does need fixing, the punishment seems a little harsh, especially since icc_eoir_write() already tolerates writes of nonexistent interrupt numbers. Display a guest error and tolerate spurious EOIR writes. Fixes: 382c7160d1cd ("hw/intc/arm_gicv3_cpuif: Fix EOIR write access check logic") Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20210604130352.1887560-1-jean-philippe@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* hw/intc/arm_gicv3_cpuif: Fix EOIR write access check logicPeter Maydell2021-05-251-16/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In icc_eoir_write() we assume that we can identify the group of the IRQ being completed based purely on which register is being written to and the current CPU state, and that "CPU state matches group indicated by register" is the only necessary access check. This isn't correct: if the CPU is not in Secure state then EOIR1 will only complete Group 1 NS IRQs, but if the CPU is in EL3 it can complete both Group 1 S and Group 1 NS IRQs. (The pseudocode ICC_EOIR1_EL1 makes this clear.) We were also missing the logic to prevent EOIR0 writes completing G0 IRQs when they should not. Rearrange the logic to first identify the group of the current highest priority interrupt and then look at whether we should complete it or ignore the access based on which register was accessed and the state of the CPU. The resulting behavioural change is: * EL3 can now complete G1NS interrupts * G0 interrupt completion is now ignored if the GIC and the CPU have the security extension enabled and the CPU is not secure Reported-by: Chan Kim <ckim@etri.re.kr> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20210510150016.24910-1-peter.maydell@linaro.org
* hw/intc/arm_gicv3_cpuif: Make GIC maintenance interrupts workPeter Maydell2020-11-021-3/+2
| | | | | | | | | | | | | | | | | | | | | In gicv3_init_cpuif() we copy the ARMCPU gicv3_maintenance_interrupt into the GICv3CPUState struct's maintenance_irq field. This will only work if the board happens to have already wired up the CPU maintenance IRQ before the GIC was realized. Unfortunately this is not the case for the 'virt' board, and so the value that gets copied is NULL (since a qemu_irq is really a pointer to an IRQState struct under the hood). The effect is that the CPU interface code never actually raises the maintenance interrupt line. Instead, since the GICv3CPUState has a pointer to the CPUState, make the dereference at the point where we want to raise the interrupt, to avoid an implicit requirement on board code to wire things up in a particular order. Reported-by: Jose Martins <josemartins90@gmail.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20201009153904.28529-1-peter.maydell@linaro.org Reviewed-by: Luc Michel <luc@lmichel.fr>
* arm/gicv3: update virtual irq state after IAR register readJeff Kubascik2020-01-171-0/+3
| | | | | | | | | | | | The IAR0/IAR1 register is used to acknowledge an interrupt - a read of the register activates the highest priority pending interrupt and provides its interrupt ID. Activating an interrupt can change the CPU's virtual interrupt state - this change makes sure the virtual irq state is updated. Signed-off-by: Jeff Kubascik <jeff.kubascik@dornerworks.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200113154607.97032-1-jeff.kubascik@dornerworks.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* Include hw/irq.h a lot lessMarkus Armbruster2019-08-161-0/+1
| | | | | | | | | | | | | | | | | | | In my "build everything" tree, changing hw/irq.h triggers a recompile of some 5400 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). hw/hw.h supposedly includes it for convenience. Several other headers include it just to get qemu_irq and.or qemu_irq_handler. Move the qemu_irq and qemu_irq_handler typedefs from hw/irq.h to qemu/typedefs.h, and then include hw/irq.h only where it's still needed. Touching it now recompiles only some 500 objects. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190812052359.30071-13-armbru@redhat.com>
* hw/intc/arm_gicv3: Fix writes to ICC_CTLR_EL3Peter Maydell2019-05-231-2/+2
| | | | | | | | | | | | | The ICC_CTLR_EL3 register includes some bits which are aliases of bits in the ICC_CTLR_EL1(S) and (NS) registers. QEMU chooses to keep those bits in the cs->icc_ctlr_el1[] struct fields. Unfortunately a missing '~' in the code to update the bits in those fields meant that writing to ICC_CTLR_EL3 would corrupt the ICC_CLTR_EL1 register values. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190520162809.2677-5-peter.maydell@linaro.org
* hw/intc/arm_gicv3: Fix write of ICH_VMCR_EL2.{VBPR0, VBPR1}Peter Maydell2019-05-231-1/+1
| | | | | | | | | | | | In ich_vmcr_write() we enforce "writes of BPR fields to less than their minimum sets them to the minimum" by doing a "read vbpr and write it back" operation. A typo here meant that we weren't handling writes to these fields correctly, because we were reading from VBPR0 but writing to VBPR1. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190520162809.2677-4-peter.maydell@linaro.org
* target/arm: Introduce arm_hcr_el2_effRichard Henderson2018-12-131-10/+11
| | | | | | | | | | | Replace arm_hcr_el2_{fmo,imo,amo} with a more general routine that also takes SCR_EL3.NS (aka arm_is_secure_below_el3) into account, as documented for the plethora of bits in HCR_EL2. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20181210150501.7990-2-richard.henderson@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>