From: Ricardo Koller <ricarkol@google.com>
To: Marc Zyngier <maz@kernel.org>
Cc: kvm@vger.kernel.org, kernel-team@android.com,
kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] KVM: arm64: vgic: Read HW interrupt pending state from the HW
Date: Tue, 8 Feb 2022 09:29:39 -0800 [thread overview]
Message-ID: <YgKogzsdCi9K4drb@google.com> (raw)
In-Reply-To: <20220208123726.3604198-1-maz@kernel.org>
On Tue, Feb 08, 2022 at 12:37:26PM +0000, Marc Zyngier wrote:
> It appears that a read access to GIC[DR]_I[CS]PENDRn doesn't always
> result in the pending interrupts being accurately reported if they are
> mapped to a HW interrupt. This is particularily visible when acking
> the timer interrupt and reading the GICR_ISPENDR1 register immediately
> after, for example (the interrupt appears as not-pending while it really
> is...).
>
> This is because a HW interrupt has its 'active and pending state' kept
> in the *physical* distributor, and not in the virtual one, as mandated
> by the spec (this is what allows the direct deactivation). The virtual
> distributor only caries the pending and active *states* (note the
> plural, as these are two independent and non-overlapping states).
>
> Fix it by reading the HW state back, either from the timer itself or
> from the distributor if necessary.
>
> Reported-by: Ricardo Koller <ricarkol@google.com>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> arch/arm64/kvm/vgic/vgic-mmio.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/kvm/vgic/vgic-mmio.c b/arch/arm64/kvm/vgic/vgic-mmio.c
> index 7068da080799..49837d3a3ef5 100644
> --- a/arch/arm64/kvm/vgic/vgic-mmio.c
> +++ b/arch/arm64/kvm/vgic/vgic-mmio.c
> @@ -248,6 +248,8 @@ unsigned long vgic_mmio_read_pending(struct kvm_vcpu *vcpu,
> IRQCHIP_STATE_PENDING,
> &val);
> WARN_RATELIMIT(err, "IRQ %d", irq->host_irq);
> + } else if (vgic_irq_is_mapped_level(irq)) {
> + val = vgic_get_phys_line_level(irq);
> } else {
> val = irq_is_pending(irq);
> }
> --
> 2.34.1
>
Thanks Marc!
Tested this fix with a selftest that we are planning to upstream soon.
It fires and handles arch timer IRQs while checking the pending state
along the way.
Tested-by: Ricardo Koller <ricarkol@google.com>
Reviewed-by: Ricardo Koller <ricarkol@google.com>
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
WARNING: multiple messages have this Message-ID (diff)
From: Ricardo Koller <ricarkol@google.com>
To: Marc Zyngier <maz@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org,
James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Alexandru Elisei <alexandru.elisei@arm.com>,
kernel-team@android.com
Subject: Re: [PATCH] KVM: arm64: vgic: Read HW interrupt pending state from the HW
Date: Tue, 8 Feb 2022 09:29:39 -0800 [thread overview]
Message-ID: <YgKogzsdCi9K4drb@google.com> (raw)
In-Reply-To: <20220208123726.3604198-1-maz@kernel.org>
On Tue, Feb 08, 2022 at 12:37:26PM +0000, Marc Zyngier wrote:
> It appears that a read access to GIC[DR]_I[CS]PENDRn doesn't always
> result in the pending interrupts being accurately reported if they are
> mapped to a HW interrupt. This is particularily visible when acking
> the timer interrupt and reading the GICR_ISPENDR1 register immediately
> after, for example (the interrupt appears as not-pending while it really
> is...).
>
> This is because a HW interrupt has its 'active and pending state' kept
> in the *physical* distributor, and not in the virtual one, as mandated
> by the spec (this is what allows the direct deactivation). The virtual
> distributor only caries the pending and active *states* (note the
> plural, as these are two independent and non-overlapping states).
>
> Fix it by reading the HW state back, either from the timer itself or
> from the distributor if necessary.
>
> Reported-by: Ricardo Koller <ricarkol@google.com>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> arch/arm64/kvm/vgic/vgic-mmio.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/kvm/vgic/vgic-mmio.c b/arch/arm64/kvm/vgic/vgic-mmio.c
> index 7068da080799..49837d3a3ef5 100644
> --- a/arch/arm64/kvm/vgic/vgic-mmio.c
> +++ b/arch/arm64/kvm/vgic/vgic-mmio.c
> @@ -248,6 +248,8 @@ unsigned long vgic_mmio_read_pending(struct kvm_vcpu *vcpu,
> IRQCHIP_STATE_PENDING,
> &val);
> WARN_RATELIMIT(err, "IRQ %d", irq->host_irq);
> + } else if (vgic_irq_is_mapped_level(irq)) {
> + val = vgic_get_phys_line_level(irq);
> } else {
> val = irq_is_pending(irq);
> }
> --
> 2.34.1
>
Thanks Marc!
Tested this fix with a selftest that we are planning to upstream soon.
It fires and handles arch timer IRQs while checking the pending state
along the way.
Tested-by: Ricardo Koller <ricarkol@google.com>
Reviewed-by: Ricardo Koller <ricarkol@google.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Ricardo Koller <ricarkol@google.com>
To: Marc Zyngier <maz@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org,
James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Alexandru Elisei <alexandru.elisei@arm.com>,
kernel-team@android.com
Subject: Re: [PATCH] KVM: arm64: vgic: Read HW interrupt pending state from the HW
Date: Tue, 8 Feb 2022 09:29:39 -0800 [thread overview]
Message-ID: <YgKogzsdCi9K4drb@google.com> (raw)
In-Reply-To: <20220208123726.3604198-1-maz@kernel.org>
On Tue, Feb 08, 2022 at 12:37:26PM +0000, Marc Zyngier wrote:
> It appears that a read access to GIC[DR]_I[CS]PENDRn doesn't always
> result in the pending interrupts being accurately reported if they are
> mapped to a HW interrupt. This is particularily visible when acking
> the timer interrupt and reading the GICR_ISPENDR1 register immediately
> after, for example (the interrupt appears as not-pending while it really
> is...).
>
> This is because a HW interrupt has its 'active and pending state' kept
> in the *physical* distributor, and not in the virtual one, as mandated
> by the spec (this is what allows the direct deactivation). The virtual
> distributor only caries the pending and active *states* (note the
> plural, as these are two independent and non-overlapping states).
>
> Fix it by reading the HW state back, either from the timer itself or
> from the distributor if necessary.
>
> Reported-by: Ricardo Koller <ricarkol@google.com>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> arch/arm64/kvm/vgic/vgic-mmio.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/kvm/vgic/vgic-mmio.c b/arch/arm64/kvm/vgic/vgic-mmio.c
> index 7068da080799..49837d3a3ef5 100644
> --- a/arch/arm64/kvm/vgic/vgic-mmio.c
> +++ b/arch/arm64/kvm/vgic/vgic-mmio.c
> @@ -248,6 +248,8 @@ unsigned long vgic_mmio_read_pending(struct kvm_vcpu *vcpu,
> IRQCHIP_STATE_PENDING,
> &val);
> WARN_RATELIMIT(err, "IRQ %d", irq->host_irq);
> + } else if (vgic_irq_is_mapped_level(irq)) {
> + val = vgic_get_phys_line_level(irq);
> } else {
> val = irq_is_pending(irq);
> }
> --
> 2.34.1
>
Thanks Marc!
Tested this fix with a selftest that we are planning to upstream soon.
It fires and handles arch timer IRQs while checking the pending state
along the way.
Tested-by: Ricardo Koller <ricarkol@google.com>
Reviewed-by: Ricardo Koller <ricarkol@google.com>
next prev parent reply other threads:[~2022-02-08 17:29 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-08 12:37 [PATCH] KVM: arm64: vgic: Read HW interrupt pending state from the HW Marc Zyngier
2022-02-08 12:37 ` Marc Zyngier
2022-02-08 12:37 ` Marc Zyngier
2022-02-08 17:29 ` Ricardo Koller [this message]
2022-02-08 17:29 ` Ricardo Koller
2022-02-08 17:29 ` Ricardo Koller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YgKogzsdCi9K4drb@google.com \
--to=ricarkol@google.com \
--cc=kernel-team@android.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maz@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.