aboutsummaryrefslogtreecommitdiff
path: root/hw/intc/arm_gicv3_cpuif.c
AgeCommit message (Collapse)Author
2022-11-14hw/intc/arm_gicv3: fix prio masking on pmr writeJens Wiklander
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>
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-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: 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-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-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_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-03-07hw/intc/arm_gicv3_cpuif: Fix register names in ICV_HPPIR read trace eventPeter Maydell
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
2021-12-15hw/intc/arm_gicv3: Extract gicv3_set_gicv3state from arm_gicv3_cpuif.cPhilippe Mathieu-Daudé
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>
2021-12-07gicv3: fix ICH_MISR's LRENP computationDamien Hedde
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>
2021-11-29hw/intc/arm_gicv3: fix handling of LPIs in list registersPeter Maydell
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>
2021-11-26hw/intc/arm_gicv3: Add new gicv3_intid_is_special() functionPeter Maydell
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>
2021-09-20hw/intc: Set GIC maintenance interrupt level to only 0 or 1Shashi Mallela
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>
2021-09-13hw/intc: GICv3 redistributor ITS processingShashi Mallela
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>
2021-07-09hw/intc/arm_gicv3_cpuif: Fix virtual irq number check in icv_[dir|eoir]_writeRicardo Koller
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>
2021-06-15hw/intc/arm_gicv3_cpuif: Tolerate spurious EOIR writesJean-Philippe Brucker
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>
2021-05-25hw/intc/arm_gicv3_cpuif: Fix EOIR write access check logicPeter Maydell
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
2020-11-02hw/intc/arm_gicv3_cpuif: Make GIC maintenance interrupts workPeter Maydell
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>
2020-01-17arm/gicv3: update virtual irq state after IAR register readJeff Kubascik
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>
2019-08-16Include hw/irq.h a lot lessMarkus Armbruster
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>
2019-05-23hw/intc/arm_gicv3: Fix writes to ICC_CTLR_EL3Peter Maydell
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
2019-05-23hw/intc/arm_gicv3: Fix write of ICH_VMCR_EL2.{VBPR0, VBPR1}Peter Maydell
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
2018-12-13target/arm: Introduce arm_hcr_el2_effRichard Henderson
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>
2018-08-14target/arm: Provide accessor functions for HCR_EL2.{IMO, FMO, AMO}Peter Maydell
The IMO, FMO and AMO bits in HCR_EL2 are defined to "behave as 1 for all purposes other than direct reads" if HCR_EL2.TGE is set and HCR_EL2.E2H is 0, and to "behave as 0 for all purposes other than direct reads" if HCR_EL2.TGE is set and HRC_EL2.E2H is 1. To avoid having to check E2H and TGE everywhere where we test IMO and FMO, provide accessors arm_hcr_el2_imo(), arm_hcr_el2_fmo()and arm_hcr_el2_amo(). We don't implement ARMv8.1-VHE yet, so the E2H case will never be true, but we include the logic to save effort when we eventually do get to that. (Note that in several of these callsites the change doesn't actually make a difference as either the callsite is handling TGE specially anyway, or the CPU can't get into that situation with TGE set; we change everywhere for consistency.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20180724115950.17316-5-peter.maydell@linaro.org
2018-07-24hw/intc/arm_gicv3: Check correct HCR_EL2 bit when routing IRQPeter Maydell
In icc_dir_write() we were incorrectly checking HCR_EL2.FMO when determining whether IRQ should be routed to EL2; this should be HCR_EL2.IMO (compare the GICv3 pseudocode ICC_DIR_EL1[]). Use the correct mask. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20180723180337.17378-1-peter.maydell@linaro.org
2018-05-31hw/intc/arm_gicv3: Fix APxR<n> register dispatchingJan Kiszka
There was a nasty flip in identifying which register group an access is targeting. The issue caused spuriously raised priorities of the guest when handing CPUs over in the Jailhouse hypervisor. Cc: qemu-stable@nongnu.org Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Message-id: 28b927d3-da58-bce4-cc13-bfec7f9b1cb9@siemens.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-04-26target/arm: Fetch GICv3 state directly from CPUARMStateAaron Lindsay
This eliminates the need for fetching it from el_change_hook_opaque, and allows for supporting multiple el_change_hooks without having to hack something together to find the registered opaque belonging to GICv3. Signed-off-by: Aaron Lindsay <alindsay@codeaurora.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 1523997485-1905-6-git-send-email-alindsay@codeaurora.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-03-23hw/intc/arm_gicv3: Fix secure-GIC NS ICC_PMR and ICC_RPR accessesPeter Maydell
If the GIC has the security extension support enabled, then a non-secure access to ICC_PMR must take account of the non-secure view of interrupt priorities, where real priorities 0x00..0x7f are secure-only and not visible to the non-secure guest, and priorities 0x80..0xff are shown to the guest as if they were 0x00..0xff. We had the logic here wrong: * on reads, the priority is in the secure range if bit 7 is clear, not if it is set * on writes, we want to set bit 7, not mask everything else Our ICC_RPR read code had the same error as ICC_PMR. (Compare the GICv3 spec pseudocode functions ICC_RPR_EL1 and ICC_PMR_EL1.) Fixes: https://bugs.launchpad.net/qemu/+bug/1748434 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Andrew Jones <drjones@redhat.com> Message-id: 20180315133441.24149-1-peter.maydell@linaro.org
2017-06-07arm_gicv3: Fix ICC_BPR1 reset value when EL3 not implementedPeter Maydell
If EL3 is not implemented (ie only one security state) then the one and only ICC_BPR1 register behaves like the Non-secure ICC_BPR1 in an EL3-present configuration. In particular, its reset value is GIC_MIN_BPR_NS, not GIC_MIN_BPR. Correct the erroneous reset value; this fixes a problem where we might hit the assert added in commit a89ff39ee901. Reported-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 1496849369-30282-1-git-send-email-peter.maydell@linaro.org
2017-06-02hw/intc/arm_gicv3_cpuif: Fix priority masking for NS BPR1Peter Maydell
When we calculate the mask to use to get the group priority from an interrupt priority, the way that NS BPR1 is handled differs from how BPR0 and S BPR1 work -- a BPR1 value of 1 means the group priority is in bits [7:1], whereas for BPR0 and S BPR1 this is indicated by a 0 BPR value. Subtract 1 from the BPR value before creating the mask if we're using the NS BPR value, for both hardware and virtual interrupts, as the GICv3 pseudocode does, and fix the comments accordingly. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 1493226792-3237-4-git-send-email-peter.maydell@linaro.org
2017-06-02hw/intc/arm_gicv3_cpuif: Don't let BPR be set below its minimumPeter Maydell
icc_bpr_write() was not enforcing that writing a value below the minimum for the BPR should behave as if the BPR was set to the minimum value. This doesn't make a difference for the secure BPRs (since we define the minimum for the QEMU implementation as zero) but did mean we were allowing the NS BPR1 to be set to 0 when 1 should be the lowest value. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 1493226792-3237-3-git-send-email-peter.maydell@linaro.org
2017-06-02hw/intc/arm_gicv3_cpuif: Fix reset value for VMCR_EL2.VBPR1Peter Maydell
We were setting the VBPR1 field of VMCR_EL2 to icv_min_vbpr() on reset, but this is not correct. The field should reset to the minimum value of ICV_BPR0_EL1 plus one. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 1493226792-3237-2-git-send-email-peter.maydell@linaro.org
2017-02-28target-arm: Add GICv3CPUState in CPUARMState structVijaya Kumar K
Add gicv3state void pointer to CPUARMState struct to store GICv3CPUState. In case of usecase like CPU reset, we need to reset GICv3CPUState of the CPU. In such scenario, this pointer becomes handy. Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@cavium.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-id: 1487850673-26455-5-git-send-email-vijay.kilari@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-02-24tcg: drop global lock during TCG code executionJan Kiszka
This finally allows TCG to benefit from the iothread introduction: Drop the global mutex while running pure TCG CPU code. Reacquire the lock when entering MMIO or PIO emulation, or when leaving the TCG loop. We have to revert a few optimization for the current TCG threading model, namely kicking the TCG thread in qemu_mutex_lock_iothread and not kicking it in qemu_cpu_kick. We also need to disable RAM block reordering until we have a more efficient locking mechanism at hand. Still, a Linux x86 UP guest and my Musicpal ARM model boot fine here. These numbers demonstrate where we gain something: 20338 jan 20 0 331m 75m 6904 R 99 0.9 0:50.95 qemu-system-arm 20337 jan 20 0 331m 75m 6904 S 20 0.9 0:26.50 qemu-system-arm The guest CPU was fully loaded, but the iothread could still run mostly independent on a second core. Without the patch we don't get beyond 32206 jan 20 0 330m 73m 7036 R 82 0.9 1:06.00 qemu-system-arm 32204 jan 20 0 330m 73m 7036 S 21 0.9 0:17.03 qemu-system-arm We don't benefit significantly, though, when the guest is not fully loading a host CPU. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Message-Id: <1439220437-23957-10-git-send-email-fred.konrad@greensocs.com> [FK: Rebase, fix qemu_devices_reset deadlock, rm address_space_* mutex] Signed-off-by: KONRAD Frederic <fred.konrad@greensocs.com> [EGC: fixed iothread lock for cpu-exec IRQ handling] Signed-off-by: Emilio G. Cota <cota@braap.org> [AJB: -smp single-threaded fix, clean commit msg, BQL fixes] Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <rth@twiddle.net> Reviewed-by: Pranith Kumar <bobby.prani@gmail.com> [PM: target-arm changes] Acked-by: Peter Maydell <peter.maydell@linaro.org>
2017-01-27arm_gicv3: Fix broken logic in ELRSR calculationPeter Maydell
Fix a broken expression in the calculation of ELRSR register bits: instead of "(lr & ICH_LR_EL2_HW) == 1" we want to check for != 0, because the HW bit is not bit 0 so a test for == 1 is always false. Fixes: https://bugs.launchpad.net/bugs/1658506 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-id: 1485255993-6322-1-git-send-email-peter.maydell@linaro.org
2017-01-20hw/intc/arm_gicv3: Implement EL2 traps for CPU i/f regsPeter Maydell
Implement the architecturally required traps from NS EL1 to EL2 for the CPU interface registers. These fall into several different groups: * group-0-only registers all trap if ICH_HRC_EL2.TALL0 is set (exactly the registers covered by gicv3_fiq_access()) * group-1-only registers all trap if ICH_HRC_EL2.TALL1 is set (exactly the registers covered by gicv3_irq_access()) * DIR traps if ICH_HCR_EL2.TC or ICH_HCR_EL2.TDIR are set * PMR, RPR, CTLR trap if ICH_HCR_EL2.TC is set * SGI0R, SGI1R, ASGI1R trap if ICH_HCR_EL2.TC is set or if HCR_EL2.IMO or HCR_EL2.FMO are set We split DIR and the SGI registers out into their own access functions, leaving the existing gicv3_irqfiq_access() just handling PMR, RPR and CTLR. This commit doesn't implement support for trapping on HSTR_EL2.T12 for the 32-bit registers, as we don't implement any of those per-coprocessor trap bits currently and probably will want to do those in some more centralized way. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 1483977924-14522-14-git-send-email-peter.maydell@linaro.org
2017-01-20hw/intc/arm_gicv3: Implement gicv3_cpuif_virt_update()Peter Maydell
Implement the function which signals virtual interrupts to the CPU as appropriate following CPU interface state changes. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 1483977924-14522-13-git-send-email-peter.maydell@linaro.org
2017-01-20hw/intc/arm_gicv3: Implement ICV_ registers EOIR and IARPeter Maydell
Implement the two remaining ICV_ registers: EOIR and IAR. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 1483977924-14522-12-git-send-email-peter.maydell@linaro.org
2017-01-20hw/intc/arm_gicv3: Implement ICV_ HPPIR, DIR and RPR registersPeter Maydell
Implement the the ICV_ registers HPPIR, DIR and RPR. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 1483977924-14522-11-git-send-email-peter.maydell@linaro.org
2017-01-20hw/intc/arm_gicv3: Implement ICV_ registers which are just accessorsPeter Maydell
If the HCR_EL2.IMO or FMO bits are set, accesses to ICC_ system registers are redirected to be accesses to ICV_ registers (the guest-visible interface to the virtual interrupt controller). Implement this behaviour for the ICV_ registers which are simple accessors to the underlying register state. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 1483977924-14522-10-git-send-email-peter.maydell@linaro.org
2017-01-20hw/intc/arm_gicv3: Add accessors for ICH_ system registersPeter Maydell
The GICv3 virtualization interface includes system registers accessible only to the hypervisor which form the control interface for interrupt virtualization. Implement these registers. The function gicv3_cpuif_virt_update() which determines whether it needs to signal vIRQ, vFIQ or a maintenance interrupt is introduced here as a stub function -- its implementation will be added in a subsequent commit. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 1483977924-14522-9-git-send-email-peter.maydell@linaro.org
2017-01-20hw/intc/gicv3: Add data fields for virtualization supportPeter Maydell
As the first step in adding support for the virtualization extensions to the GICv3 emulation: * add the necessary data fields to the state structures * add the fields to the migration state, as a subsection which is only present if virtualization is enabled The use of a subsection means we retain migration compatibility as EL2 is not enabled on any CPUs currently. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Acked-by: Alistair Francis <alistair.francis@xilinx.com> Message-id: 1483977924-14522-8-git-send-email-peter.maydell@linaro.org
2016-12-27hw/intc/arm_gicv3: Remove incorrect usage of fieldoffsetPeter Maydell
In the ARMCPRegInfo definitions for the GICv3 CPU interface registers, we were trying to use .fieldoffset to specify the locations of data fields within the GICv3CPUState struct. This is completely broken, because .fieldoffset is for offsets into the CPUARMState struct. We didn't notice because we were only using this for reads to BPR0, AP0R<n>, IGRPEN0 and CTLR_EL3, and Linux doesn't use these registers. Replace the .fieldoffset uses with explicit read functions. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
2016-10-17hw/intc/arm_gicv3: Fix ICC register tracepointsPeter Maydell
Fix some problems with the tracepoints for ICC register reads and writes: * tracepoints for ICC_BPR<n>, ICC_AP<n>R<x>, ICC_IGRPEN<n>, ICC_EIOR<n> were not printing the <n> that indicated whether the access was to the group 0 or 1 register * the ICC_IGREPEN1_EL3 read function was not actually calling the associated tracepoint * the ICC_BPR<n> write function was incorrectly calling the tracepoint for ICC_PMR writes Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Acked-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Message-id: 1476294876-12340-4-git-send-email-peter.maydell@linaro.org