linux-toradex.git/include/linux/irqchip/arm-gic-v4.h, branch v7.0-rc1

KVM: arm64: WARN if unmapping a vLPI fails in any path

2025-06-20T20:52:29+00:00

When unmapping a vLPI, WARN if nullifying vCPU affinity fails, not just if
failure occurs when freeing an ITE.  If undoing vCPU affinity fails, then
odds are very good that vLPI state tracking has has gotten out of whack,
i.e. that KVM and the GIC disagree on the state of an IRQ/vLPI.  At best,
inconsistent state means there is a lurking bug/flaw somewhere.  At worst,
the inconsistency could eventually be fatal to the host, e.g. if an ITS
command fails because KVM's view of things doesn't match reality/hardware.

Note, only the call from kvm_arch_irq_bypass_del_producer() by way of
kvm_vgic_v4_unset_forwarding() doesn't already WARN.  Common KVM's
kvm_irq_routing_update() WARNs if kvm_arch_update_irqfd_routing() fails.
For that path, if its_unmap_vlpi() fails in kvm_vgic_v4_unset_forwarding(),
the only possible causes are that the GIC doesn't have a v4 ITS (from
its_irq_set_vcpu_affinity()):

        /* Need a v4 ITS */
        if (!is_v4(its_dev->its))
                return -EINVAL;

        guard(raw_spinlock)(&its_dev->event_map.vlpi_lock);

        /* Unmap request? */
        if (!info)
                return its_vlpi_unmap(d);

or that KVM has gotten out of sync with the GIC/ITS (from its_vlpi_unmap()):

        if (!its_dev->event_map.vm || !irqd_is_forwarded_to_vcpu(d))
                return -EINVAL;

All of the above failure scenarios are warnable offences, as they should
never occur absent a kernel/KVM bug.

Acked-by: Oliver Upton 
Link: https://lore.kernel.org/all/aFWY2LTVIxz5rfhh@google.com
Signed-off-by: Sean Christopherson

irqchip/gic-v4: Don't allow a VMOVP on a dying VPE

2024-10-08T15:44:27+00:00

Kunkun Jiang reported that there is a small window of opportunity for
userspace to force a change of affinity for a VPE while the VPE has already
been unmapped, but the corresponding doorbell interrupt still visible in
/proc/irq/.

Plug the race by checking the value of vmapp_count, which tracks whether
the VPE is mapped ot not, and returning an error in this case.

This involves making vmapp_count common to both GICv4.1 and its v4.0
ancestor.

Fixes: 64edfaa9a234 ("irqchip/gic-v4.1: Implement the v4.1 flavour of VMAPP")
Reported-by: Kunkun Jiang 
Signed-off-by: Marc Zyngier 
Signed-off-by: Thomas Gleixner 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/c182ece6-2ba0-ce4f-3404-dba7a3ab6c52@huawei.com
Link: https://lore.kernel.org/all/20241002204959.2051709-1-maz@kernel.org

irqchip/gic-v4: Substitute vmovp_lock for a per-VM lock

2024-07-15T13:13:55+00:00

vmovp_lock is abused in a number of cases to serialise updates
to vlpi_count[] and deal with map/unmap of a VM to ITSs.

Instead, provide a per-VM lock and revisit the use of vlpi_count[]
so that it is always wrapped in this per-VM vmapp_lock.

This reduces the potential contention on a concurrent VMOVP command,
and paves the way for subsequent VPE locking that holding vmovp_lock
actively prevents due to the lock ordering.

Signed-off-by: Marc Zyngier 
Signed-off-by: Thomas Gleixner 
Tested-by: Nianyao Tang 
Link: https://lore.kernel.org/r/20240705093155.871070-3-maz@kernel.org

irqchip/gic-v4.1: Disable vSGI upon (GIC CPUIF < v4.1) detection

2021-04-22T14:55:21+00:00

GIC CPU interfaces versions predating GIC v4.1 were not built to
accommodate vINTID within the vSGI range; as reported in the GIC
specifications (8.2 "Changes to the CPU interface"), it is
CONSTRAINED UNPREDICTABLE to deliver a vSGI to a PE with
ID_AA64PFR0_EL1.GIC < b0011.

Check the GIC CPUIF version by reading the SYS_ID_AA64_PFR0_EL1.

Disable vSGIs if a CPUIF version < 4.1 is detected to prevent using
vSGIs on systems where they may misbehave.

Signed-off-by: Lorenzo Pieralisi 
Cc: Marc Zyngier 
Signed-off-by: Marc Zyngier 
Link: https://lore.kernel.org/r/20210317100719.3331-2-lorenzo.pieralisi@arm.com

KVM: arm64: Delay the polling of the GICR_VPENDBASER.Dirty bit

2020-11-30T11:18:29+00:00

In order to reduce the impact of the VPT parsing happening on the GIC,
we can split the vcpu reseidency in two phases:

- programming GICR_VPENDBASER: this still happens in vcpu_load()
- checking for the VPT parsing to be complete: this can happen
  on vcpu entry (in kvm_vgic_flush_hwstate())

This allows the GIC and the CPU to work in parallel, rewmoving some
of the entry overhead.

Suggested-by: Marc Zyngier 
Signed-off-by: Shenming Lu 
Signed-off-by: Marc Zyngier 
Link: https://lore.kernel.org/r/20201128141857.983-3-lushenming@huawei.com

irqchip/gic-v4.1: Add VSGI property setup

2020-03-24T12:15:51+00:00

Add the SGI configuration entry point for KVM to use.

Signed-off-by: Marc Zyngier 
Reviewed-by: Zenghui Yu 
Link: https://lore.kernel.org/r/20200304203330.4967-16-maz@kernel.org

irqchip/gic-v4.1: Add VSGI allocation/teardown

2020-03-24T12:15:51+00:00

Allocate per-VPE SGIs when initializing the GIC-specific part of the
VPE data structure.

Signed-off-by: Marc Zyngier 
Reviewed-by: Zenghui Yu 
Link: https://lore.kernel.org/r/20200304203330.4967-15-maz@kernel.org

irqchip/gic-v4.1: Move doorbell management to the GICv4 abstraction layer

2020-03-24T12:15:51+00:00

In order to hide some of the differences between v4.0 and v4.1, move
the doorbell management out of the KVM code, and into the GICv4-specific
layer. This allows the calling code to ask for the doorbell when blocking,
and otherwise to leave the doorbell permanently disabled.

This matches the v4.1 code perfectly, and only results in a minor
refactoring of the v4.0 code.

Signed-off-by: Marc Zyngier 
Reviewed-by: Zenghui Yu 
Link: https://lore.kernel.org/r/20200304203330.4967-14-maz@kernel.org

irqchip/gic-v4.1: Plumb set_vcpu_affinity SGI callbacks

2020-03-24T12:15:51+00:00

Just like for vLPIs, there is some configuration information that cannot
be directly communicated through the normal irqchip API, and we have to
use our good old friend set_vcpu_affinity as a side-band communication
mechanism.

This is used to configure group and priority for a given vSGI.

Signed-off-by: Marc Zyngier 
Reviewed-by: Zenghui Yu 
Reviewed-by: Eric Auger 
Link: https://lore.kernel.org/r/20200304203330.4967-13-maz@kernel.org

irqchip/gic-v4.1: Plumb skeletal VSGI irqchip

2020-03-24T12:05:04+00:00

Since GICv4.1 has the capability to inject 16 SGIs into each VPE,
and that I'm keen not to invent too many specific interfaces to
manipulate these interrupts, let's pretend that each of these SGIs
is an actual Linux interrupt.

For that matter, let's introduce a minimal irqchip and irqdomain
setup that will get fleshed up in the following patches.

Signed-off-by: Marc Zyngier 
Reviewed-by: Zenghui Yu 
Reviewed-by: Eric Auger 
Link: https://lore.kernel.org/r/20200304203330.4967-9-maz@kernel.org