[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1436813849.1391.380.camel@redhat.com>
Date: Mon, 13 Jul 2015 12:57:29 -0600
From: Alex Williamson <alex.williamson@...hat.com>
To: Feng Wu <feng.wu@...el.com>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
pbonzini@...hat.com, joro@...tes.org, eric.auger@...aro.org
Subject: Re: [v5 09/19] vfio: Register/unregister irq_bypass_producer
On Mon, 2015-07-13 at 17:47 +0800, Feng Wu wrote:
> This patch adds the registration/unregistration of an
> irq_bypass_producer for MSI/MSIx on vfio pci devices.
>
> Signed-off-by: Feng Wu <feng.wu@...el.com>
> ---
> drivers/vfio/pci/vfio_pci_intrs.c | 19 +++++++++++++++++++
> drivers/vfio/pci/vfio_pci_private.h | 2 ++
> 2 files changed, 21 insertions(+)
>
> diff --git a/drivers/vfio/pci/vfio_pci_intrs.c b/drivers/vfio/pci/vfio_pci_intrs.c
> index 1f577b4..4795606 100644
> --- a/drivers/vfio/pci/vfio_pci_intrs.c
> +++ b/drivers/vfio/pci/vfio_pci_intrs.c
> @@ -305,6 +305,16 @@ static int vfio_msi_enable(struct vfio_pci_device *vdev, int nvec, bool msix)
> return 0;
> }
>
> +void vfio_pci_add_consumer(struct irq_bypass_producer *prod,
> + struct irq_bypass_consumer *cons)
> +{
> +}
> +
> +void vfio_pci_del_consumer(struct irq_bypass_producer *prod,
> + struct irq_bypass_consumer *cons)
> +{
> +}
> +
Yes, as Eric says, these should be static
> static int vfio_msi_set_vector_signal(struct vfio_pci_device *vdev,
> int vector, int fd, bool msix)
> {
> @@ -319,6 +329,7 @@ static int vfio_msi_set_vector_signal(struct vfio_pci_device *vdev,
>
> if (vdev->ctx[vector].trigger) {
> free_irq(irq, vdev->ctx[vector].trigger);
> + irq_bypass_unregister_producer(&vdev->ctx[vector].producer);
> kfree(vdev->ctx[vector].name);
> eventfd_ctx_put(vdev->ctx[vector].trigger);
> vdev->ctx[vector].trigger = NULL;
> @@ -360,6 +371,14 @@ static int vfio_msi_set_vector_signal(struct vfio_pci_device *vdev,
> return ret;
> }
>
> + INIT_LIST_HEAD(&vdev->ctx[vector].producer.node);
nit, INIT_LIST_HEAD isn't really needed, irq-bypass-manager shouldn't
trust incoming data here anyway.
> + vdev->ctx[vector].producer.token = trigger;
> + vdev->ctx[vector].producer.irq = irq;
> + vdev->ctx[vector].producer.add_consumer = vfio_pci_add_consumer;
> + vdev->ctx[vector].producer.del_consumer = vfio_pci_del_consumer;
> + ret = irq_bypass_register_producer(&vdev->ctx[vector].producer);
> + WARN_ON(ret);
This is only an acceleration path, so a dev_dbg() or dev_info() is
probably more appropriate. Same for kvm side.
> +
> vdev->ctx[vector].trigger = trigger;
>
> return 0;
> diff --git a/drivers/vfio/pci/vfio_pci_private.h b/drivers/vfio/pci/vfio_pci_private.h
> index ae0e1b4..0e7394f 100644
> --- a/drivers/vfio/pci/vfio_pci_private.h
> +++ b/drivers/vfio/pci/vfio_pci_private.h
> @@ -13,6 +13,7 @@
>
> #include <linux/mutex.h>
> #include <linux/pci.h>
> +#include <linux/irqbypass.h>
>
> #ifndef VFIO_PCI_PRIVATE_H
> #define VFIO_PCI_PRIVATE_H
> @@ -29,6 +30,7 @@ struct vfio_pci_irq_ctx {
> struct virqfd *mask;
> char *name;
> bool masked;
> + struct irq_bypass_producer producer;
> };
>
> struct vfio_pci_device {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists