On Thu, 17 Jun 2021 15:58:31 +0100,
Alexandru Elisei <alexandru.elisei@xxxxxxx> wrote:
>
> Hi Marc,
>
> On 6/1/21 11:40 AM, 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:
>
> Nitpick, but shouldn't that be "let's"?
"Let it be...". ;-) Yup.
>
> >
> > - 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@xxxxxxxxxx>
> > ---
> > 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)) {
>
> 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.
Yes, and that's what an implementation requires.
> 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.
> 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.
> 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?
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.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
