All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: Sasha Levin <sashal@kernel.org>, Marc Zyngier <maz@kernel.org>,
	rikard.falkeborn@gmail.com, catalin.marinas@arm.com,
	will@kernel.org, kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: [PATCH AUTOSEL 5.15 09/28] KVM: arm64: vgic: Read HW interrupt pending state from the HW
Date: Tue, 22 Feb 2022 21:29:10 -0500	[thread overview]
Message-ID: <20220223022929.241127-9-sashal@kernel.org> (raw)
In-Reply-To: <20220223022929.241127-1-sashal@kernel.org>

From: Marc Zyngier <maz@kernel.org>

[ Upstream commit 5bfa685e62e9ba93c303a9a8db646c7228b9b570 ]

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>
Tested-by: Ricardo Koller <ricarkol@google.com>
Reviewed-by: Ricardo Koller <ricarkol@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220208123726.3604198-1-maz@kernel.org
Signed-off-by: Sasha Levin <sashal@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 48c6067fc5ecb..f972992682746 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

_______________________________________________
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: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: Marc Zyngier <maz@kernel.org>,
	Ricardo Koller <ricarkol@google.com>,
	Sasha Levin <sashal@kernel.org>,
	catalin.marinas@arm.com, will@kernel.org, eric.auger@redhat.com,
	rikard.falkeborn@gmail.com, linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu
Subject: [PATCH AUTOSEL 5.15 09/28] KVM: arm64: vgic: Read HW interrupt pending state from the HW
Date: Tue, 22 Feb 2022 21:29:10 -0500	[thread overview]
Message-ID: <20220223022929.241127-9-sashal@kernel.org> (raw)
In-Reply-To: <20220223022929.241127-1-sashal@kernel.org>

From: Marc Zyngier <maz@kernel.org>

[ Upstream commit 5bfa685e62e9ba93c303a9a8db646c7228b9b570 ]

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>
Tested-by: Ricardo Koller <ricarkol@google.com>
Reviewed-by: Ricardo Koller <ricarkol@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220208123726.3604198-1-maz@kernel.org
Signed-off-by: Sasha Levin <sashal@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 48c6067fc5ecb..f972992682746 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


_______________________________________________
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: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: Marc Zyngier <maz@kernel.org>,
	Ricardo Koller <ricarkol@google.com>,
	Sasha Levin <sashal@kernel.org>,
	catalin.marinas@arm.com, will@kernel.org, eric.auger@redhat.com,
	rikard.falkeborn@gmail.com, linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu
Subject: [PATCH AUTOSEL 5.15 09/28] KVM: arm64: vgic: Read HW interrupt pending state from the HW
Date: Tue, 22 Feb 2022 21:29:10 -0500	[thread overview]
Message-ID: <20220223022929.241127-9-sashal@kernel.org> (raw)
In-Reply-To: <20220223022929.241127-1-sashal@kernel.org>

From: Marc Zyngier <maz@kernel.org>

[ Upstream commit 5bfa685e62e9ba93c303a9a8db646c7228b9b570 ]

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>
Tested-by: Ricardo Koller <ricarkol@google.com>
Reviewed-by: Ricardo Koller <ricarkol@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220208123726.3604198-1-maz@kernel.org
Signed-off-by: Sasha Levin <sashal@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 48c6067fc5ecb..f972992682746 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


  parent reply	other threads:[~2022-02-23  2:29 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-23  2:29 [PATCH AUTOSEL 5.15 01/28] mac80211_hwsim: report NOACK frames in tx_status Sasha Levin
2022-02-23  2:29 ` [PATCH AUTOSEL 5.15 02/28] mac80211_hwsim: initialize ieee80211_tx_info at hw_scan_work Sasha Levin
2022-02-23  2:29 ` [PATCH AUTOSEL 5.15 03/28] i2c: bcm2835: Avoid clock stretching timeouts Sasha Levin
2022-02-23  2:29   ` Sasha Levin
2022-02-23  2:29 ` [PATCH AUTOSEL 5.15 04/28] ASoC: rt5668: do not block workqueue if card is unbound Sasha Levin
2022-02-23  2:29   ` Sasha Levin
2022-02-23  2:29 ` [PATCH AUTOSEL 5.15 05/28] ASoC: rt5682: " Sasha Levin
2022-02-23  2:29   ` Sasha Levin
2022-02-23  2:29 ` [PATCH AUTOSEL 5.15 06/28] regulator: core: fix false positive in regulator_late_cleanup() Sasha Levin
2022-02-23  2:29 ` [PATCH AUTOSEL 5.15 07/28] Input: clear BTN_RIGHT/MIDDLE on buttonpads Sasha Levin
2022-02-23  2:29 ` [PATCH AUTOSEL 5.15 08/28] btrfs: get rid of warning on transaction commit when using flushoncommit Sasha Levin
2022-02-23  2:29 ` Sasha Levin [this message]
2022-02-23  2:29   ` [PATCH AUTOSEL 5.15 09/28] KVM: arm64: vgic: Read HW interrupt pending state from the HW Sasha Levin
2022-02-23  2:29   ` Sasha Levin
2022-02-23  2:29 ` [PATCH AUTOSEL 5.15 10/28] block: loop:use kstatfs.f_bsize of backing file to set discard granularity Sasha Levin
2022-02-23  2:29 ` [PATCH AUTOSEL 5.15 11/28] tipc: fix a bit overflow in tipc_crypto_key_rcv() Sasha Levin
2022-02-23  2:29 ` [PATCH AUTOSEL 5.15 12/28] cifs: do not use uninitialized data in the owner/group sid Sasha Levin
2022-02-23  2:29 ` [PATCH AUTOSEL 5.15 13/28] cifs: fix double free race when mount fails in cifs_get_root() Sasha Levin
2022-02-23  2:29 ` [PATCH AUTOSEL 5.15 14/28] USB: zaurus: support another broken Zaurus Sasha Levin
2022-02-23  2:29 ` [PATCH AUTOSEL 5.15 15/28] HID: amd_sfh: Handle amd_sfh work buffer in PM ops Sasha Levin
2022-02-23  2:29 ` [PATCH AUTOSEL 5.15 16/28] HID: amd_sfh: Add functionality to clear interrupts Sasha Levin
2022-02-23  2:29 ` [PATCH AUTOSEL 5.15 17/28] HID: amd_sfh: Add interrupt handler to process interrupts Sasha Levin
2022-02-23  2:29 ` [PATCH AUTOSEL 5.15 18/28] cifs: modefromsids must add an ACE for authenticated users Sasha Levin
2022-02-23  2:29 ` [PATCH AUTOSEL 5.15 19/28] selftests/seccomp: Fix seccomp failure by adding missing headers Sasha Levin
2022-02-23  2:29 ` [PATCH AUTOSEL 5.15 20/28] drm/amd/pm: correct UMD pstate clocks for Dimgrey Cavefish and Beige Goby Sasha Levin
2022-02-23  2:29   ` Sasha Levin
2022-02-23  2:29   ` Sasha Levin
2022-02-23  2:29 ` [PATCH AUTOSEL 5.15 21/28] selftests/ftrace: Do not trace do_softirq because of PREEMPT_RT Sasha Levin
2022-02-23  2:29 ` [PATCH AUTOSEL 5.15 22/28] dmaengine: shdma: Fix runtime PM imbalance on error Sasha Levin
2022-02-23  2:29 ` [PATCH AUTOSEL 5.15 23/28] i2c: cadence: allow COMPILE_TEST Sasha Levin
2022-02-23  2:29 ` [PATCH AUTOSEL 5.15 24/28] i2c: imx: " Sasha Levin
2022-02-23  2:29 ` [PATCH AUTOSEL 5.15 25/28] i2c: qup: " Sasha Levin
2022-02-23  2:29 ` [PATCH AUTOSEL 5.15 26/28] CDC-NCM: avoid overflow in sanity checking Sasha Levin
2022-02-23  2:29 ` [PATCH AUTOSEL 5.15 27/28] net: usb: cdc_mbim: avoid altsetting toggling for Telit FN990 Sasha Levin
2022-02-23  2:29 ` [PATCH AUTOSEL 5.15 28/28] block-map: add __GFP_ZERO flag for alloc_page in function bio_copy_kern Sasha Levin

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=20220223022929.241127-9-sashal@kernel.org \
    --to=sashal@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=rikard.falkeborn@gmail.com \
    --cc=stable@vger.kernel.org \
    --cc=will@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.