From: Marc Zyngier <maz@kernel.org>
To: Kunkun Jiang <jiangkunkun@huawei.com>
Cc: Oliver Upton <oliver.upton@linux.dev>,
James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Jean-Philippe Brucker <jean-philippe@linaro.org>,
eric.auger@redhat.com, linux-arm-kernel@lists.infradead.org,
kvmarm@lists.linux.dev, wanghaibin.wang@huawei.com
Subject: Re: [PATCH v2] KVM: arm/arm64: GICv4: Do not perform a map to a mapped vLPI
Date: Mon, 20 Nov 2023 09:15:48 +0000 [thread overview]
Message-ID: <8a84365107c856e266b206e6e2374ec3@kernel.org> (raw)
In-Reply-To: <20231119104941.1952-1-jiangkunkun@huawei.com>
On 2023-11-19 10:49, Kunkun Jiang wrote:
> Before performing a map, let's check whether the vLPI has been
> mapped. This corresponds to checking whether a vLPI is valid
> before unmap it.
I don't understand this last sentence. Mapping and unmapping
are two different actions, and we shouldn't conflate them.
>
> Fixes: 196b136498b3 ("KVM: arm/arm64: GICv4: Wire mapping/unmapping of
> VLPIs in VFIO irq bypass")
> Signed-off-by: Kunkun Jiang <jiangkunkun@huawei.com>
> ---
> arch/arm64/kvm/vgic/vgic-v4.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/kvm/vgic/vgic-v4.c
> b/arch/arm64/kvm/vgic/vgic-v4.c
> index 339a55194b2c..fb60bbb94460 100644
> --- a/arch/arm64/kvm/vgic/vgic-v4.c
> +++ b/arch/arm64/kvm/vgic/vgic-v4.c
> @@ -436,6 +436,11 @@ int kvm_vgic_v4_set_forwarding(struct kvm *kvm,
> int virq,
> if (ret)
> goto out;
>
> + if (irq->hw) {
> + ret = 0;
ret is obviously already 0.
> + goto out;
> + }
> +
> /*
> * Emit the mapping request. If it fails, the ITS probably
> * isn't v4 compatible, so let's silently bail out. Holding
Furthermore, this really deserves a comment. Something like:
/* Silently exit if the vLPI is already mapped */
With these changes:
Acked-by: Marc Zyngier <maz@kernel.org>
Oliver, can you please apply these changes and queue it as a fix
for 6.7?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Kunkun Jiang <jiangkunkun@huawei.com>
Cc: Oliver Upton <oliver.upton@linux.dev>,
James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Jean-Philippe Brucker <jean-philippe@linaro.org>,
eric.auger@redhat.com, linux-arm-kernel@lists.infradead.org,
kvmarm@lists.linux.dev, wanghaibin.wang@huawei.com
Subject: Re: [PATCH v2] KVM: arm/arm64: GICv4: Do not perform a map to a mapped vLPI
Date: Mon, 20 Nov 2023 09:15:48 +0000 [thread overview]
Message-ID: <8a84365107c856e266b206e6e2374ec3@kernel.org> (raw)
In-Reply-To: <20231119104941.1952-1-jiangkunkun@huawei.com>
On 2023-11-19 10:49, Kunkun Jiang wrote:
> Before performing a map, let's check whether the vLPI has been
> mapped. This corresponds to checking whether a vLPI is valid
> before unmap it.
I don't understand this last sentence. Mapping and unmapping
are two different actions, and we shouldn't conflate them.
>
> Fixes: 196b136498b3 ("KVM: arm/arm64: GICv4: Wire mapping/unmapping of
> VLPIs in VFIO irq bypass")
> Signed-off-by: Kunkun Jiang <jiangkunkun@huawei.com>
> ---
> arch/arm64/kvm/vgic/vgic-v4.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/kvm/vgic/vgic-v4.c
> b/arch/arm64/kvm/vgic/vgic-v4.c
> index 339a55194b2c..fb60bbb94460 100644
> --- a/arch/arm64/kvm/vgic/vgic-v4.c
> +++ b/arch/arm64/kvm/vgic/vgic-v4.c
> @@ -436,6 +436,11 @@ int kvm_vgic_v4_set_forwarding(struct kvm *kvm,
> int virq,
> if (ret)
> goto out;
>
> + if (irq->hw) {
> + ret = 0;
ret is obviously already 0.
> + goto out;
> + }
> +
> /*
> * Emit the mapping request. If it fails, the ITS probably
> * isn't v4 compatible, so let's silently bail out. Holding
Furthermore, this really deserves a comment. Something like:
/* Silently exit if the vLPI is already mapped */
With these changes:
Acked-by: Marc Zyngier <maz@kernel.org>
Oliver, can you please apply these changes and queue it as a fix
for 6.7?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-11-20 9:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-19 10:49 [PATCH v2] KVM: arm/arm64: GICv4: Do not perform a map to a mapped vLPI Kunkun Jiang
2023-11-19 10:49 ` Kunkun Jiang
2023-11-20 9:15 ` Marc Zyngier [this message]
2023-11-20 9:15 ` Marc Zyngier
2023-11-20 13:19 ` Kunkun Jiang
2023-11-20 13:19 ` Kunkun Jiang
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=8a84365107c856e266b206e6e2374ec3@kernel.org \
--to=maz@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=eric.auger@redhat.com \
--cc=james.morse@arm.com \
--cc=jean-philippe@linaro.org \
--cc=jiangkunkun@huawei.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=oliver.upton@linux.dev \
--cc=suzuki.poulose@arm.com \
--cc=wanghaibin.wang@huawei.com \
--cc=will@kernel.org \
--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 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.