KVM: arm64: Initial host support for the Apple M1

The vGIC advertising code is unsurprisingly very much tied to the GIC implementations. However, we are about to extend the support to lesser implementations.

Let's dissociate the vgic registration from the GIC code and move it into KVM, where it makes a bit more sense. This also allows us to mark the gic_kvm_info structures as __initdata.

Signed-off-by Marc Zyngier <[email protected]>

---
 arch/arm64/kvm/vgic/vgic-init.c        | 18 +++++++++--
 drivers/irqchip/irq-gic-common.c       | 13 --------
 drivers/irqchip/irq-gic-common.h       |  2 --
 drivers/irqchip/irq-gic-v3.c           |  6 ++--
 drivers/irqchip/irq-gic.c              |  6 ++--
 include/linux/irqchip/arm-gic-common.h | 25 +---------------
 include/linux/irqchip/arm-vgic-info.h  | 41 ++++++++++++++++++++++++++
 7 files changed, 63 insertions(+), 48 deletions(-)
 create mode 100644 include/linux/irqchip/arm-vgic-info.h

arch/arm64/kvm/vgic/vgic-init.c +10 -2

index 58cbda00e56d..2fdb65529594 100644
@@ -482,6 +482,16 @@ static irqreturn_t vgic_maintenance_handler(int irq, void *data)
 	return IRQ_HANDLED;
 }
 
+static struct gic_kvm_info *gic_kvm_info;
+
+void __init vgic_set_kvm_info(const struct gic_kvm_info *info)
+{
+	BUG_ON(gic_kvm_info != NULL);
+	gic_kvm_info = kmalloc(sizeof(*info), GFP_KERNEL);
+	if (gic_kvm_info)
+		*gic_kvm_info = *info;
+}
+
 /**
  * kvm_vgic_init_cpu_hardware - initialize the GIC VE hardware
  *

@@ -509,10 +519,8 @@ void kvm_vgic_init_cpu_hardware(void)
  */
 int kvm_vgic_hyp_init(void)
 {
-	const struct gic_kvm_info *gic_kvm_info;
 	int ret;
 
-	gic_kvm_info = gic_get_kvm_info();
 	if (!gic_kvm_info)
 		return -ENODEV;
 

arch/arm64/kvm/vgic/vgic-init.c +1 -1

+
 	if (ret)
 		return ret;
 
-	kvm_vgic_global_state.maint_irq = gic_kvm_info->maint_irq;
 	ret = request_percpu_irq(kvm_vgic_global_state.maint_irq,
 				 vgic_maintenance_handler,
 				 "vgic", kvm_get_running_vcpus());

drivers/irqchip/irq-gic-common.c +0 -13

index f47b41dfd023..a610821c8ff2 100644
@@ -12,19 +12,6 @@
 
 static DEFINE_RAW_SPINLOCK(irq_controller_lock);
 
-static const struct gic_kvm_info *gic_kvm_info;
-
-const struct gic_kvm_info *gic_get_kvm_info(void)
-{
-	return gic_kvm_info;
-}
-
-void gic_set_kvm_info(const struct gic_kvm_info *info)
-{
-	BUG_ON(gic_kvm_info != NULL);
-	gic_kvm_info = info;
-}
-
 void gic_enable_of_quirks(const struct device_node *np,
 			  const struct gic_quirk *quirks, void *data)
 {

drivers/irqchip/irq-gic-common.h +0 -2

index ccba8b0fe0f5..27e3d4ed4f32 100644
@@ -28,6 +28,4 @@ void gic_enable_quirks(u32 iidr, const struct gic_quirk *quirks,
 void gic_enable_of_quirks(const struct device_node *np,
 			  const struct gic_quirk *quirks, void *data);
 
-void gic_set_kvm_info(const struct gic_kvm_info *info);
-
 #endif /* _IRQ_GIC_COMMON_H */

drivers/irqchip/irq-gic-v3.c +3 -3

index 37a23aa6de37..453fc425eede 100644
@@ -103,7 +103,7 @@ EXPORT_SYMBOL(gic_nonsecure_priorities);
 /* ppi_nmi_refs[n] == number of cpus having ppi[n + 16] set as NMI */
 static refcount_t *ppi_nmi_refs;
 
-static struct gic_kvm_info gic_v3_kvm_info;
+static struct gic_kvm_info gic_v3_kvm_info __initdata;
 static DEFINE_PER_CPU(bool, has_rss);
 
 #define MPIDR_RS(mpidr)			(((mpidr) & 0xF0UL) >> 4)

@@ -1852,7 +1852,7 @@ static void __init gic_of_setup_kvm_info(struct device_node *node)
 
 	gic_v3_kvm_info.has_v4 = gic_data.rdists.has_vlpis;
 	gic_v3_kvm_info.has_v4_1 = gic_data.rdists.has_rvpeid;
-	gic_set_kvm_info(&gic_v3_kvm_info);
+	vgic_set_kvm_info(&gic_v3_kvm_info);
 }
 
 static int __init gic_of_init(struct device_node *node, struct device_node *parent)

@@ -2168,7 +2168,7 @@ static void __init gic_acpi_setup_kvm_info(void)
 
 	gic_v3_kvm_info.has_v4 = gic_data.rdists.has_vlpis;
 	gic_v3_kvm_info.has_v4_1 = gic_data.rdists.has_rvpeid;
-	gic_set_kvm_info(&gic_v3_kvm_info);
+	vgic_set_kvm_info(&gic_v3_kvm_info);
 }
 
 static int __init

drivers/irqchip/irq-gic.c +3 -3

index b1d9c22caf2e..2de9ec8ece0c 100644
@@ -119,7 +119,7 @@ static DEFINE_STATIC_KEY_TRUE(supports_deactivate_key);
 
 static struct gic_chip_data gic_data[CONFIG_ARM_GIC_MAX_NR] __read_mostly;
 
-static struct gic_kvm_info gic_v2_kvm_info;
+static struct gic_kvm_info gic_v2_kvm_info __initdata;
 
 static DEFINE_PER_CPU(u32, sgi_intid);
 

@@ -1451,7 +1451,7 @@ static void __init gic_of_setup_kvm_info(struct device_node *node)
 		return;
 
 	if (static_branch_likely(&supports_deactivate_key))
-		gic_set_kvm_info(&gic_v2_kvm_info);
+		vgic_set_kvm_info(&gic_v2_kvm_info);
 }
 
 int __init

@@ -1618,7 +1618,7 @@ static void __init gic_acpi_setup_kvm_info(void)
 
 	gic_v2_kvm_info.maint_irq = irq;
 
-	gic_set_kvm_info(&gic_v2_kvm_info);
+	vgic_set_kvm_info(&gic_v2_kvm_info);
 }
 
 static int __init gic_v2_acpi_init(union acpi_subtable_headers *header,

include/linux/irqchip/arm-gic-common.h +1 -24

index fa8c0455c352..1177f3a1aed5 100644
@@ -7,8 +7,7 @@
 #ifndef __LINUX_IRQCHIP_ARM_GIC_COMMON_H
 #define __LINUX_IRQCHIP_ARM_GIC_COMMON_H
 
-#include <linux/types.h>
-#include <linux/ioport.h>
+#include <linux/irqchip/arm-vgic-info.h>
 
 #define GICD_INT_DEF_PRI		0xa0
 #define GICD_INT_DEF_PRI_X4		((GICD_INT_DEF_PRI << 24) |\

@@ -16,28 +15,6 @@
 					(GICD_INT_DEF_PRI << 8) |\
 					GICD_INT_DEF_PRI)
 
-enum gic_type {
-	GIC_V2,
-	GIC_V3,
-};
-
-struct gic_kvm_info {
-	/* GIC type */
-	enum gic_type	type;
-	/* Virtual CPU interface */
-	struct resource vcpu;
-	/* Interrupt number */
-	unsigned int	maint_irq;
-	/* Virtual control interface */
-	struct resource vctrl;
-	/* vlpi support */
-	bool		has_v4;
-	/* rvpeid support */
-	bool		has_v4_1;
-};
-
-const struct gic_kvm_info *gic_get_kvm_info(void);
-
 struct irq_domain;
 struct fwnode_handle;
 int gicv2m_init(struct fwnode_handle *parent_handle,

include/linux/irqchip/arm-vgic-info.h new file +0 -0

new file mode 100644
index 000000000000..0319636be928

include/linux/irqchip/arm-vgic-info.h new file +33 -0

+
+#include <linux/types.h>
+#include <linux/ioport.h>
+
+enum gic_type {
+	/* Full GICv2 */
+	GIC_V2,
+	/* Full GICv3, optionally with v2 compat */
+	GIC_V3,
+};
+
+struct gic_kvm_info {
+	/* GIC type */
+	enum gic_type	type;
+	/* Virtual CPU interface */
+	struct resource vcpu;
+	/* Interrupt number */
+	unsigned int	maint_irq;
+	/* Virtual control interface */
+	struct resource vctrl;
+	/* vlpi support */
+	bool		has_v4;
+	/* rvpeid support */
+	bool		has_v4_1;
+};
+
+#ifdef CONFIG_KVM
+void vgic_set_kvm_info(const struct gic_kvm_info *info);
+#else
+static inline void vgic_set_kvm_info(const struct gic_kvm_info *info) {}
+#endif
+
+#endif

As we we now entertain the possibility of FIQ being used on the host, treat the signalling of a FIQ while running a guest as an IRQ, causing an exit instead of a HYP panic.

Signed-off-by Marc Zyngier <[email protected]>

---
 arch/arm64/kvm/hyp/hyp-entry.S | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

arch/arm64/kvm/hyp/hyp-entry.S +3 -3

index 5f49df4ffdd8..9aa9b73475c9 100644
@@ -76,6 +76,7 @@ el1_trap:
 	b	__guest_exit
 
 el1_irq:
+el1_fiq:
 	get_vcpu_ptr	x1, x0
 	mov	x0, #ARM_EXCEPTION_IRQ
 	b	__guest_exit

@@ -131,7 +132,6 @@ SYM_CODE_END(\label)
 	invalid_vector	el2t_error_invalid
 	invalid_vector	el2h_irq_invalid
 	invalid_vector	el2h_fiq_invalid
-	invalid_vector	el1_fiq_invalid
 
 	.ltorg
 

@@ -179,12 +179,12 @@ SYM_CODE_START(__kvm_hyp_vector)
 
 	valid_vect	el1_sync		// Synchronous 64-bit EL1
 	valid_vect	el1_irq			// IRQ 64-bit EL1
-	invalid_vect	el1_fiq_invalid		// FIQ 64-bit EL1
+	valid_vect	el1_fiq			// FIQ 64-bit EL1
 	valid_vect	el1_error		// Error 64-bit EL1
 
 	valid_vect	el1_sync		// Synchronous 32-bit EL1
 	valid_vect	el1_irq			// IRQ 32-bit EL1
-	invalid_vect	el1_fiq_invalid		// FIQ 32-bit EL1
+	valid_vect	el1_fiq			// FIQ 32-bit EL1
 	valid_vect	el1_error		// Error 32-bit EL1
 SYM_CODE_END(__kvm_hyp_vector)
 

As it turns out, not all the interrupt controllers are able to expose a vGIC maintenance interrupt as a distrete signal. And to be fair, it doesn't really matter as all we require is for *something* to kick us out of guest mode out way or another.

On systems that do not expose a maintenance interrupt as such, there are two outcomes:

- either the virtual CPUIF does generate an interrupt, and by the time we are back to the host the interrupt will have long been disabled (as we set ICH_HCR_EL2.EN to 0 on exit). In this case, interrupt latency is as good as it gets.

- or some other event (physical timer) will take us out of the guest anyway, and the only drawback is a bad interrupt latency.

So let's be tolerant to the lack of maintenance interrupt, and just let the user know that their mileage may vary...

Signed-off-by Marc Zyngier <[email protected]>

---
 arch/arm64/kvm/vgic/vgic-init.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

arch/arm64/kvm/vgic/vgic-init.c +5 -5

index 2fdb65529594..9fd23f32aa54 100644
@@ -524,11 +524,6 @@ int kvm_vgic_hyp_init(void)
 	if (!gic_kvm_info)
 		return -ENODEV;
 
-	if (!gic_kvm_info->maint_irq) {
-		kvm_err("No vgic maintenance irq\n");
-		return -ENXIO;
-	}
-
 	switch (gic_kvm_info->type) {
 	case GIC_V2:
 		ret = vgic_v2_probe(gic_kvm_info);

@@ -552,6 +547,11 @@ int kvm_vgic_hyp_init(void)
 	if (ret)
 		return ret;
 
+	if (!kvm_vgic_global_state.maint_irq) {
+		kvm_err("No maintenance interrupt available, fingers crossed...\n");
+		return 0;
+	}
+
 	ret = request_percpu_irq(kvm_vgic_global_state.maint_irq,
 				 vgic_maintenance_handler,
 				 "vgic", kvm_get_running_vcpus());

Signature · 1 line

2.29.2

Quoted 13 lines · Marc Zyngier

As it turns out, not all the interrupt controllers are able to expose a vGIC maintenance interrupt as a distrete signal. And to be fair, it doesn't really matter as all we require is for *something* to kick us out of guest mode out way or another.

On systems that do not expose a maintenance interrupt as such, there are two outcomes:

- either the virtual CPUIF does generate an interrupt, and by the time we are back to the host the interrupt will have long been disabled (as we set ICH_HCR_EL2.EN to 0 on exit). In this case, interrupt latency is as good as it gets.

Quoted 2 lines

- or some other event (physical timer) will take us out of the guest anyway, and the only drawback is a bad interrupt latency.

IIRC we won't have a a guaranteed schedular tick for NO_HZ_FULL, so in that case we'll either need to set a period software maintenance interrupt, or reject this combination at runtime (either when trying to isolate the dynticks CPUs, or when trying to create a VM).

Quoted 15 lines · Mark Rutland

Quoted 13 lines · Marc Zyngier

As it turns out, not all the interrupt controllers are able to expose a vGIC maintenance interrupt as a distrete signal. And to be fair, it doesn't really matter as all we require is for *something* to kick us out of guest mode out way or another.

On systems that do not expose a maintenance interrupt as such, there are two outcomes:

- either the virtual CPUIF does generate an interrupt, and by the time we are back to the host the interrupt will have long been disabled (as we set ICH_HCR_EL2.EN to 0 on exit). In this case, interrupt latency is as good as it gets.

Quoted 7 lines

Quoted 2 lines

- or some other event (physical timer) will take us out of the guest anyway, and the only drawback is a bad interrupt latency.

IIRC we won't have a a guaranteed schedular tick for NO_HZ_FULL, so in that case we'll either need to set a period software maintenance interrupt, or reject this combination at runtime (either when trying to isolate the dynticks CPUs, or when trying to create a VM).

That's a good point.

On sensible systems, the maintenance interrupt is a standard GIC PPI that requires enabling, and that is all that KVM requires (the maintenance interrupt is only used as an exit mechanism and will be disabled before reaching the handler).

On the M1, owing to the lack of a per-CPU interrupt controller, there is nothing to enable. The virtual CPU interface will fire at will and take us out of the guest in a timely manner.

So maybe instead of relaxing the requirement for a maintenance interrupt, we should only bypass the checks if the root interrupt controller advertises that it is safe to do so, making it a M1-specific hack.

The vGIC, as architected by ARM, allows a virtual interrupt to trigger the deactivation of a physical interrupt. This allows the following interrupt to be delivered without requiring an exit.

However, some implementations have choosen not to implement this, meaning that we will need some unsavoury workarounds to deal with this.

On detecting such a case, taint the kernel and spit a nastygram. We'll deal with this in later patches.

Signed-off-by Marc Zyngier <[email protected]>

---
 arch/arm64/kvm/vgic/vgic-init.c       | 10 ++++++++++
 include/kvm/arm_vgic.h                |  3 +++
 include/linux/irqchip/arm-vgic-info.h |  2 ++
 3 files changed, 15 insertions(+)

arch/arm64/kvm/vgic/vgic-init.c +0 -0

index 9fd23f32aa54..5b06a9970a57 100644
@@ -524,6 +524,16 @@ int kvm_vgic_hyp_init(void)
 	if (!gic_kvm_info)
 		return -ENODEV;

arch/arm64/kvm/vgic/vgic-init.c +1 -0

+
 	switch (gic_kvm_info->type) {
 	case GIC_V2:
 		ret = vgic_v2_probe(gic_kvm_info);

include/kvm/arm_vgic.h +3 -0

index ec621180ef09..e45b26e8d479 100644
@@ -72,6 +72,9 @@ struct vgic_global {
 	bool			has_gicv4;
 	bool			has_gicv4_1;
 
+	/* Pseudo GICv3 from outer space */
+	bool			no_hw_deactivation;
+
 	/* GIC system register CPU interface */
 	struct static_key_false gicv3_cpuif;
 

include/linux/irqchip/arm-vgic-info.h +2 -0

index 0319636be928..d39d0b591c5a 100644
@@ -30,6 +30,8 @@ struct gic_kvm_info {
 	bool		has_v4;
 	/* rvpeid support */
 	bool		has_v4_1;
+	/* Deactivation impared, subpar stuff */
+	bool		no_hw_deactivation;
 };
 
 #ifdef CONFIG_KVM

Hi Marc,

Quoted 3 lines · Marc Zyngier

The vGIC, as architected by ARM, allows a virtual interrupt to trigger the deactivation of a physical interrupt. This allows the following interrupt to be delivered without requiring an exit.

If I got this right, the AIC doesn't implement/ignores the

ICH_LR_EL2.HW bit. Does it mean that the CPU IF behaves as if HW = 0b0, meaning it asserts a maintenance interrupt on virtual interrupt deactivation when ICH_LR_EL2.EOI = 0b1? I assume that's the case, just double checking.

I am wondering what would happen if we come across an interrupt controller where the CPU IF cannot assert a maintenance interrupt at all and we rely on the EOI bit to take us out of the guest to deactivate the HW interrupt.

I have to say that it looks a bit strange to start relying on the maintenance interrupt to emulate interrupt deactivate for hardware interrupts, but at the same timer allowing an interrupt controller without a maintenance interrupt.

Other than that, this idea sounds like the best thing to do considering the circumstances, I certainly can't think of anything better.

Quoted 22 lines

However, some implementations have choosen not to implement this, meaning that we will need some unsavoury workarounds to deal with this.

On detecting such a case, taint the kernel and spit a nastygram. We'll deal with this in later patches.

Signed-off-by Marc Zyngier <[email protected]>

---
 arch/arm64/kvm/vgic/vgic-init.c       | 10 ++++++++++
 include/kvm/arm_vgic.h                |  3 +++
 include/linux/irqchip/arm-vgic-info.h |  2 ++
 3 files changed, 15 insertions(+)

arch/arm64/kvm/vgic/vgic-init.c +0 -0

index 9fd23f32aa54..5b06a9970a57 100644
@@ -524,6 +524,16 @@ int kvm_vgic_hyp_init(void)
 	if (!gic_kvm_info)
 		return -ENODEV;
 

arch/arm64/kvm/vgic/vgic-init.c int kvm_vgic_hyp_init(void) · line 535

Quoted 9 lines

arch/arm64/kvm/vgic/vgic-init.c +9 -0

+	/*
+	 * If we get one of these oddball non-GICs, taint the kernel,
+	 * as we have no idea of how they *really* behave.
+	 */
+	if (gic_kvm_info->no_hw_deactivation) {
+		kvm_info("Non-architectural vgic, tainting kernel\n");
+		add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_STILL_OK);
+		kvm_vgic_global_state.no_hw_deactivation = true;
+	}

IMO, since this means we're going to rely even more on the maintenance interrupt (not just for software emulation of level sensitive interrupts), I think there should be some sort of dependency on having something that resembles a working maintenance interrupt.

In order to deal with these systems that do not offer HW-based deactivation of interrupts, let implement a SW-based approach:

- When the irq is queued into a LR, treat it as a pure virtual interrupt and set the EOI flag in the LR.

- When the interrupt state is read back from the LR, force a deactivation when the state is invalid (neither active nor pending)

Interrupts requiring such treatment get the VGIC_SW_RESAMPLE flag.

Signed-off-by Marc Zyngier <[email protected]>

---
 arch/arm64/kvm/vgic/vgic-v2.c | 19 +++++++++++++++----
 arch/arm64/kvm/vgic/vgic-v3.c | 19 +++++++++++++++----
 include/kvm/arm_vgic.h        | 10 ++++++++++
 3 files changed, 40 insertions(+), 8 deletions(-)

arch/arm64/kvm/vgic/vgic-v2.c +3 -0

index 11934c2af2f4..2c580204f1dc 100644
@@ -108,11 +108,22 @@ void vgic_v2_fold_lr_state(struct kvm_vcpu *vcpu)
 		 * If this causes us to lower the level, we have to also clear
 		 * the physical active state, since we will otherwise never be
 		 * told when the interrupt becomes asserted again.
+		 *
+		 * Another case is when the interrupt requires a helping hand
+		 * on deactivation (no HW deactivation, for example).
 		 */

arch/arm64/kvm/vgic/vgic-v2.c +1 -1

 				vgic_irq_set_phys_active(irq, false);
 		}
 

@@ -152,7 +163,7 @@ void vgic_v2_populate_lr(struct kvm_vcpu *vcpu, struct vgic_irq *irq, int lr)
 	if (irq->group)
 		val |= GICH_LR_GROUP1;
 
-	if (irq->hw) {
+	if (irq->hw && !vgic_irq_needs_resampling(irq)) {
 		val |= GICH_LR_HW;
 		val |= irq->hwintid << GICH_LR_PHYSID_CPUID_SHIFT;
 		/*

arch/arm64/kvm/vgic/vgic-v3.c +15 -4

index 41ecf219c333..66004f61cd83 100644
@@ -101,11 +101,22 @@ void vgic_v3_fold_lr_state(struct kvm_vcpu *vcpu)
 		 * If this causes us to lower the level, we have to also clear
 		 * the physical active state, since we will otherwise never be
 		 * told when the interrupt becomes asserted again.
+		 *
+		 * Another case is when the interrupt requires a helping hand
+		 * on deactivation (no HW deactivation, for example).
 		 */
-		if (vgic_irq_is_mapped_level(irq) && (val & ICH_LR_PENDING_BIT)) {
-			irq->line_level = vgic_get_phys_line_level(irq);
+		if (vgic_irq_is_mapped_level(irq)) {
+			bool resample = false;
+
+			if (val & ICH_LR_PENDING_BIT) {
+				irq->line_level = vgic_get_phys_line_level(irq);
+				resample = !irq->line_level;
+			} else if (vgic_irq_needs_resampling(irq) &&
+				   !(irq->active || irq->pending_latch)) {
+				resample = true;
+			}
 
-			if (!irq->line_level)
+			if (resample)
 				vgic_irq_set_phys_active(irq, false);
 		}
 

@@ -136,7 +147,7 @@ void vgic_v3_populate_lr(struct kvm_vcpu *vcpu, struct vgic_irq *irq, int lr)
 		}
 	}
 
-	if (irq->hw) {
+	if (irq->hw && !vgic_irq_needs_resampling(irq)) {
 		val |= ICH_LR_HW;
 		val |= ((u64)irq->hwintid) << ICH_LR_PHYS_ID_SHIFT;
 		/*

include/kvm/arm_vgic.h +10 -0

index e5f06df000f2..e602d848fc1a 100644
@@ -99,6 +99,11 @@ enum vgic_irq_config {
  * kvm_arm_get_running_vcpu() to get the vcpu pointer for private IRQs.
  */
 struct irq_ops {
+	/* Per interrupt flags for special-cased interrupts */
+	unsigned long flags;
+
+#define VGIC_IRQ_SW_RESAMPLE	BIT(0)	/* Clear the active state for resampling */
+
 	/*
 	 * Callback function pointer to in-kernel devices that can tell us the
 	 * state of the input level of mapped level-triggered IRQ faster than

@@ -150,6 +155,11 @@ struct vgic_irq {
 					   for in-kernel devices. */
 };
 
+static inline bool vgic_irq_needs_resampling(struct vgic_irq *irq)
+{
+	return irq->ops && (irq->ops->flags & VGIC_IRQ_SW_RESAMPLE);
+}
+
 struct vgic_register_region;
 struct vgic_its;
 

Hi Marc,

Some questions regarding how this is supposed to work.

Quoted 37 lines · Marc Zyngier

In order to deal with these systems that do not offer HW-based deactivation of interrupts, let implement a SW-based approach:

- When the irq is queued into a LR, treat it as a pure virtual interrupt and set the EOI flag in the LR.

- When the interrupt state is read back from the LR, force a deactivation when the state is invalid (neither active nor pending)

Interrupts requiring such treatment get the VGIC_SW_RESAMPLE flag.

Signed-off-by Marc Zyngier <[email protected]>

---
 arch/arm64/kvm/vgic/vgic-v2.c | 19 +++++++++++++++----
 arch/arm64/kvm/vgic/vgic-v3.c | 19 +++++++++++++++----
 include/kvm/arm_vgic.h        | 10 ++++++++++
 3 files changed, 40 insertions(+), 8 deletions(-)

arch/arm64/kvm/vgic/vgic-v2.c +7 -2

index 11934c2af2f4..2c580204f1dc 100644
@@ -108,11 +108,22 @@ void vgic_v2_fold_lr_state(struct kvm_vcpu *vcpu)
 		 * If this causes us to lower the level, we have to also clear
 		 * the physical active state, since we will otherwise never be
 		 * told when the interrupt becomes asserted again.
+		 *
+		 * Another case is when the interrupt requires a helping hand
+		 * on deactivation (no HW deactivation, for example).
 		 */
-		if (vgic_irq_is_mapped_level(irq) && (val & GICH_LR_PENDING_BIT)) {
-			irq->line_level = vgic_get_phys_line_level(irq);
+		if (vgic_irq_is_mapped_level(irq)) {
+			bool resample = false;
+
+			if (val & GICH_LR_PENDING_BIT) {

arch/arm64/kvm/vgic/vgic-v2.c void vgic_v2_fold_lr_state(struct kvm_vcpu *vcpu) · line 122

Quoted 4 lines

arch/arm64/kvm/vgic/vgic-v2.c +4 -0

+				irq->line_level = vgic_get_phys_line_level(irq);
+				resample = !irq->line_level;
+			} else if (vgic_irq_needs_resampling(irq) &&
+				   !(irq->active || irq->pending_latch)) {

So this means that if the IRQ has the special flag, if it's not pending in the LR or at the software level, and it's not active either, then perform interrupt deactivation.

I don't see where the state of the interrupt is checked again, am I correct in assuming that we rely on the CPU interface to assert the interrupt to the host while we run with interrupts enabled in the run loop, and the handler for the interrupt will mark it pending for kvm_vgic_sync_hw_state->vgic_vx_fold_lr_state?

Quoted 4 lines

arch/arm64/kvm/vgic/vgic-v2.c +2 -0

+				resample = true;
+			}
 

arch/arm64/kvm/vgic/vgic-v2.c void vgic_v2_fold_lr_state(struct kvm_vcpu *vcpu) · line 126

Quoted 2 lines

arch/arm64/kvm/vgic/vgic-v2.c +1 -1

-			if (!irq->line_level)
+			if (resample)

This name, "resample", is confusing to me, quite possibly because I'm not familiar with the irqchip subsystem. It was my impression that "resample" means that at some point, the physical interrupt state will be checked again, yet I don't see that happening anywhere when VGIC_IRQ_SW_RESAMPLE is set. Am I mistaken in my assumptions?

As we are about to add some more things to the timer IRQ configuration, move this code out of the main timer init code into its own set of functions.

No functional changes.

Signed-off-by Marc Zyngier <[email protected]>

---
 arch/arm64/kvm/arch_timer.c | 61 ++++++++++++++++++++++---------------
 1 file changed, 37 insertions(+), 24 deletions(-)

arch/arm64/kvm/arch_timer.c +5 -0

index e2288b6bf435..7fa4f446456a 100644
@@ -973,6 +973,39 @@ static int kvm_timer_dying_cpu(unsigned int cpu)
 	return 0;
 }
 
+static void kvm_irq_fixup_flags(unsigned int virq, u32 *flags)
+{
+	*flags = irq_get_trigger_type(virq);
+	if (*flags != IRQF_TRIGGER_HIGH && *flags != IRQF_TRIGGER_LOW) {
+		kvm_err("Invalid trigger for timer IRQ%d, assuming level low\n",

arch/arm64/kvm/arch_timer.c +7 -0

+
+	if (info->virtual_irq <= 0) {
+		kvm_err("kvm_arch_timer: invalid virtual timer IRQ: %d\n",
+			info->virtual_irq);
+		return -ENODEV;
+	}
+

Quoted 28 lines · Marc Zyngier

As we are about to add some more things to the timer IRQ configuration, move this code out of the main timer init code into its own set of functions.

No functional changes.

Signed-off-by Marc Zyngier <[email protected]>

---
 arch/arm64/kvm/arch_timer.c | 61 
++++++++++++++++++++++---------------
 1 file changed, 37 insertions(+), 24 deletions(-)

arch/arm64/kvm/arch_timer.c +8 -0

index e2288b6bf435..7fa4f446456a 100644
@@ -973,6 +973,39 @@ static int kvm_timer_dying_cpu(unsigned int cpu)
 	return 0;
 }
 +static void kvm_irq_fixup_flags(unsigned int virq, u32 *flags)
+{
+	*flags = irq_get_trigger_type(virq);
+	if (*flags != IRQF_TRIGGER_HIGH && *flags != IRQF_TRIGGER_LOW) {
+		kvm_err("Invalid trigger for timer IRQ%d, assuming level low\n",
+			virq);
+		*flags = IRQF_TRIGGER_LOW;
+	}
+}

arch/arm64/kvm/arch_timer.c static int kvm_timer_dying_cpu(unsigned int cpu) · line 990

Quoted 6 lines

arch/arm64/kvm/arch_timer.c +6 -0

+
+static int kvm_irq_init(struct arch_timer_kvm_info *info)
+{
+	struct irq_domain *domain = NULL;
+	struct fwnode_handle *fwnode;
+	struct irq_data *data;

Shouldn't this belong to patch #8?

This is a new version of the series previously posted at [2], reworking the vGIC and timer code to cope with the M1 braindead^Wamusing nature.

Hardly any change this time around, mostly rebased on top of upstream now that the dependencies have made it in.

Tested with multiple concurrent VMs running from an initramfs.

* From v2:
- Rebased on 5.13-rc1
- Fixed a couple of nits in the GIC registration code

* From v1 [1]:
- Rebased on Hector's v4 posting[0]
- Dropped a couple of patches that have been merged in the above series
- Fixed irq_ack callback on the timer path

[0] https://lore.kernel.org/r/[email protected]
[1] https://lore.kernel.org/r/[email protected]
[2] https://lore.kernel.org/r/[email protected]

Marc Zyngier (9):
irqchip/gic: Split vGIC probing information from the GIC code
KVM: arm64: Handle physical FIQ as an IRQ while running a guest
KVM: arm64: vgic: Be tolerant to the lack of maintenance interrupt
KVM: arm64: vgic: Let an interrupt controller advertise lack of HW
deactivation
KVM: arm64: vgic: move irq->get_input_level into an ops structure
KVM: arm64: vgic: Implement SW-driven deactivation
KVM: arm64: timer: Refactor IRQ configuration
KVM: arm64: timer: Add support for SW-based deactivation irqchip/apple-aic: Advertise some level of vGICv3 compatibility

 arch/arm64/kvm/arch_timer.c            | 161 +++++++++++++++++++++----
 arch/arm64/kvm/hyp/hyp-entry.S         |   6 +-
 arch/arm64/kvm/vgic/vgic-init.c        |  34 +++++-
 arch/arm64/kvm/vgic/vgic-v2.c          |  19 ++-
 arch/arm64/kvm/vgic/vgic-v3.c          |  19 ++-
 arch/arm64/kvm/vgic/vgic.c             |  14 +--
 drivers/irqchip/irq-apple-aic.c        |   8 ++
 drivers/irqchip/irq-gic-common.c       |  13 --
 drivers/irqchip/irq-gic-common.h       |   2 -
 drivers/irqchip/irq-gic-v3.c           |   6 +-
 drivers/irqchip/irq-gic.c              |   6 +-
 include/kvm/arm_vgic.h                 |  41 +++++--
 include/linux/irqchip/arm-gic-common.h |  25 +---
 include/linux/irqchip/arm-vgic-info.h  |  43 +++++++
 14 files changed, 291 insertions(+), 106 deletions(-)
 create mode 100644 include/linux/irqchip/arm-vgic-info.h

Hi Marc,

Quoted 17 lines · Marc Zyngier

This is a new version of the series previously posted at [2], reworking the vGIC and timer code to cope with the M1 braindead^Wamusing nature.

Hardly any change this time around, mostly rebased on top of upstream now that the dependencies have made it in.

Tested with multiple concurrent VMs running from an initramfs.

* From v2:
- Rebased on 5.13-rc1
- Fixed a couple of nits in the GIC registration code

* From v1 [1]:
- Rebased on Hector's v4 posting[0]
- Dropped a couple of patches that have been merged in the above series
- Fixed irq_ack callback on the timer path

Quoted 3 lines

[0] https://lore.kernel.org/r/[email protected]
[1] https://lore.kernel.org/r/[email protected]
[2] https://lore.kernel.org/r/[email protected]

This looks interesting and I want to take a look. For now, I can only review the series, but maybe at some point I'll take the leap and try to run Linux on my Macbook Air.

Can I find something resembling a specification for the Apple interrupt controller, or the only available documentation is in the Linux driver and patches on the mailing list?