linux-toradex.git/include/linux/irqchip/arm-gic-v4.h, branch v6.12

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

irqchip/gic-v4.1: Ensure mutual exclusion between vPE affinity change and RD access

2020-03-19T11:21:58+00:00

Before GICv4.1, all operations would be serialized with the affinity
changes by virtue of using the same ITS command queue. With v4.1, things
change, as invalidations (and a number of other operations) are issued
using the redistributor MMIO frame.

We must thus make sure that these redistributor accesses cannot race
against aginst the affinity change, or we may end-up talking to the
wrong redistributor.

To ensure this, we expand the irq_to_cpuid() helper to take a spinlock
when the LPI is mapped to a vLPI (a new per-VPE lock) on each operation
that requires mutual exclusion.

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