linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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] KVM: arm/arm64: GICv4: Do not perform an map to a mapped vLPI
Date: Fri, 17 Nov 2023 11:47:40 +0000	[thread overview]
Message-ID: <86y1ewzjmr.wl-maz@kernel.org> (raw)
In-Reply-To: <967d81f7-74ae-da34-33b1-00e0b5cd1f22@huawei.com>

On Fri, 17 Nov 2023 09:54:37 +0000,
Kunkun Jiang <jiangkunkun@huawei.com> wrote:
> 
> Hi Marc,
> 
> On 2023/11/16 22:10, Marc Zyngier wrote:
> > On Thu, 16 Nov 2023 12:52:15 +0000,
> > Kunkun Jiang <jiangkunkun@huawei.com> wrote:
> >> Before performing an unmap, let's check whether the vLPI has been
> s/unmap/map
> >> mapped. This corresponds to checking whether a vLPI is valid before
> >> unmap it.
> >> 
> >> 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..824f4baf50ee 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 = -EBUSY;
> >> +		goto out;
> >> +	}
> >> +
> > So this code affects the mapping side, not the unmapping. Even more
> > confusingly, the subject of the patch doesn't match the commit
> > message.
> > 
> > Furthermore, I'm not sure we want to return an error here. Userspace
> > has no knowledge of GICv4, and there are numerous other cases where we
> > don't return any error. This is certainly a userspace visible change.
> Yes, Userspace has no knowledge of GICv4. In the current implementation,
> this error will not be presented to userspace. Only a log will be printed
> in kvm_irqfd_assign().
> > #ifdef CONFIG_HAVE_KVM_IRQ_BYPASS
> >         if (kvm_arch_has_irq_bypass()) {
> >                 irqfd->consumer.token = (void *)irqfd->eventfd;
> >                 irqfd->consumer.add_producer =
> kvm_arch_irq_bypass_add_producer;
> >                 irqfd->consumer.del_producer =
> kvm_arch_irq_bypass_del_producer;
> >                 irqfd->consumer.stop = kvm_arch_irq_bypass_stop;
> >                 irqfd->consumer.start = kvm_arch_irq_bypass_start;
> >                 ret = irq_bypass_register_consumer(&irqfd->consumer);
> >                 if (ret)
> >                         pr_info("irq bypass consumer (token %p)
> registration fails: %d\n",
> >                                 irqfd->consumer.token, ret);
> >         }
> > #endif
> 
> If you think it is better not to return an error, I will modify it in
> the next version.

I don't think returning an error is worth it, given that it is not
actionable from userspace. The pr_info() itself is ugly and should
probably be at least ratelimited, but that's for another patch.

Please resend this with a 0 return value, a fixed commit message, and
a Fixes: tag.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

      reply	other threads:[~2023-11-17 11:48 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-16 12:52 [PATCH] KVM: arm/arm64: GICv4: Do not perform an map to a mapped vLPI Kunkun Jiang
2023-11-16 14:10 ` Marc Zyngier
2023-11-17  9:54   ` Kunkun Jiang
2023-11-17 11:47     ` Marc Zyngier [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=86y1ewzjmr.wl-maz@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 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).