From: Shenming Lu <lushenming@huawei.com>
To: Marc Zyngier <maz@kernel.org>, James Morse <james.morse@arm.com>,
"Julien Thierry" <julien.thierry.kdev@gmail.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Eric Auger <eric.auger@redhat.com>,
<linux-arm-kernel@lists.infradead.org>,
<kvmarm@lists.cs.columbia.edu>, <kvm@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
Christoffer Dall <christoffer.dall@arm.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
Kirti Wankhede <kwankhede@nvidia.com>,
Cornelia Huck <cohuck@redhat.com>, Neo Jia <cjia@nvidia.com>,
<wanghaibin.wang@huawei.com>, <yuzenghui@huawei.com>,
<lushenming@huawei.com>
Subject: [RFC PATCH v1 4/4] KVM: arm64: GICv4.1: Give a chance to save VLPI's pending state
Date: Mon, 23 Nov 2020 14:54:10 +0800 [thread overview]
Message-ID: <20201123065410.1915-5-lushenming@huawei.com> (raw)
In-Reply-To: <20201123065410.1915-1-lushenming@huawei.com>
Before GICv4.1, we do not have direct access to the VLPI's pending
state. So we simply let it fail early when encountering any VLPI.
But now we don't have to return -EACCES directly if on GICv4.1. So
let’s change the hard code and give a chance to save the VLPI's pending
state (and preserve the interfaces).
Signed-off-by: Shenming Lu <lushenming@huawei.com>
---
Documentation/virt/kvm/devices/arm-vgic-its.rst | 2 +-
arch/arm64/kvm/vgic/vgic-its.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/virt/kvm/devices/arm-vgic-its.rst b/Documentation/virt/kvm/devices/arm-vgic-its.rst
index 6c304fd2b1b4..d257eddbae29 100644
--- a/Documentation/virt/kvm/devices/arm-vgic-its.rst
+++ b/Documentation/virt/kvm/devices/arm-vgic-its.rst
@@ -80,7 +80,7 @@ KVM_DEV_ARM_VGIC_GRP_CTRL
-EFAULT Invalid guest ram access
-EBUSY One or more VCPUS are running
-EACCES The virtual ITS is backed by a physical GICv4 ITS, and the
- state is not available
+ state is not available without GICv4.1
======= ==========================================================
KVM_DEV_ARM_VGIC_GRP_ITS_REGS
diff --git a/arch/arm64/kvm/vgic/vgic-its.c b/arch/arm64/kvm/vgic/vgic-its.c
index 40cbaca81333..ec7543a9617c 100644
--- a/arch/arm64/kvm/vgic/vgic-its.c
+++ b/arch/arm64/kvm/vgic/vgic-its.c
@@ -2218,10 +2218,10 @@ static int vgic_its_save_itt(struct vgic_its *its, struct its_device *device)
/*
* If an LPI carries the HW bit, this means that this
* interrupt is controlled by GICv4, and we do not
- * have direct access to that state. Let's simply fail
- * the save operation...
+ * have direct access to that state without GICv4.1.
+ * Let's simply fail the save operation...
*/
- if (ite->irq->hw)
+ if (ite->irq->hw && !kvm_vgic_global_state.has_gicv4_1)
return -EACCES;
ret = vgic_its_save_ite(its, device, ite, gpa, ite_esz);
--
2.23.0
prev parent reply other threads:[~2020-11-23 6:55 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-23 6:54 [RFC PATCH v1 0/4] KVM: arm64: Add VLPI migration support on GICv4.1 Shenming Lu
2020-11-23 6:54 ` [RFC PATCH v1 1/4] irqchip/gic-v4.1: Plumb get_irqchip_state VLPI callback Shenming Lu
2020-11-23 9:01 ` Marc Zyngier
2020-11-24 7:38 ` Shenming Lu
2020-11-24 8:08 ` Marc Zyngier
2020-11-28 7:19 ` luojiaxing
2020-11-28 10:18 ` Marc Zyngier
2020-12-01 9:38 ` luojiaxing
2020-12-01 10:58 ` Marc Zyngier
2020-11-23 6:54 ` [RFC PATCH v1 2/4] KVM: arm64: GICv4.1: Try to save hw pending state in save_pending_tables Shenming Lu
2020-11-23 9:18 ` Marc Zyngier
2020-11-24 7:40 ` Shenming Lu
2020-11-24 8:26 ` Marc Zyngier
2020-11-24 13:10 ` Shenming Lu
2020-11-23 6:54 ` [RFC PATCH v1 3/4] KVM: arm64: GICv4.1: Restore VLPI's pending state to physical side Shenming Lu
2020-11-23 9:27 ` Marc Zyngier
2020-11-24 8:10 ` Shenming Lu
2020-11-24 8:44 ` Marc Zyngier
2020-11-24 13:12 ` Shenming Lu
2020-11-30 7:23 ` Shenming Lu
2020-12-01 10:55 ` Marc Zyngier
2020-12-01 11:40 ` Shenming Lu
2020-12-01 11:50 ` Marc Zyngier
2020-12-01 12:15 ` Shenming Lu
2020-12-08 8:25 ` Shenming Lu
2020-12-16 10:35 ` Auger Eric
2020-12-17 4:19 ` Shenming Lu
2020-11-23 6:54 ` Shenming Lu [this message]
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=20201123065410.1915-5-lushenming@huawei.com \
--to=lushenming@huawei.com \
--cc=alex.williamson@redhat.com \
--cc=christoffer.dall@arm.com \
--cc=cjia@nvidia.com \
--cc=cohuck@redhat.com \
--cc=eric.auger@redhat.com \
--cc=james.morse@arm.com \
--cc=julien.thierry.kdev@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=kwankhede@nvidia.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=suzuki.poulose@arm.com \
--cc=wanghaibin.wang@huawei.com \
--cc=yuzenghui@huawei.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).