KVM: arm64: Initial host support for the Apple M1

As it turns out, not all the interrupt controllers are able to expose a vGIC maintenance interrupt that can be independently enabled/disabled.

And to be fair, it doesn't really matter as all we require is for the interrupt to kick us out of guest mode out way or another.

To that effect, add gic_kvm_info.no_maint_irq_mask for an interrupt controller to advertise the lack of masking.

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

---
 arch/arm64/kvm/vgic/vgic-init.c       | 8 +++++++-
 include/linux/irqchip/arm-vgic-info.h | 2 ++
 2 files changed, 9 insertions(+), 1 deletion(-)

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

index 2fdb65529594..6752d084934d 100644
@@ -519,12 +519,15 @@ void kvm_vgic_init_cpu_hardware(void)
  */

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

+
+	if (has_mask && !gic_kvm_info->maint_irq) {
 		kvm_err("No vgic maintenance irq\n");
 		return -ENXIO;
 	}

@@ -552,6 +555,9 @@ int kvm_vgic_hyp_init(void)
 	if (ret)
 		return ret;
 
+	if (!has_mask)
+		return 0;
+
 	ret = request_percpu_irq(kvm_vgic_global_state.maint_irq,
 				 vgic_maintenance_handler,
 				 "vgic", kvm_get_running_vcpus());

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

index a25d4da5697d..7c0d08ebb82c 100644
@@ -24,6 +24,8 @@ struct gic_kvm_info {
 	struct resource vcpu;
 	/* Interrupt number */
 	unsigned int	maint_irq;
+	/* No interrupt mask, no need to use the above field */
+	bool		no_maint_irq_mask;
 	/* Virtual control interface */
 	struct resource vctrl;
 	/* vlpi support */

Hi Marc,

Quoted 27 lines · Marc Zyngier

As it turns out, not all the interrupt controllers are able to expose a vGIC maintenance interrupt that can be independently enabled/disabled.

And to be fair, it doesn't really matter as all we require is for the interrupt to kick us out of guest mode out way or another.

To that effect, add gic_kvm_info.no_maint_irq_mask for an interrupt controller to advertise the lack of masking.

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

---
 arch/arm64/kvm/vgic/vgic-init.c       | 8 +++++++-
 include/linux/irqchip/arm-vgic-info.h | 2 ++
 2 files changed, 9 insertions(+), 1 deletion(-)

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

index 2fdb65529594..6752d084934d 100644
@@ -519,12 +519,15 @@ void kvm_vgic_init_cpu_hardware(void)
  */
 int kvm_vgic_hyp_init(void)
 {
+	bool has_mask;
 	int ret;
 

arch/arm64/kvm/vgic/vgic-init.c void kvm_vgic_init_cpu_hardware(void) · line 528

Quoted 5 lines

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

 	if (!gic_kvm_info)
 		return -ENODEV;
 
-	if (!gic_kvm_info->maint_irq) {
+	has_mask = !gic_kvm_info->no_maint_irq_mask;

This double negative is pretty awkward, I suppose this was done to avoid changes to the gic drivers, because the default value is 0 (false). Just an idea, maybe renaming it to maint_irq_unmaskable would be more readable?

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 6752d084934d..340c51d87677 100644

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

+		kvm_vgic_global_state.no_hw_deactivation = true;
+	}
+
 	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 +0 -0

index 7c0d08ebb82c..a75b2c7de69d 100644

Hi Marc,

Quoted 22 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.

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 6752d084934d..340c51d87677 100644

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

Quoted 10 lines

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

@@ -532,6 +532,16 @@ int kvm_vgic_hyp_init(void)
 		return -ENXIO;
 	}
 
+	/*
+	 * 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);

I'm trying to figure out what are the effects of tainting the kernel, besides those nasty messages. In Documentation/admin-guide/tainted-kernels.rst, I found this bit:

[..] the information is mainly of interest once someone wants to investigate some problem, as its real cause might be the event that got the kernel tainted. That's why bug reports from tainted kernels will often be ignored by developers, hence try to reproduce problems with an untainted kernel.

The lack of HW deactivation affects only KVM, I was wondering if we could taint the kernel the first time a VM created. If the above doc is to go by, someone who is running Linux on an M1, but not using KVM, might stand a better chance to get support when something goes wrong in that case.

What do you think?

We already have the option to attach a callback to an interrupt to retrieve its pending state. As we are planning to expand this facility, move this callback into its own data structure.

This will limit the size of individual interrupts as the ops structures can be shared across multiple interrupts.

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

---
 arch/arm64/kvm/arch_timer.c |  8 ++++++--
 arch/arm64/kvm/vgic/vgic.c  | 14 +++++++-------
 include/kvm/arm_vgic.h      | 28 +++++++++++++++++-----------
 3 files changed, 30 insertions(+), 20 deletions(-)

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

index 74e0699661e9..e2288b6bf435 100644

arch/arm64/kvm/arch_timer.c +4 -2

+};
+
 int kvm_timer_enable(struct kvm_vcpu *vcpu)
 {
 	struct arch_timer_cpu *timer = vcpu_timer(vcpu);

@@ -1143,7 +1147,7 @@ int kvm_timer_enable(struct kvm_vcpu *vcpu)
 	ret = kvm_vgic_map_phys_irq(vcpu,
 				    map.direct_vtimer->host_timer_irq,
 				    map.direct_vtimer->irq.irq,
-				    kvm_arch_timer_get_input_level);
+				    &arch_timer_irq_ops);
 	if (ret)
 		return ret;
 

@@ -1151,7 +1155,7 @@ int kvm_timer_enable(struct kvm_vcpu *vcpu)
 		ret = kvm_vgic_map_phys_irq(vcpu,
 					    map.direct_ptimer->host_timer_irq,
 					    map.direct_ptimer->irq.irq,
-					    kvm_arch_timer_get_input_level);
+					    &arch_timer_irq_ops);
 	}
 
 	if (ret)

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

index 15b666200f0b..111bff47e471 100644
@@ -182,8 +182,8 @@ bool vgic_get_phys_line_level(struct vgic_irq *irq)
 
 	BUG_ON(!irq->hw);
 
-	if (irq->get_input_level)
-		return irq->get_input_level(irq->intid);
+	if (irq->ops && irq->ops->get_input_level)
+		return irq->ops->get_input_level(irq->intid);
 
 	WARN_ON(irq_get_irqchip_state(irq->host_irq,
 				      IRQCHIP_STATE_PENDING,

@@ -480,7 +480,7 @@ int kvm_vgic_inject_irq(struct kvm *kvm, int cpuid, unsigned int intid,
 /* @irq->irq_lock must be held */
 static int kvm_vgic_map_irq(struct kvm_vcpu *vcpu, struct vgic_irq *irq,
 			    unsigned int host_irq,
-			    bool (*get_input_level)(int vindid))
+			    struct irq_ops *ops)
 {
 	struct irq_desc *desc;
 	struct irq_data *data;

@@ -500,7 +500,7 @@ static int kvm_vgic_map_irq(struct kvm_vcpu *vcpu, struct vgic_irq *irq,
 	irq->hw = true;
 	irq->host_irq = host_irq;
 	irq->hwintid = data->hwirq;
-	irq->get_input_level = get_input_level;
+	irq->ops = ops;
 	return 0;
 }
 

@@ -509,11 +509,11 @@ static inline void kvm_vgic_unmap_irq(struct vgic_irq *irq)
 {
 	irq->hw = false;
 	irq->hwintid = 0;
-	irq->get_input_level = NULL;
+	irq->ops = NULL;
 }
 
 int kvm_vgic_map_phys_irq(struct kvm_vcpu *vcpu, unsigned int host_irq,
-			  u32 vintid, bool (*get_input_level)(int vindid))
+			  u32 vintid, struct irq_ops *ops)
 {
 	struct vgic_irq *irq = vgic_get_irq(vcpu->kvm, vcpu, vintid);
 	unsigned long flags;

@@ -522,7 +522,7 @@ int kvm_vgic_map_phys_irq(struct kvm_vcpu *vcpu, unsigned int host_irq,
 	BUG_ON(!irq);
 
 	raw_spin_lock_irqsave(&irq->irq_lock, flags);
-	ret = kvm_vgic_map_irq(vcpu, irq, host_irq, get_input_level);
+	ret = kvm_vgic_map_irq(vcpu, irq, host_irq, ops);
 	raw_spin_unlock_irqrestore(&irq->irq_lock, flags);
 	vgic_put_irq(vcpu->kvm, irq);
 

include/kvm/arm_vgic.h +17 -11

index e45b26e8d479..e5f06df000f2 100644
@@ -92,6 +92,21 @@ enum vgic_irq_config {
 	VGIC_CONFIG_LEVEL
 };
 
+/*
+ * Per-irq ops overriding some common behavious.
+ *
+ * Always called in non-preemptible section and the functions can use
+ * kvm_arm_get_running_vcpu() to get the vcpu pointer for private IRQs.
+ */
+struct irq_ops {
+	/*
+	 * Callback function pointer to in-kernel devices that can tell us the
+	 * state of the input level of mapped level-triggered IRQ faster than
+	 * peaking into the physical GIC.
+	 */
+	bool (*get_input_level)(int vintid);
+};
+
 struct vgic_irq {
 	raw_spinlock_t irq_lock;	/* Protects the content of the struct */
 	struct list_head lpi_list;	/* Used to link all LPIs together */

@@ -129,16 +144,7 @@ struct vgic_irq {
 	u8 group;			/* 0 == group 0, 1 == group 1 */
 	enum vgic_irq_config config;	/* Level or edge */
 
-	/*
-	 * Callback function pointer to in-kernel devices that can tell us the
-	 * state of the input level of mapped level-triggered IRQ faster than
-	 * peaking into the physical GIC.
-	 *
-	 * Always called in non-preemptible section and the functions can use
-	 * kvm_arm_get_running_vcpu() to get the vcpu pointer for private
-	 * IRQs.
-	 */
-	bool (*get_input_level)(int vintid);
+	struct irq_ops *ops;
 
 	void *owner;			/* Opaque pointer to reserve an interrupt
 					   for in-kernel devices. */

@@ -355,7 +361,7 @@ void kvm_vgic_init_cpu_hardware(void);
 int kvm_vgic_inject_irq(struct kvm *kvm, int cpuid, unsigned int intid,
 			bool level, void *owner);
 int kvm_vgic_map_phys_irq(struct kvm_vcpu *vcpu, unsigned int host_irq,
-			  u32 vintid, bool (*get_input_level)(int vindid));
+			  u32 vintid, struct irq_ops *ops);
 int kvm_vgic_unmap_phys_irq(struct kvm_vcpu *vcpu, unsigned int vintid);
 bool kvm_vgic_map_is_active(struct kvm_vcpu *vcpu, unsigned int vintid);
 

Hi Marc,

Quoted 4 lines · Marc Zyngier

We already have the option to attach a callback to an interrupt to retrieve its pending state. As we are planning to expand this facility, move this callback into its own data structure.

Quoted 2 lines

This will limit the size of individual interrupts as the ops structures can be shared across multiple interrupts.

I can't figure out what you mean by that. If you are referring to struct vgic_irq, the change I am seeing is a pointer being replaced by another pointer, which shouldn't affect its size. Are you referring to something else?

Quoted 17 lines

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

---
 arch/arm64/kvm/arch_timer.c |  8 ++++++--
 arch/arm64/kvm/vgic/vgic.c  | 14 +++++++-------
 include/kvm/arm_vgic.h      | 28 +++++++++++++++++-----------
 3 files changed, 30 insertions(+), 20 deletions(-)

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

index 74e0699661e9..e2288b6bf435 100644
@@ -1116,6 +1116,10 @@ bool kvm_arch_timer_get_input_level(int vintid)
 	return kvm_timer_should_fire(timer);
 }
 

arch/arm64/kvm/arch_timer.c bool kvm_arch_timer_get_input_level(int vintid) · line 1120

Quoted 2 lines

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

+static struct irq_ops arch_timer_irq_ops = {
+	.get_input_level = kvm_arch_timer_get_input_level,

Since kvm_arch_timer_get_input_level() is used only indirectly, through the get_input_level field of the static struct, I think we can make kvm_arch_timer_get_input_level() static and remove the declaration from include/kvm/arm_arch_timer.h.

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 +3 -1

+				resample = true;
+			}
 
-			if (!irq->line_level)
+			if (resample)
 				vgic_irq_set_phys_active(irq, false);
 		}
 

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

 		val |= GICH_LR_HW;
 		val |= irq->hwintid << GICH_LR_PHYSID_CPUID_SHIFT;
 		/*

arch/arm64/kvm/vgic/vgic-v3.c +14 -3

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);
 		}
 

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

 		val |= ICH_LR_HW;
 		val |= ((u64)irq->hwintid) << ICH_LR_PHYS_ID_SHIFT;
 		/*

include/kvm/arm_vgic.h +5 -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. */

Hi Marc,

Quoted 2 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:

Nitpick, but shouldn't that be "let's"?

Quoted 30 lines

- 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 void vgic_v2_fold_lr_state(struct kvm_vcpu *vcpu) · line 122

Quoted 10 lines

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

-		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) {
+				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)) {

I'm having a hard time figuring out when and why a level sensitive can have pending_latch = true.

I looked kvm_vgic_inject_irq(), and that function sets pending_latch only for edge triggered interrupts (it sets line_level for level sensitive ones). But irq_is_pending() looks at **both** pending_latch and line_level for level sensitive interrupts.

The only place that I've found that sets pending_latch regardless of the interrupt type is in vgic_mmio_write_spending() (called on a
trapped write to GICD_ISENABLER).

vgic_v2_populate_lr() clears

pending_latch  only for  edge triggered  interrupts, so  that leaves
vgic_v2_fold_lr_state()  as  the   only  function  pending_latch  is
cleared for level sensitive interrupts,  when the interrupt has been

handled by the guest. Are we doing all of this to emulate the fact that level sensitive interrupts (either purely virtual or hw mapped) made pending by a write to GICD_ISENABLER remain pending until they are handled by the guest?

If that is the case, then I think this is what the code is doing:

- There's no functional change when the irqchip has HW deactivation

- For level sensitive, hw mapped interrupts made pending by a write to GICD_ISENABLER and not yet handled by the guest (pending_latch == true) we don't clear the pending state of the interrupt.

- For level sensitive, hw mapped interrupts we clear the pending state in the GIC and the device will assert the interrupt again if it's still pending at the device 1level. I have a question about this. Why don't we sample the interrupt state by calling vgic_get_phys_line_level()? Because that would be slower than the alternative that you are proposing here?

Quoted 6 lines · Alexandru Elisei

Hi Marc,

Quoted 2 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:

Nitpick, but shouldn't that be "let's"?

"Let it be...". ;-) Yup.

Quoted 41 lines

Quoted 28 lines

- 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 void vgic_v2_fold_lr_state(struct kvm_vcpu *vcpu) · line 122

Quoted 10 lines

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

-		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) {
+				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)) {

I'm having a hard time figuring out when and why a level sensitive can have pending_latch = true.

Quoted 4 lines

I looked kvm_vgic_inject_irq(), and that function sets pending_latch only for edge triggered interrupts (it sets line_level for level sensitive ones). But irq_is_pending() looks at **both** pending_latch and line_level for level sensitive interrupts.

Yes, and that's what an implementation requires.

Quoted 3 lines

The only place that I've found that sets pending_latch regardless of the interrupt type is in vgic_mmio_write_spending() (called on a
trapped write to GICD_ISENABLER).

Are you sure? It really should be GICD_ISPENDR. I'll assume that this is what you mean below.

Quoted 9 lines

vgic_v2_populate_lr() clears

pending_latch  only for  edge triggered  interrupts, so  that leaves
vgic_v2_fold_lr_state()  as  the   only  function  pending_latch  is
cleared for level sensitive interrupts,  when the interrupt has been

handled by the guest. Are we doing all of this to emulate the fact that level sensitive interrupts (either purely virtual or hw mapped) made pending by a write to GICD_ISENABLER remain pending until they are handled by the guest?

Yes, or cleared by a write to GICD_ICPENDR. You really need to think of the input into the GIC as some sort of OR gate combining both the line level and the PEND register. With a latch for edge interrupts.

Have a look at Figure 4-10 ("Logic of the pending status of a level-sensitive interrupt") in the GICv2 arch spec (ARM IHI 0048B.b) to see what I actually mean.

Quoted 8 lines

If that is the case, then I think this is what the code is doing:

- There's no functional change when the irqchip has HW deactivation

- For level sensitive, hw mapped interrupts made pending by a write to GICD_ISENABLER and not yet handled by the guest (pending_latch == true) we don't clear the pending state of the interrupt.

Quoted 6 lines

- For level sensitive, hw mapped interrupts we clear the pending state in the GIC and the device will assert the interrupt again if it's still pending at the device 1level. I have a question about this. Why don't we sample the interrupt state by calling vgic_get_phys_line_level()? Because that would be slower than the alternative that you are proposing here?

Yes. It is *much* faster to read the timer status register (for example) than going via an MMIO access to read the (re)distributor that will return the same value.

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 | 57 +++++++++++++++++++++----------------
 1 file changed, 33 insertions(+), 24 deletions(-)

arch/arm64/kvm/arch_timer.c +33 -17

index e2288b6bf435..3cd170388d88 100644
@@ -973,6 +973,35 @@ 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;
+	}
+}
+
+static int kvm_irq_init(struct arch_timer_kvm_info *info)
+{
+	if (info->virtual_irq <= 0) {
+		kvm_err("kvm_arch_timer: invalid virtual timer IRQ: %d\n",
+			info->virtual_irq);
+		return -ENODEV;
+	}
+
+	host_vtimer_irq = info->virtual_irq;
+	kvm_irq_fixup_flags(host_vtimer_irq, &host_vtimer_irq_flags);
+
+	if (info->physical_irq > 0) {
+		host_ptimer_irq = info->physical_irq;
+		kvm_irq_fixup_flags(host_ptimer_irq, &host_ptimer_irq_flags);
+	}
+
+	return 0;
+}
+
 int kvm_timer_hyp_init(bool has_gic)
 {
 	struct arch_timer_kvm_info *info;

@@ -986,22 +1015,11 @@ int kvm_timer_hyp_init(bool has_gic)
 		return -ENODEV;
 	}
 
-	/* First, do the virtual EL1 timer irq */
-
-	if (info->virtual_irq <= 0) {
-		kvm_err("kvm_arch_timer: invalid virtual timer IRQ: %d\n",
-			info->virtual_irq);
-		return -ENODEV;
-	}
-	host_vtimer_irq = info->virtual_irq;
+	err = kvm_irq_init(info);
+	if (err)
+		return err;
 
-	host_vtimer_irq_flags = irq_get_trigger_type(host_vtimer_irq);
-	if (host_vtimer_irq_flags != IRQF_TRIGGER_HIGH &&
-	    host_vtimer_irq_flags != IRQF_TRIGGER_LOW) {
-		kvm_err("Invalid trigger for vtimer IRQ%d, assuming level low\n",
-			host_vtimer_irq);
-		host_vtimer_irq_flags = IRQF_TRIGGER_LOW;
-	}
+	/* First, do the virtual EL1 timer irq */
 
 	err = request_percpu_irq(host_vtimer_irq, kvm_arch_timer_handler,
 				 "kvm guest vtimer", kvm_get_running_vcpus());

@@ -1027,15 +1045,6 @@ int kvm_timer_hyp_init(bool has_gic)
 	/* Now let's do the physical EL1 timer irq */
 
 	if (info->physical_irq > 0) {
-		host_ptimer_irq = info->physical_irq;
-		host_ptimer_irq_flags = irq_get_trigger_type(host_ptimer_irq);

This is a new version of the series previously posted at [3], 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.

Until someone shouts loudly now, I'll take this into 5.14 (and in -next from tomorrow).

- Rebased on 5.13-rc4 to match the kvmarm/next base
- Moved stuff from patch #7 to its logical spot in patch #8
- Changed the include/linux/irqchip/arm-vgic-info.h guard
- Collected RBs from Alex, with thanks

* From v2 [2]:
- 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]
[3] 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
masking
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            | 162 +++++++++++++++++++++----
 arch/arm64/kvm/hyp/hyp-entry.S         |   6 +-
 arch/arm64/kvm/vgic/vgic-init.c        |  36 +++++-
 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        |   9 ++
 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  |  45 +++++++
 14 files changed, 299 insertions(+), 104 deletions(-)
 create mode 100644 include/linux/irqchip/arm-vgic-info.h

Hi Marc,

Quoted 10 lines · Marc Zyngier

This is a new version of the series previously posted at [3], 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.

Until someone shouts loudly now, I'll take this into 5.14 (and in -next from tomorrow).

I am not familiar with irqdomains or with the irqchip infrastructure, so I can't really comment on patch #8.

I tried testing this with a GICv3 by modifying the driver to set no_hw_deactivation and no_maint_irq_mask:

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

index 340c51d87677..d0c6f808d7f4 100644
@@ -565,8 +565,10 @@ int kvm_vgic_hyp_init(void)
         if (ret)
                 return ret;

+       /*
        if (!has_mask)
                return 0;
+               */

        ret = request_percpu_irq(kvm_vgic_global_state.maint_irq, vgic_maintenance_handler,

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

index 453fc425eede..9ce4dee20655 100644
@@ -1850,6 +1850,12 @@ static void __init gic_of_setup_kvm_info(struct device_node
 *node)
         if (!ret)
                 gic_v3_kvm_info.vcpu = r;

+       gic_v3_kvm_info.no_hw_deactivation = true;

+       gic_v3_kvm_info.no_maint_irq_mask = true;

drivers/irqchip/irq-gic-v3.c +4 -0

+
+       vgic_set_kvm_info(&gic_v3_kvm_info);
+       return;
+

        gic_v3_kvm_info.has_v4 = gic_data.rdists.has_vlpis; gic_v3_kvm_info.has_v4_1 = gic_data.rdists.has_rvpeid; vgic_set_kvm_info(&gic_v3_kvm_info);

Kept the maintenance irq ID so the IRQ gets enabled at the Redistributor level. I don't know if I managed to break something with those changes, but when testing on the model and on a rockpro64 (with the patches cherry-picked on top of v5.13-rc7) I kept seeing rcu stalls. I assume I did something wrong.

Hi Alex,

Quoted 42 lines · Alexandru Elisei

Hi Marc,

Quoted 10 lines · Marc Zyngier

This is a new version of the series previously posted at [3], 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.

Until someone shouts loudly now, I'll take this into 5.14 (and in -next from tomorrow).

I am not familiar with irqdomains or with the irqchip infrastructure, so I can't really comment on patch #8.

I tried testing this with a GICv3 by modifying the driver to set no_hw_deactivation and no_maint_irq_mask:

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

index 340c51d87677..d0c6f808d7f4 100644
@@ -565,8 +565,10 @@ int kvm_vgic_hyp_init(void)
         if (ret)
                 return ret;

+       /*
        if (!has_mask)
                return 0;
+               */

        ret = request_percpu_irq(kvm_vgic_global_state.maint_irq, vgic_maintenance_handler,

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

index 453fc425eede..9ce4dee20655 100644
@@ -1850,6 +1850,12 @@ static void __init gic_of_setup_kvm_info(struct device_node
 *node)
         if (!ret)
                 gic_v3_kvm_info.vcpu = r;

Quoted 2 lines

+       gic_v3_kvm_info.no_hw_deactivation = true;

Blink...

Quoted 9 lines

+       gic_v3_kvm_info.no_maint_irq_mask = true;

drivers/irqchip/irq-gic-v3.c +4 -0

+
+       vgic_set_kvm_info(&gic_v3_kvm_info);
+       return;
+

        gic_v3_kvm_info.has_v4 = gic_data.rdists.has_vlpis; gic_v3_kvm_info.has_v4_1 = gic_data.rdists.has_rvpeid; vgic_set_kvm_info(&gic_v3_kvm_info);

Quoted 5 lines

Kept the maintenance irq ID so the IRQ gets enabled at the Redistributor level. I don't know if I managed to break something with those changes, but when testing on the model and on a rockpro64 (with the patches cherry-picked on top of v5.13-rc7) I kept seeing rcu stalls. I assume I did something wrong.

If you do that, the interrupts that are forwarded to the guest (timers) will never be deactivated, and will be left dangling after the first injection. This is bound to create havoc, as we will then use mask/unmask to control the timer delivery (remember that the Active state is just another form of auto-masking on top of the standard enable bit)

On the contrary, the AIC only has a single bit to control the timer (used as a mask), which is what the irqdomain stuff implements to mimic the active state.

Thanks,

	M.

Hi Marc,

Quoted 71 lines · Marc Zyngier

Hi Alex,

Quoted 42 lines · Alexandru Elisei

Hi Marc,

Quoted 10 lines · Marc Zyngier

This is a new version of the series previously posted at [3], 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.

Until someone shouts loudly now, I'll take this into 5.14 (and in -next from tomorrow).

I am not familiar with irqdomains or with the irqchip infrastructure, so I can't really comment on patch #8.

I tried testing this with a GICv3 by modifying the driver to set no_hw_deactivation and no_maint_irq_mask:

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

index 340c51d87677..d0c6f808d7f4 100644
@@ -565,8 +565,10 @@ int kvm_vgic_hyp_init(void)
         if (ret)
                 return ret;

+       /*
        if (!has_mask)
                return 0;
+               */

        ret = request_percpu_irq(kvm_vgic_global_state.maint_irq, vgic_maintenance_handler,

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

index 453fc425eede..9ce4dee20655 100644
@@ -1850,6 +1850,12 @@ static void __init gic_of_setup_kvm_info(struct device_node
 *node)
         if (!ret)
                 gic_v3_kvm_info.vcpu = r;

Quoted 2 lines

+       gic_v3_kvm_info.no_hw_deactivation = true;

Blink...

Quoted 9 lines

+       gic_v3_kvm_info.no_maint_irq_mask = true;

drivers/irqchip/irq-gic-v3.c +4 -0

+
+       vgic_set_kvm_info(&gic_v3_kvm_info);
+       return;
+

        gic_v3_kvm_info.has_v4 = gic_data.rdists.has_vlpis; gic_v3_kvm_info.has_v4_1 = gic_data.rdists.has_rvpeid; vgic_set_kvm_info(&gic_v3_kvm_info);

Quoted 5 lines

Kept the maintenance irq ID so the IRQ gets enabled at the Redistributor level. I don't know if I managed to break something with those changes, but when testing on the model and on a rockpro64 (with the patches cherry-picked on top of v5.13-rc7) I kept seeing rcu stalls. I assume I did something wrong.

If you do that, the interrupts that are forwarded to the guest (timers) will never be deactivated, and will be left dangling after the first injection. This is bound to create havoc, as we will then use mask/unmask to control the timer delivery (remember that the Active state is just another form of auto-masking on top of the standard enable bit)

Quoted 3 lines

On the contrary, the AIC only has a single bit to control the timer (used as a mask), which is what the irqdomain stuff implements to mimic the active state.

So these patches work **only** with the AIC, not with a standard GICv3 without the HW bit in the LR registers and with an unmaskable maintenance IRQ? Because from the commit message from #8 I got the impression that the purpose of the change is to make timers work on a standard GICv3, sans those required architectural features.

Quoted 77 lines · Alexandru Elisei

Hi Marc,

Quoted 74 lines · Marc Zyngier

Hi Alex,

Quoted 42 lines · Alexandru Elisei

Hi Marc,

Quoted 10 lines · Marc Zyngier

This is a new version of the series previously posted at [3], 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.

Until someone shouts loudly now, I'll take this into 5.14 (and in -next from tomorrow).

I am not familiar with irqdomains or with the irqchip infrastructure, so I can't really comment on patch #8.

I tried testing this with a GICv3 by modifying the driver to set no_hw_deactivation and no_maint_irq_mask:

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

index 340c51d87677..d0c6f808d7f4 100644
@@ -565,8 +565,10 @@ int kvm_vgic_hyp_init(void)
         if (ret)
                 return ret;

+       /*
        if (!has_mask)
                return 0;
+               */

        ret = request_percpu_irq(kvm_vgic_global_state.maint_irq, vgic_maintenance_handler,

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

index 453fc425eede..9ce4dee20655 100644
@@ -1850,6 +1850,12 @@ static void __init gic_of_setup_kvm_info(struct device_node
 *node)
         if (!ret)
                 gic_v3_kvm_info.vcpu = r;

Quoted 2 lines

+       gic_v3_kvm_info.no_hw_deactivation = true;

Blink...

Quoted 9 lines

+       gic_v3_kvm_info.no_maint_irq_mask = true;

drivers/irqchip/irq-gic-v3.c +4 -0

+
+       vgic_set_kvm_info(&gic_v3_kvm_info);
+       return;
+

        gic_v3_kvm_info.has_v4 = gic_data.rdists.has_vlpis; gic_v3_kvm_info.has_v4_1 = gic_data.rdists.has_rvpeid; vgic_set_kvm_info(&gic_v3_kvm_info);

Quoted 5 lines

Kept the maintenance irq ID so the IRQ gets enabled at the Redistributor level. I don't know if I managed to break something with those changes, but when testing on the model and on a rockpro64 (with the patches cherry-picked on top of v5.13-rc7) I kept seeing rcu stalls. I assume I did something wrong.

If you do that, the interrupts that are forwarded to the guest (timers) will never be deactivated, and will be left dangling after the first injection. This is bound to create havoc, as we will then use mask/unmask to control the timer delivery (remember that the Active state is just another form of auto-masking on top of the standard enable bit)

On the contrary, the AIC only has a single bit to control the timer (used as a mask), which is what the irqdomain stuff implements to mimic the active state.

Quoted 5 lines

So these patches work **only** with the AIC, not with a standard GICv3 without the HW bit in the LR registers and with an unmaskable maintenance IRQ? Because from the commit message from #8 I got the impression that the purpose of the change is to make timers work on a standard GICv3, sans those required architectural features.

I don't understand what you mean.

The HW bit in the LR and deactivation *are* required, non-negotiable parts of the GICv3 architecture. Apple did not implement it is a consequence of the AIC not having an active state that the guest can manipulate independently of the host.

Either you have both HW bit and active state, and both work together (normal GICv3), or you have none of that and we rely on the maintenance interrupt to exit and fix the mess (Apple crap). You cannot have an intermediate state between the two.

Thanks,

	M.