linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Auger Eric <eric.auger@redhat.com>
To: Marc Zyngier <marc.zyngier@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org
Cc: Christoffer Dall <christoffer.dall@linaro.org>,
	Shanker Donthineni <shankerd@codeaurora.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Shameerali Kolothum Thodi  <shameerali.kolothum.thodi@huawei.com>,
	Andre Przywara <Andre.Przywara@arm.com>
Subject: Re: [PATCH v5 10/26] KVM: arm/arm64: GICv4: Wire mapping/unmapping of VLPIs in VFIO irq bypass
Date: Tue, 7 Nov 2017 14:06:36 +0100	[thread overview]
Message-ID: <1b60525f-5bb3-d19b-78df-fdfa5f48dc30@redhat.com> (raw)
In-Reply-To: <20171027142855.21584-11-marc.zyngier@arm.com>

Hi Marc,

On 27/10/2017 16:28, Marc Zyngier wrote:
> Let's use the irq bypass mechanism introduced for platform device
> interrupts
nit: I would remove "introduced for platform device interrupts"
as this is not upstream yet. x86 posted interrupts also use it.

>
 and establish our LPI->VLPI mapping.
> 
> Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
>  include/kvm/arm_vgic.h      |   8 ++++
>  virt/kvm/arm/arm.c          |   6 ++-
>  virt/kvm/arm/vgic/vgic-v4.c | 108 ++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 120 insertions(+), 2 deletions(-)
> 
> diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
> index 7eeb6c2a2f9c..2f750c770bf2 100644
> --- a/include/kvm/arm_vgic.h
> +++ b/include/kvm/arm_vgic.h
> @@ -373,4 +373,12 @@ int kvm_vgic_setup_default_irq_routing(struct kvm *kvm);
>  
>  int kvm_vgic_set_owner(struct kvm_vcpu *vcpu, unsigned int intid, void *owner);
>  
> +struct kvm_kernel_irq_routing_entry;
> +
> +int kvm_vgic_v4_set_forwarding(struct kvm *kvm, int irq,
> +			       struct kvm_kernel_irq_routing_entry *irq_entry);
> +
> +int kvm_vgic_v4_unset_forwarding(struct kvm *kvm, int irq,
> +				 struct kvm_kernel_irq_routing_entry *irq_entry);
> +
>  #endif /* __KVM_ARM_VGIC_H */
> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
> index 5d5218ecd547..8388c1cc23f6 100644
> --- a/virt/kvm/arm/arm.c
> +++ b/virt/kvm/arm/arm.c
> @@ -1462,7 +1462,8 @@ int kvm_arch_irq_bypass_add_producer(struct irq_bypass_consumer *cons,
>  	struct kvm_kernel_irqfd *irqfd =
>  		container_of(cons, struct kvm_kernel_irqfd, consumer);
>  
> -	return 0;
> +	return kvm_vgic_v4_set_forwarding(irqfd->kvm, prod->irq,
> +					  &irqfd->irq_entry);
>  }
>  void kvm_arch_irq_bypass_del_producer(struct irq_bypass_consumer *cons,
>  				      struct irq_bypass_producer *prod)
> @@ -1470,7 +1471,8 @@ void kvm_arch_irq_bypass_del_producer(struct irq_bypass_consumer *cons,
>  	struct kvm_kernel_irqfd *irqfd =
>  		container_of(cons, struct kvm_kernel_irqfd, consumer);
>  
> -	return;
> +	kvm_vgic_v4_unset_forwarding(irqfd->kvm, prod->irq,
> +				     &irqfd->irq_entry);
>  }
>  
>  void kvm_arch_irq_bypass_stop(struct irq_bypass_consumer *cons)
> diff --git a/virt/kvm/arm/vgic/vgic-v4.c b/virt/kvm/arm/vgic/vgic-v4.c
> index c794f0cef09e..01a2889b7b7c 100644
> --- a/virt/kvm/arm/vgic/vgic-v4.c
> +++ b/virt/kvm/arm/vgic/vgic-v4.c
> @@ -18,6 +18,7 @@
>  #include <linux/interrupt.h>
>  #include <linux/irqdomain.h>
>  #include <linux/kvm_host.h>
> +#include <linux/irqchip/arm-gic-v3.h>
>  
>  #include "vgic.h"
>  
> @@ -81,3 +82,110 @@ void vgic_v4_teardown(struct kvm *kvm)
>  	its_vm->nr_vpes = 0;
>  	its_vm->vpes = NULL;
>  }
> +
> +static struct vgic_its *vgic_get_its(struct kvm *kvm,
> +				     struct kvm_kernel_irq_routing_entry *irq_entry)
> +{
> +	struct kvm_msi msi  = (struct kvm_msi) {
> +		.address_lo	= irq_entry->msi.address_lo,
> +		.address_hi	= irq_entry->msi.address_hi,
> +		.data		= irq_entry->msi.data,
> +		.flags		= irq_entry->msi.flags,
> +		.devid		= irq_entry->msi.devid,
> +	};
> +
> +	/*
> +	 * Get a reference on the LPI. If NULL, this is not a valid
> +	 * translation for any of our vITSs.
> +	 */
I don't understand the relevance of the above comment.
> +	return vgic_msi_to_its(kvm, &msi);
> +}
> +
> +int kvm_vgic_v4_set_forwarding(struct kvm *kvm, int virq,
@virq is the host linux irq. virq naming is a bit confusing to me.
> +			       struct kvm_kernel_irq_routing_entry *irq_entry)
> +{
> +	struct vgic_its *its;
> +	struct vgic_irq *irq;
> +	struct its_vlpi_map map;
> +	int ret;
> +
Don't you need to check that the linux irq (virq) is an LPI? You may
encounter some VFIO "producers" for irq that are not LPIs, typically if
we eventually upstream SPI forwarding.
> +	if (!vgic_supports_direct_msis(kvm))
> +		return 0;
> +
> +	/*
> +	 * Get the ITS, and escape early on error (not a valid
> +	 * doorbell for any of our vITSs).
> +	 */
> +	its = vgic_get_its(kvm, irq_entry);
> +	if (IS_ERR(its))
> +		return 0;
> +
> +	mutex_lock(&its->its_lock);
wouldn't it be safer to take the its_lock before the get_its()? and even
before the vgic_supports_direct_msis, in an unlikely case where the its
would disappear?
> +
> +	/* Perform then actual DevID/EventID -> LPI translation. */
> +	ret = vgic_its_resolve_lpi(kvm, its, irq_entry->msi.devid,
> +				   irq_entry->msi.data, &irq);
> +	if (ret)
> +		goto out;
> +
> +	/*
> +	 * Emit the mapping request. If it fails, the ITS probably
> +	 * isn't v4 compatible, so let's silently bail out. Holding
> +	 * the ITS lock should ensure that nothing can modify the
> +	 * target vcpu.
> +	 */
> +	map = (struct its_vlpi_map) {
> +		.vm		= &kvm->arch.vgic.its_vm,
> +		.vpe		= &irq->target_vcpu->arch.vgic_cpu.vgic_v3.its_vpe,
> +		.vintid		= irq->intid,
> +		.properties	= ((irq->priority & 0xfc) |
> +				   (irq->enabled ? LPI_PROP_ENABLED : 0) |
> +				   LPI_PROP_GROUP1),
there is an inconsistency between the comment in irqchip/arm-gic-v4.h
and this setting:

* @properties: Priority and enable bits (as written in the prop table)

Also maybe we could use LPI_PROP_PRIORITY macro instead of 0xfc?
> +		.db_enabled	= true,
> +	};
> +
> +	ret = its_map_vlpi(virq, &map);
Looking at its_map_lpi implementation, assuming irq_set_vcpu_affinity()
fails, will you get a change to turn  IRQ_DISABLE_LAZY again.
> +	if (ret)
> +		goto out;
> +
> +	irq->hw		= true;
> +	irq->host_irq	= virq;
Shouldn't we theoretically hold the irq lock here?
> +
> +out:
> +	mutex_unlock(&its->its_lock);
> +	return ret;
> +}
> +
> +int kvm_vgic_v4_unset_forwarding(struct kvm *kvm, int virq,
same
> +				 struct kvm_kernel_irq_routing_entry *irq_entry)
> +{
> +	struct vgic_its *its;
> +	struct vgic_irq *irq;
> +	int ret;
> +
> +	if (!vgic_supports_direct_msis(kvm))
> +		return 0;
> +
> +	/*
> +	 * Get the ITS, and escape early on error (not a valid
> +	 * doorbell for any of our vITSs).
> +	 */
> +	its = vgic_get_its(kvm, irq_entry);
> +	if (IS_ERR(its))
> +		return 0;
> +
> +	mutex_lock(&its->its_lock);
same?

Thanks

Eric
> +
> +	ret = vgic_its_resolve_lpi(kvm, its, irq_entry->msi.devid,
> +				   irq_entry->msi.data, &irq);
> +	if (ret)
> +		goto out;
> +
> +	WARN_ON(!(irq->hw && irq->host_irq == virq));
> +	irq->hw = false;
> +	ret = its_unmap_vlpi(virq);
> +
> +out:
> +	mutex_unlock(&its->its_lock);
> +	return ret;
> +}
> 

  reply	other threads:[~2017-11-07 13:06 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-27 14:28 [PATCH v5 00/26] KVM/ARM: Add support for GICv4 Marc Zyngier
2017-10-27 14:28 ` [PATCH v5 01/26] irqchip/gic-v3-its: Setup VLPI properties at map time Marc Zyngier
2017-10-30  6:46   ` Christoffer Dall
2017-10-27 14:28 ` [PATCH v5 02/26] KVM: arm/arm64: register irq bypass consumer on ARM/ARM64 Marc Zyngier
2017-10-30  6:47   ` Christoffer Dall
2017-10-27 14:28 ` [PATCH v5 03/26] KVM: arm/arm64: vgic: restructure kvm_vgic_(un)map_phys_irq Marc Zyngier
2017-10-27 14:28 ` [PATCH v5 04/26] KVM: arm: Select ARM_GIC_V3 and ARM_GIC_V3_ITS Marc Zyngier
2017-10-27 14:28 ` [PATCH v5 05/26] KVM: arm/arm64: vgic: Move kvm_vgic_destroy call around Marc Zyngier
2017-10-27 14:28 ` [PATCH v5 06/26] KVM: arm/arm64: vITS: Add MSI translation helpers Marc Zyngier
2017-11-07 20:34   ` Auger Eric
2017-10-27 14:28 ` [PATCH v5 07/26] KVM: arm/arm64: vITS: Add a helper to update the affinity of an LPI Marc Zyngier
2017-11-07 13:44   ` Auger Eric
2017-10-27 14:28 ` [PATCH v5 08/26] KVM: arm/arm64: GICv4: Add property field and per-VM predicate Marc Zyngier
2017-11-07 20:30   ` Auger Eric
2017-10-27 14:28 ` [PATCH v5 09/26] KVM: arm/arm64: GICv4: Add init/teardown of the per-VM vPE irq domain Marc Zyngier
2017-11-07 13:08   ` Auger Eric
2017-11-10  8:20     ` Christoffer Dall
2017-11-10  8:55       ` Marc Zyngier
2017-11-07 13:09   ` Auger Eric
2017-10-27 14:28 ` [PATCH v5 10/26] KVM: arm/arm64: GICv4: Wire mapping/unmapping of VLPIs in VFIO irq bypass Marc Zyngier
2017-11-07 13:06   ` Auger Eric [this message]
2017-11-07 14:42     ` Marc Zyngier
2017-11-07 15:59       ` Auger Eric
2017-11-08 11:30         ` Marc Zyngier
2017-11-10  8:28       ` Christoffer Dall
2017-11-10  9:05         ` Marc Zyngier
2017-11-10  9:41           ` Christoffer Dall
2017-10-27 14:28 ` [PATCH v5 11/26] KVM: arm/arm64: GICv4: Handle INT command applied to a VLPI Marc Zyngier
2017-11-07 20:15   ` Auger Eric
2017-11-08 11:40     ` Marc Zyngier
2017-11-08 14:14       ` Auger Eric
2017-10-27 14:28 ` [PATCH v5 12/26] KVM: arm/arm64: GICv4: Unmap VLPI when freeing an LPI Marc Zyngier
2017-11-07 20:28   ` Auger Eric
2017-11-08 11:52     ` Marc Zyngier
2017-11-08 14:14       ` Auger Eric
2017-10-27 14:28 ` [PATCH v5 13/26] KVM: arm/arm64: GICv4: Propagate affinity changes to the physical ITS Marc Zyngier
2017-11-07 21:01   ` Auger Eric
2017-11-08 12:05     ` Marc Zyngier
2017-10-27 14:28 ` [PATCH v5 14/26] KVM: arm/arm64: GICv4: Handle CLEAR applied to a VLPI Marc Zyngier
2017-11-07 21:04   ` Auger Eric
2017-10-27 14:28 ` [PATCH v5 15/26] KVM: arm/arm64: GICv4: Handle MOVALL applied to a vPE Marc Zyngier
2017-11-07 21:06   ` Auger Eric
2017-10-27 14:28 ` [PATCH v5 16/26] KVM: arm/arm64: GICv4: Propagate property updates to VLPIs Marc Zyngier
2017-11-07 21:28   ` Auger Eric
2017-11-08 15:08     ` Marc Zyngier
2017-11-10  8:37       ` Christoffer Dall
2017-11-10  8:58         ` Marc Zyngier
2017-10-27 14:28 ` [PATCH v5 17/26] KVM: arm/arm64: GICv4: Handle INVALL applied to a vPE Marc Zyngier
2017-11-07 21:23   ` Auger Eric
2017-11-10  8:41     ` Christoffer Dall
2017-11-10  8:56       ` Marc Zyngier
2017-10-27 14:28 ` [PATCH v5 18/26] KVM: arm/arm64: GICv4: Use pending_last as a scheduling hint Marc Zyngier
2017-11-07 21:38   ` Auger Eric
2017-10-27 14:28 ` [PATCH v5 19/26] KVM: arm/arm64: GICv4: Add doorbell interrupt handling Marc Zyngier
2017-11-07 21:43   ` Auger Eric
2017-10-27 14:28 ` [PATCH v5 20/26] KVM: arm/arm64: GICv4: Use the doorbell interrupt as an unblocking source Marc Zyngier
2017-11-07 21:45   ` Auger Eric
2017-10-27 14:28 ` [PATCH v5 21/26] KVM: arm/arm64: GICv4: Hook vPE scheduling into vgic flush/sync Marc Zyngier
2017-11-07 21:54   ` Auger Eric
2017-11-07 22:14     ` Auger Eric
2017-10-27 14:28 ` [PATCH v5 22/26] KVM: arm/arm64: GICv4: Enable virtual cpuif if VLPIs can be delivered Marc Zyngier
2017-11-08  8:46   ` Auger Eric
2017-10-27 14:28 ` [PATCH v5 23/26] KVM: arm/arm64: GICv4: Prevent a VM using GICv4 from being saved Marc Zyngier
2017-11-07 15:24   ` Auger Eric
2017-11-07 15:38     ` Marc Zyngier
2017-11-07 16:12       ` Auger Eric
2017-11-07 16:34         ` Marc Zyngier
2017-11-07 22:24           ` Auger Eric
2017-11-08  9:35             ` Auger Eric
2017-10-27 14:28 ` [PATCH v5 24/26] KVM: arm/arm64: GICv4: Prevent userspace from changing doorbell affinity Marc Zyngier
2017-10-30  6:51   ` Christoffer Dall
2017-11-07 22:17   ` Auger Eric
2017-10-27 14:28 ` [PATCH v5 25/26] KVM: arm/arm64: GICv4: Enable VLPI support Marc Zyngier
2017-11-08  8:44   ` Auger Eric
2017-11-08 15:14     ` Marc Zyngier
2017-10-27 14:28 ` [PATCH v5 26/26] KVM: arm/arm64: GICv4: Theory of operations Marc Zyngier
2017-11-08  9:13   ` Auger Eric
2017-11-08 15:19     ` Marc Zyngier

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=1b60525f-5bb3-d19b-78df-fdfa5f48dc30@redhat.com \
    --to=eric.auger@redhat.com \
    --cc=Andre.Przywara@arm.com \
    --cc=christoffer.dall@linaro.org \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=shankerd@codeaurora.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 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).