All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoffer Dall <christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
To: Antonios Motakis
	<a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
	Stuart Yoder
	<stuart.yoder-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
	KVM devel mailing list
	<kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Eric Auger <eric.auger-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>,
	Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>,
	Linux IOMMU
	<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
	alvise rigo
	<a.rigo-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>,
	Vladimir Murzin <vladimir.murzin-5wv7dgnIgG8@public.gmane.org>,
	VirtualOpenSystems Technical Team
	<tech-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>,
	kvm-arm
	<kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg@public.gmane.org>,
	open list <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [RFC PATCH v6 15/20] vfio/platform: support for maskable and automasked interrupts
Date: Wed, 10 Sep 2014 12:13:33 +0200	[thread overview]
Message-ID: <20140910101333.GA3002@lvm> (raw)
In-Reply-To: <CAG8rG2z02JPE+D-Bo1puuMPCR=wETciLaBgKT+i1XKQ55U-kYg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Tue, Sep 02, 2014 at 06:06:17PM +0200, Antonios Motakis wrote:
> On Sun, Jun 8, 2014 at 12:17 PM, Christoffer Dall
> <christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> > On Thu, Jun 05, 2014 at 07:03:23PM +0200, Antonios Motakis wrote:
> >> Adds support to mask interrupts, and also for automasked interrupts.
> >> Level sensitive interrupts are exposed as automasked interrupts and
> >> are masked and disabled automatically when they fire.
> >>
> >> Signed-off-by: Antonios Motakis <a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
> >> ---
> >>  drivers/vfio/platform/vfio_platform_irq.c     | 112 ++++++++++++++++++++++++--
> >>  drivers/vfio/platform/vfio_platform_private.h |   2 +
> >>  2 files changed, 109 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/vfio/platform/vfio_platform_irq.c b/drivers/vfio/platform/vfio_platform_irq.c
> >> index d79f5af..10dfbf0 100644
> >> --- a/drivers/vfio/platform/vfio_platform_irq.c
> >> +++ b/drivers/vfio/platform/vfio_platform_irq.c
> >> @@ -51,9 +51,17 @@ int vfio_platform_irq_init(struct vfio_platform_device *vdev)
> >>               if (hwirq < 0)
> >>                       goto err;
> >>
> >> -             vdev->irq[i].flags = VFIO_IRQ_INFO_EVENTFD;
> >> +             spin_lock_init(&vdev->irq[i].lock);
> >> +
> >> +             vdev->irq[i].flags = VFIO_IRQ_INFO_EVENTFD
> >> +                                     | VFIO_IRQ_INFO_MASKABLE;
> >> +
> >> +             if (irq_get_trigger_type(hwirq) & IRQ_TYPE_LEVEL_MASK)
> >> +                     vdev->irq[i].flags |= VFIO_IRQ_INFO_AUTOMASKED;
> >
> > This seems to rely on the fact that you had actually loaded a driver for
> > your device to set the right type.  Is this assumption always correct?
> >
> > It seems to me that this configuration bit should now be up to your user
> > space drive who is the best candidate to know details about your device
> > at this point?
> >
> 
> Hm, I see this type being set usually either in a device tree source,
> or in the support code for a specific platform. Are there any
> situations where this is actually set by the driver? If I understand
> right this is not the case for the PL330, but if it is possible that
> it is the case for another device then I need to rethink this. Though
> as far as I understand this should not be the case.
> 

Wow, this has been incredibly long time since I looked at this code, so
not sure if I remember my original reasoning anymore, however,

while device properties are set in the DT, they would only be available
to this code if you actually loaded a device driver for that device,
right?  I'm just not sure that assumption always holds for devices used
by VFIO, but I'm really not sure anymore.  Maybe I'm rambling.

> >> +
> >>               vdev->irq[i].count = 1;
> >>               vdev->irq[i].hwirq = hwirq;
> >> +             vdev->irq[i].masked = false;
> >>       }
> >>
> >>       vdev->num_irqs = cnt;
> >> @@ -77,11 +85,27 @@ void vfio_platform_irq_cleanup(struct vfio_platform_device *vdev)
> >>
> >>  static irqreturn_t vfio_irq_handler(int irq, void *dev_id)
> >>  {
> >> -     struct eventfd_ctx *trigger = dev_id;
> >> +     struct vfio_platform_irq *irq_ctx = dev_id;
> >> +     unsigned long flags;
> >> +     int ret = IRQ_NONE;
> >> +
> >> +     spin_lock_irqsave(&irq_ctx->lock, flags);
> >> +
> >> +     if (!irq_ctx->masked) {
> >> +             ret = IRQ_HANDLED;
> >> +
> >> +             if (irq_ctx->flags & VFIO_IRQ_INFO_AUTOMASKED) {
> >> +                     disable_irq_nosync(irq_ctx->hwirq);
> >> +                     irq_ctx->masked = true;
> >> +             }
> >> +     }
> >>
> >> -     eventfd_signal(trigger, 1);
> >> +     spin_unlock_irqrestore(&irq_ctx->lock, flags);
> >>
> >> -     return IRQ_HANDLED;
> >> +     if (ret == IRQ_HANDLED)
> >> +             eventfd_signal(irq_ctx->trigger, 1);
> >> +
> >> +     return ret;
> >>  }
> >>
> >>  static int vfio_set_trigger(struct vfio_platform_device *vdev,
> >> @@ -162,6 +186,82 @@ static int vfio_platform_set_irq_trigger(struct vfio_platform_device *vdev,
> >>       return -EFAULT;
> >>  }
> >>
> >> +static int vfio_platform_set_irq_unmask(struct vfio_platform_device *vdev,
> >> +                                 unsigned index, unsigned start,
> >> +                                 unsigned count, uint32_t flags, void *data)
> >> +{
> >> +     uint8_t arr;
> >
> >
> > arr?
> 
> arr for array! As in, the VFIO API allows an array of IRQs. However
> for platform devices we don't use this, each IRQ is exposed
> independently as an array of 1 IRQ.
> 

but it's not an array.  If it contains IRQs, call it irqs.  Unless this
is referring specifically to a field *named* array, I don't remember the
API at current, but reading the code along it didn't make sense to me to
have a uint8_t called arr, and code should make as much sense
independenly as possible.

This reminds me of people writing code like:

String str;

yuck.

> >
> >> +
> >> +     if (start != 0 || count != 1)
> >> +             return -EINVAL;
> >> +
> >> +     switch (flags & VFIO_IRQ_SET_DATA_TYPE_MASK) {
> >> +     case VFIO_IRQ_SET_DATA_BOOL:
> >> +             if (copy_from_user(&arr, data, sizeof(uint8_t)))
> >> +                     return -EFAULT;
> >> +
> >> +             if (arr != 0x1)
> >> +                     return -EINVAL;
> >
> > why the fallthrough, what's this about?
> 
> The VFIO API allows to unmask/mask an array of IRQs, however with
> platform devices we only have arrays of 1 IRQ (so not really arrays).
> 
> So if the user uses VFIO_IRQ_SET_DATA_BOOL, we need to check that arr
> == 0x1. When that is the case, a fallthrough to the same code for
> VFIO_IRQ_SET_DATA_NONE is safe.
> 
> If that is not readable enough, then I can add a comment or duplicate
> the code that does the unmasking. I realize that if you don't know the
> VFIO API well, then this can look confusing.
> 

yeah, please put a big fat comment explaining the fallthrough.

-Christoffer

WARNING: multiple messages have this Message-ID (diff)
From: Christoffer Dall <christoffer.dall@linaro.org>
To: Antonios Motakis <a.motakis@virtualopensystems.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
	kvm-arm <kvmarm@lists.cs.columbia.edu>,
	Linux IOMMU <iommu@lists.linux-foundation.org>,
	VirtualOpenSystems Technical Team <tech@virtualopensystems.com>,
	alvise rigo <a.rigo@virtualopensystems.com>,
	KVM devel mailing list <kvm@vger.kernel.org>,
	Will Deacon <will.deacon@arm.com>,
	Kim Phillips <kim.phillips@freescale.com>,
	Stuart Yoder <stuart.yoder@freescale.com>,
	Eric Auger <eric.auger@linaro.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Vladimir Murzin <vladimir.murzin@arm.com>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH v6 15/20] vfio/platform: support for maskable and automasked interrupts
Date: Wed, 10 Sep 2014 12:13:33 +0200	[thread overview]
Message-ID: <20140910101333.GA3002@lvm> (raw)
In-Reply-To: <CAG8rG2z02JPE+D-Bo1puuMPCR=wETciLaBgKT+i1XKQ55U-kYg@mail.gmail.com>

On Tue, Sep 02, 2014 at 06:06:17PM +0200, Antonios Motakis wrote:
> On Sun, Jun 8, 2014 at 12:17 PM, Christoffer Dall
> <christoffer.dall@linaro.org> wrote:
> > On Thu, Jun 05, 2014 at 07:03:23PM +0200, Antonios Motakis wrote:
> >> Adds support to mask interrupts, and also for automasked interrupts.
> >> Level sensitive interrupts are exposed as automasked interrupts and
> >> are masked and disabled automatically when they fire.
> >>
> >> Signed-off-by: Antonios Motakis <a.motakis@virtualopensystems.com>
> >> ---
> >>  drivers/vfio/platform/vfio_platform_irq.c     | 112 ++++++++++++++++++++++++--
> >>  drivers/vfio/platform/vfio_platform_private.h |   2 +
> >>  2 files changed, 109 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/vfio/platform/vfio_platform_irq.c b/drivers/vfio/platform/vfio_platform_irq.c
> >> index d79f5af..10dfbf0 100644
> >> --- a/drivers/vfio/platform/vfio_platform_irq.c
> >> +++ b/drivers/vfio/platform/vfio_platform_irq.c
> >> @@ -51,9 +51,17 @@ int vfio_platform_irq_init(struct vfio_platform_device *vdev)
> >>               if (hwirq < 0)
> >>                       goto err;
> >>
> >> -             vdev->irq[i].flags = VFIO_IRQ_INFO_EVENTFD;
> >> +             spin_lock_init(&vdev->irq[i].lock);
> >> +
> >> +             vdev->irq[i].flags = VFIO_IRQ_INFO_EVENTFD
> >> +                                     | VFIO_IRQ_INFO_MASKABLE;
> >> +
> >> +             if (irq_get_trigger_type(hwirq) & IRQ_TYPE_LEVEL_MASK)
> >> +                     vdev->irq[i].flags |= VFIO_IRQ_INFO_AUTOMASKED;
> >
> > This seems to rely on the fact that you had actually loaded a driver for
> > your device to set the right type.  Is this assumption always correct?
> >
> > It seems to me that this configuration bit should now be up to your user
> > space drive who is the best candidate to know details about your device
> > at this point?
> >
> 
> Hm, I see this type being set usually either in a device tree source,
> or in the support code for a specific platform. Are there any
> situations where this is actually set by the driver? If I understand
> right this is not the case for the PL330, but if it is possible that
> it is the case for another device then I need to rethink this. Though
> as far as I understand this should not be the case.
> 

Wow, this has been incredibly long time since I looked at this code, so
not sure if I remember my original reasoning anymore, however,

while device properties are set in the DT, they would only be available
to this code if you actually loaded a device driver for that device,
right?  I'm just not sure that assumption always holds for devices used
by VFIO, but I'm really not sure anymore.  Maybe I'm rambling.

> >> +
> >>               vdev->irq[i].count = 1;
> >>               vdev->irq[i].hwirq = hwirq;
> >> +             vdev->irq[i].masked = false;
> >>       }
> >>
> >>       vdev->num_irqs = cnt;
> >> @@ -77,11 +85,27 @@ void vfio_platform_irq_cleanup(struct vfio_platform_device *vdev)
> >>
> >>  static irqreturn_t vfio_irq_handler(int irq, void *dev_id)
> >>  {
> >> -     struct eventfd_ctx *trigger = dev_id;
> >> +     struct vfio_platform_irq *irq_ctx = dev_id;
> >> +     unsigned long flags;
> >> +     int ret = IRQ_NONE;
> >> +
> >> +     spin_lock_irqsave(&irq_ctx->lock, flags);
> >> +
> >> +     if (!irq_ctx->masked) {
> >> +             ret = IRQ_HANDLED;
> >> +
> >> +             if (irq_ctx->flags & VFIO_IRQ_INFO_AUTOMASKED) {
> >> +                     disable_irq_nosync(irq_ctx->hwirq);
> >> +                     irq_ctx->masked = true;
> >> +             }
> >> +     }
> >>
> >> -     eventfd_signal(trigger, 1);
> >> +     spin_unlock_irqrestore(&irq_ctx->lock, flags);
> >>
> >> -     return IRQ_HANDLED;
> >> +     if (ret == IRQ_HANDLED)
> >> +             eventfd_signal(irq_ctx->trigger, 1);
> >> +
> >> +     return ret;
> >>  }
> >>
> >>  static int vfio_set_trigger(struct vfio_platform_device *vdev,
> >> @@ -162,6 +186,82 @@ static int vfio_platform_set_irq_trigger(struct vfio_platform_device *vdev,
> >>       return -EFAULT;
> >>  }
> >>
> >> +static int vfio_platform_set_irq_unmask(struct vfio_platform_device *vdev,
> >> +                                 unsigned index, unsigned start,
> >> +                                 unsigned count, uint32_t flags, void *data)
> >> +{
> >> +     uint8_t arr;
> >
> >
> > arr?
> 
> arr for array! As in, the VFIO API allows an array of IRQs. However
> for platform devices we don't use this, each IRQ is exposed
> independently as an array of 1 IRQ.
> 

but it's not an array.  If it contains IRQs, call it irqs.  Unless this
is referring specifically to a field *named* array, I don't remember the
API at current, but reading the code along it didn't make sense to me to
have a uint8_t called arr, and code should make as much sense
independenly as possible.

This reminds me of people writing code like:

String str;

yuck.

> >
> >> +
> >> +     if (start != 0 || count != 1)
> >> +             return -EINVAL;
> >> +
> >> +     switch (flags & VFIO_IRQ_SET_DATA_TYPE_MASK) {
> >> +     case VFIO_IRQ_SET_DATA_BOOL:
> >> +             if (copy_from_user(&arr, data, sizeof(uint8_t)))
> >> +                     return -EFAULT;
> >> +
> >> +             if (arr != 0x1)
> >> +                     return -EINVAL;
> >
> > why the fallthrough, what's this about?
> 
> The VFIO API allows to unmask/mask an array of IRQs, however with
> platform devices we only have arrays of 1 IRQ (so not really arrays).
> 
> So if the user uses VFIO_IRQ_SET_DATA_BOOL, we need to check that arr
> == 0x1. When that is the case, a fallthrough to the same code for
> VFIO_IRQ_SET_DATA_NONE is safe.
> 
> If that is not readable enough, then I can add a comment or duplicate
> the code that does the unmasking. I realize that if you don't know the
> VFIO API well, then this can look confusing.
> 

yeah, please put a big fat comment explaining the fallthrough.

-Christoffer

  parent reply	other threads:[~2014-09-10 10:13 UTC|newest]

Thread overview: 131+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-05 17:03 [RFC PATCH v6 00/20] VFIO support for platform devices on ARM Antonios Motakis
     [not found] ` <1401987808-23596-1-git-send-email-a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
2014-06-05 17:03   ` [RFC PATCH v6 01/20] iommu/arm-smmu: change IOMMU_EXEC to IOMMU_NOEXEC Antonios Motakis
2014-06-05 17:03     ` Antonios Motakis
2014-06-05 17:03     ` Antonios Motakis
2014-06-16 15:04     ` Will Deacon
2014-06-16 15:04       ` Will Deacon
2014-06-16 15:04       ` Will Deacon
2014-06-16 15:04       ` Will Deacon
2014-06-05 17:03   ` [RFC PATCH v6 02/20] iommu: add capability IOMMU_CAP_NOEXEC Antonios Motakis
2014-06-05 17:03     ` Antonios Motakis
     [not found]     ` <1401987808-23596-3-git-send-email-a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
2014-06-05 20:03       ` Alex Williamson
2014-06-05 20:03         ` Alex Williamson
     [not found]         ` <1401998627.9207.227.camel-85EaTFmN5p//9pzu0YdTqQ@public.gmane.org>
2014-06-06 16:35           ` Antonios Motakis
2014-06-05 17:03   ` [RFC PATCH v6 03/20] iommu/arm-smmu: add IOMMU_CAP_NOEXEC to the ARM SMMU driver Antonios Motakis
2014-06-05 17:03     ` Antonios Motakis
2014-06-05 17:03     ` Antonios Motakis
     [not found]     ` <1401987808-23596-4-git-send-email-a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
2014-06-16 15:04       ` Will Deacon
2014-06-16 15:04         ` Will Deacon
2014-06-16 15:04         ` Will Deacon
     [not found]         ` <20140616150451.GP16758-5wv7dgnIgG8@public.gmane.org>
2014-06-16 15:25           ` Alex Williamson
2014-06-16 15:25             ` Alex Williamson
2014-06-16 15:25             ` Alex Williamson
     [not found]             ` <1402932328.3707.36.camel-85EaTFmN5p//9pzu0YdTqQ@public.gmane.org>
2014-06-16 15:30               ` Will Deacon
2014-06-16 15:30                 ` Will Deacon
2014-06-16 15:30                 ` Will Deacon
2014-06-05 17:03   ` [RFC PATCH v6 04/20] iommu/arm-smmu: add capability IOMMU_CAP_INTR_REMAP Antonios Motakis
2014-06-05 17:03     ` Antonios Motakis
2014-06-05 17:03     ` Antonios Motakis
     [not found]     ` <1401987808-23596-5-git-send-email-a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
2014-06-05 18:31       ` Varun Sethi
2014-06-05 18:31         ` Varun Sethi
2014-06-05 18:31         ` Varun Sethi
2014-06-08 10:31       ` Christoffer Dall
2014-06-08 10:31         ` Christoffer Dall
2014-06-08 10:31         ` Christoffer Dall
2014-06-16 14:53         ` Joerg Roedel
2014-06-16 14:53           ` Joerg Roedel
2014-06-16 14:53           ` Joerg Roedel
     [not found]           ` <20140616145344.GD18986-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2014-06-16 15:13             ` Will Deacon
2014-06-16 15:13               ` Will Deacon
2014-06-16 15:13               ` Will Deacon
     [not found]               ` <20140616151329.GQ16758-5wv7dgnIgG8@public.gmane.org>
2014-06-16 15:21                 ` Joerg Roedel
2014-06-16 15:21                   ` Joerg Roedel
2014-06-16 15:21                   ` Joerg Roedel
     [not found]                   ` <20140616152157.GB31771-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2014-06-16 15:25                     ` Will Deacon
2014-06-16 15:25                       ` Will Deacon
2014-06-16 15:25                       ` Will Deacon
     [not found]                       ` <20140616152526.GR16758-5wv7dgnIgG8@public.gmane.org>
2014-06-16 15:38                         ` Joerg Roedel
2014-06-16 15:38                           ` Joerg Roedel
2014-06-16 15:38                           ` Joerg Roedel
2014-06-26 18:08                           ` Chalamarla, Tirumalesh
2014-06-26 18:08                             ` Chalamarla, Tirumalesh
2014-06-26 18:15                             ` Chalamarla, Tirumalesh
2014-06-26 18:15                               ` Chalamarla, Tirumalesh
2014-06-26 18:41                               ` Chalamarla, Tirumalesh
2014-06-26 18:41                                 ` Chalamarla, Tirumalesh
     [not found]                                 ` <b085e02e72dc424d9624c3e810951087-Rl8gF8DaO8QN+Mk3fGG+YBQPvRvOrrxkXA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
2014-06-26 19:00                                   ` Alex Williamson
2014-06-26 19:00                                     ` Alex Williamson
2014-06-26 19:00                                     ` Alex Williamson
2014-06-26 19:10                                     ` Chalamarla, Tirumalesh
2014-06-26 19:10                                       ` Chalamarla, Tirumalesh
2014-06-26 19:10                                       ` Chalamarla, Tirumalesh
     [not found]                                       ` <ec8dbbcb991e4d73b73f4b4f98342445-Rl8gF8DaO8QN+Mk3fGG+YBQPvRvOrrxkXA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
2014-06-26 19:36                                         ` Alex Williamson
2014-06-26 19:36                                           ` Alex Williamson
2014-06-26 19:36                                           ` Alex Williamson
     [not found]                                           ` <1403811384.31091.151.camel-85EaTFmN5p//9pzu0YdTqQ@public.gmane.org>
2014-06-27  8:47                                             ` Will Deacon
2014-06-27  8:47                                               ` Will Deacon
2014-06-27  8:47                                               ` Will Deacon
2014-06-27 21:57                                               ` Chalamarla, Tirumalesh
2014-06-27 21:57                                                 ` Chalamarla, Tirumalesh
2014-06-27 21:57                                                 ` Chalamarla, Tirumalesh
     [not found]                                                 ` <2645e3a22f5e4ae9994c0ee8fa327cb4-Rl8gF8DaO8QN+Mk3fGG+YBQPvRvOrrxkXA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
2014-06-28  7:05                                                   ` Marc Zyngier
2014-06-28  7:05                                                     ` Marc Zyngier
2014-06-28  7:05                                                     ` Marc Zyngier
2014-06-28  7:05                                                     ` Marc Zyngier
2014-06-16 15:30                     ` Alex Williamson
2014-06-16 15:30                       ` Alex Williamson
2014-06-16 15:30                       ` Alex Williamson
2014-06-05 17:03   ` [RFC PATCH v6 05/20] vfio/iommu_type1: support for platform bus devices on ARM Antonios Motakis
2014-06-05 17:03     ` Antonios Motakis
2014-06-05 17:03   ` [RFC PATCH v6 06/20] vfio: introduce the VFIO_DMA_MAP_FLAG_NOEXEC flag Antonios Motakis
2014-06-05 17:03     ` Antonios Motakis
2014-06-05 17:03   ` [RFC PATCH v6 07/20] vfio/iommu_type1: implement " Antonios Motakis
2014-06-05 17:03     ` Antonios Motakis
     [not found]     ` <1401987808-23596-8-git-send-email-a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
2014-06-05 20:48       ` Alex Williamson
2014-06-05 20:48         ` Alex Williamson
2014-06-05 17:03   ` [RFC PATCH v6 08/20] driver core: platform: add device binding path 'driver_override' Antonios Motakis
2014-06-05 17:03     ` Antonios Motakis
2014-06-05 17:03   ` [RFC PATCH v6 09/20] vfio/platform: initial skeleton of VFIO support for platform devices Antonios Motakis
2014-06-05 17:03     ` Antonios Motakis
2014-06-05 17:03   ` [RFC PATCH v6 10/20] vfio/platform: return info for device and its memory mapped IO regions Antonios Motakis
2014-06-05 17:03     ` Antonios Motakis
     [not found]     ` <1401987808-23596-11-git-send-email-a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
2014-06-05 21:14       ` Alex Williamson
2014-06-05 21:14         ` Alex Williamson
     [not found]         ` <1402002841.9207.260.camel-85EaTFmN5p//9pzu0YdTqQ@public.gmane.org>
2014-06-06 16:39           ` Antonios Motakis
2014-06-06 16:39             ` Antonios Motakis
2014-06-05 17:03   ` [RFC PATCH v6 11/20] vfio/platform: read and write support for the device fd Antonios Motakis
2014-06-05 17:03     ` Antonios Motakis
2014-06-05 17:03   ` [RFC PATCH v6 13/20] vfio/platform: return IRQ info Antonios Motakis
2014-06-05 17:03     ` Antonios Motakis
2014-06-05 17:03   ` [RFC PATCH v6 14/20] vfio/platform: initial interrupts support Antonios Motakis
2014-06-05 17:03     ` Antonios Motakis
     [not found]     ` <1401987808-23596-15-git-send-email-a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
2014-06-08 10:09       ` Christoffer Dall
2014-06-08 10:09         ` Christoffer Dall
2014-09-02 16:07         ` Antonios Motakis
2014-09-02 16:07           ` Antonios Motakis
2014-06-05 17:03   ` [RFC PATCH v6 15/20] vfio/platform: support for maskable and automasked interrupts Antonios Motakis
2014-06-05 17:03     ` Antonios Motakis
     [not found]     ` <1401987808-23596-16-git-send-email-a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
2014-06-08 10:17       ` Christoffer Dall
2014-06-08 10:17         ` Christoffer Dall
2014-09-02 16:06         ` Antonios Motakis
2014-09-02 16:06           ` Antonios Motakis
     [not found]           ` <CAG8rG2z02JPE+D-Bo1puuMPCR=wETciLaBgKT+i1XKQ55U-kYg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-09-10 10:13             ` Christoffer Dall [this message]
2014-09-10 10:13               ` Christoffer Dall
2014-09-11 17:20               ` Antonios Motakis
2014-09-11 17:20                 ` Antonios Motakis
2014-06-05 17:03   ` [RFC PATCH v6 16/20] vfio: move eventfd support code for VFIO_PCI to a sepparate file Antonios Motakis
2014-06-05 17:03     ` Antonios Motakis
2014-06-05 17:03   ` [RFC PATCH v6 17/20] vfio: add local lock in virqfd instead of depending on VFIO PCI Antonios Motakis
2014-06-05 17:03     ` Antonios Motakis
     [not found]     ` <1401987808-23596-18-git-send-email-a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
2014-06-05 22:19       ` Alex Williamson
2014-06-05 22:19         ` Alex Williamson
     [not found]         ` <1402006750.9207.267.camel-85EaTFmN5p//9pzu0YdTqQ@public.gmane.org>
2014-06-06 16:57           ` Antonios Motakis
2014-06-06 16:57             ` Antonios Motakis
2014-06-05 17:03   ` [RFC PATCH v6 18/20] vfio: pass an opaque pointer on virqfd initialization Antonios Motakis
2014-06-05 17:03     ` Antonios Motakis
2014-06-05 17:03   ` [RFC PATCH v6 19/20] vfio: initialize the virqfd workqueue in VFIO generic code Antonios Motakis
2014-06-05 17:03     ` Antonios Motakis
2014-06-05 17:03   ` [RFC PATCH v6 20/20] vfio/platform: implement IRQ masking/unmasking via an eventfd Antonios Motakis
2014-06-05 17:03     ` Antonios Motakis
2014-06-05 17:03 ` [RFC PATCH v6 12/20] vfio/platform: support MMAP of MMIO regions Antonios Motakis
2014-06-05 17:03   ` Antonios Motakis

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=20140910101333.GA3002@lvm \
    --to=christoffer.dall-qsej5fyqhm4dnm+yrofe0a@public.gmane.org \
    --cc=a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org \
    --cc=a.rigo-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org \
    --cc=catalin.marinas-5wv7dgnIgG8@public.gmane.org \
    --cc=eric.auger-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
    --cc=stuart.yoder-KZfg59tc24xl57MIdRCFDg@public.gmane.org \
    --cc=tech-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org \
    --cc=vladimir.murzin-5wv7dgnIgG8@public.gmane.org \
    --cc=will.deacon-5wv7dgnIgG8@public.gmane.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 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.