[PATCH v3 6/9] KVM: arm64: vgic: Implement SW-driven deactivation

[Marc Zyngier]

On Mon, 24 May 2021 17:53:04 +0100,
Alexandru Elisei <alexandru.elisei at arm.com> wrote:
> 
> Hi Marc,
> 
> Some questions regarding how this is supposed to work.
> 
> On 5/10/21 2:48 PM, Marc Zyngier wrote:
> > 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 <maz at kernel.org>
> > ---
> >  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(-)
> >
> > diff --git a/arch/arm64/kvm/vgic/vgic-v2.c b/arch/arm64/kvm/vgic/vgic-v2.c
> > index 11934c2af2f4..2c580204f1dc 100644
> > --- a/arch/arm64/kvm/vgic/vgic-v2.c
> > +++ b/arch/arm64/kvm/vgic/vgic-v2.c
> > @@ -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) {
> > +				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.

Correct.

> 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?

See the vgic_get_phys_line_level() call. This is all about dealing
with an interrupt that was made pending in the LR, that the guest
didn't Ack, but instead decided to disable the timer.

In this case, we need to clear the pending bit and deactivate the
interrupt because nothing will perform the physical deactivation for
us.

What we add in the M1 case is that if the interrupt isn't pending
anymore at the virtual level, we also need to deactivate it at the
physical level, because there is no HW mechanism to enforce it.

> 
> > +				resample = true;
> > +			}
> >  
> > -			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?

The resample is at the HW level. We forcefully tell the interrupt
controller to deliver a pending interrupt (this is implemented as an
unmask under the hood).

	M.

-- 
Without deviation from the norm, progress is not possible.