From: Auger Eric <eric.auger-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Geetha Akula
<geethasowjanya.akula-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: "drjones-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org"
<drjones-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
"jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org"
<jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>,
"kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"marc.zyngier-5wv7dgnIgG8@public.gmane.org"
<marc.zyngier-5wv7dgnIgG8@public.gmane.org>,
"punit.agrawal-5wv7dgnIgG8@public.gmane.org"
<punit.agrawal-5wv7dgnIgG8@public.gmane.org>,
"will.deacon-5wv7dgnIgG8@public.gmane.org"
<will.deacon-5wv7dgnIgG8@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org"
<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
"pranav.sawargaonkar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
<pranav.sawargaonkar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"shankerd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org"
<shankerd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
"tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org"
<tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>,
"gpkulkarni-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
<gpkulkarni-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org"
<christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
"eric.auger.pro-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
<eric.auger.pro-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: [RFC v4 15/16] vfio/type1: Check MSI remapping at irq domain level
Date: Fri, 23 Dec 2016 16:13:24 +0100 [thread overview]
Message-ID: <72057deb-cc71-33f1-e96a-ed2c96a99c3b@redhat.com> (raw)
In-Reply-To: <CANHdaibH3GCFhM4nXh1KJoFhZCodtWo7KfP7AcSoVD0HwjDWfg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Geetha,
On 23/12/2016 14:33, Geetha Akula wrote:
> Hi Eric,
>
> Seeing same issue reported by Diana on ThunderX with you
> v4.9-reserved-v4 branch.
> Vfio passthough work fine when allow_unsafe_interrupts is set.
Thank you for testing! I will fix the security assessment by better
studying flag propagation in domain hierarchy.
Best Regards
Eric
>
>
> Thank you,
> Geetha.
>
> On Thu, Dec 22, 2016 at 6:32 PM, Auger Eric <eric.auger-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
> <mailto:eric.auger-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>> wrote:
>
> Hi Diana,
>
> On 22/12/2016 13:41, Diana Madalina Craciun wrote:
> > Hi Eric,
> >
> > On 12/13/2016 10:32 PM, Eric Auger wrote:
> >> In case the IOMMU does not bypass MSI transactions (typical
> >> case on ARM), we check all MSI controllers are IRQ remapping
> >> capable. If not the IRQ assignment may be unsafe.
> >>
> >> At this stage the arm-smmu-(v3) still advertise the
> >> IOMMU_CAP_INTR_REMAP capability at IOMMU level. This will be
> >> removed in subsequent patches.
> >>
> >> Signed-off-by: Eric Auger <eric.auger-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
> <mailto:eric.auger-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>>
> >> ---
> >> drivers/vfio/vfio_iommu_type1.c | 9 ++++++---
> >> 1 file changed, 6 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/vfio/vfio_iommu_type1.c
> b/drivers/vfio/vfio_iommu_type1.c
> >> index d07fe73..a05648b 100644
> >> --- a/drivers/vfio/vfio_iommu_type1.c
> >> +++ b/drivers/vfio/vfio_iommu_type1.c
> >> @@ -37,6 +37,7 @@
> >> #include <linux/vfio.h>
> >> #include <linux/workqueue.h>
> >> #include <linux/dma-iommu.h>
> >> +#include <linux/irqdomain.h>
> >>
> >> #define DRIVER_VERSION "0.2"
> >> #define DRIVER_AUTHOR "Alex Williamson
> <alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org <mailto:alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>>"
> >> @@ -765,7 +766,7 @@ static int vfio_iommu_type1_attach_group(void
> *iommu_data,
> >> struct vfio_domain *domain, *d;
> >> struct bus_type *bus = NULL;
> >> int ret;
> >> - bool resv_msi;
> >> + bool resv_msi, msi_remap;
> >> phys_addr_t resv_msi_base;
> >>
> >> mutex_lock(&iommu->lock);
> >> @@ -818,8 +819,10 @@ static int
> vfio_iommu_type1_attach_group(void *iommu_data,
> >> INIT_LIST_HEAD(&domain->group_list);
> >> list_add(&group->next, &domain->group_list);
> >>
> >> - if (!allow_unsafe_interrupts &&
> >> - !iommu_capable(bus, IOMMU_CAP_INTR_REMAP)) {
> >> + msi_remap = resv_msi ? irq_domain_check_msi_remap() :
> >> + iommu_capable(bus, IOMMU_CAP_INTR_REMAP);
> >> +
> >> + if (!allow_unsafe_interrupts && !msi_remap) {
> >> pr_warn("%s: No interrupt remapping support. Use
> the module param \"allow_unsafe_interrupts\" to enable VFIO IOMMU
> support on this platform\n",
> >> __func__);
> >> ret = -EPERM;
> >
> > I tested your v4.9-reserved-v4 branch on a ITS capable hardware (NXP
> > LS2080), so I did not set allow_unsafe_interrupts. It fails here
> > complaining that the there is no interrupt remapping support. The
> > irq_domain_check_msi_remap function returns false as none of the
> checked
> > domains has the IRQ_DOMAIN_FLAG_MSI_REMAP flag set. I think the reason
> > is that the flags are not propagated through the domain hierarchy when
> > the domain is created.
>
> Hum OK. Please apologize for the inconvenience, all the more so this is
> the second time you report the same issue for different cause :-( At the
> moment I can't test on a GICv3 ITS based system. I will try to fix that
> though.
>
> I would like to get the confirmation introducing this flag is the right
> direction though.
>
> Thanks
>
> Eric
> >
> > Thanks,
> >
> > Diana
> >
> >
> >
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> <mailto:linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> <http://lists.infradead.org/mailman/listinfo/linux-arm-kernel>
>
>
WARNING: multiple messages have this Message-ID (diff)
From: eric.auger@redhat.com (Auger Eric)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC v4 15/16] vfio/type1: Check MSI remapping at irq domain level
Date: Fri, 23 Dec 2016 16:13:24 +0100 [thread overview]
Message-ID: <72057deb-cc71-33f1-e96a-ed2c96a99c3b@redhat.com> (raw)
In-Reply-To: <CANHdaibH3GCFhM4nXh1KJoFhZCodtWo7KfP7AcSoVD0HwjDWfg@mail.gmail.com>
Hi Geetha,
On 23/12/2016 14:33, Geetha Akula wrote:
> Hi Eric,
>
> Seeing same issue reported by Diana on ThunderX with you
> v4.9-reserved-v4 branch.
> Vfio passthough work fine when allow_unsafe_interrupts is set.
Thank you for testing! I will fix the security assessment by better
studying flag propagation in domain hierarchy.
Best Regards
Eric
>
>
> Thank you,
> Geetha.
>
> On Thu, Dec 22, 2016 at 6:32 PM, Auger Eric <eric.auger@redhat.com
> <mailto:eric.auger@redhat.com>> wrote:
>
> Hi Diana,
>
> On 22/12/2016 13:41, Diana Madalina Craciun wrote:
> > Hi Eric,
> >
> > On 12/13/2016 10:32 PM, Eric Auger wrote:
> >> In case the IOMMU does not bypass MSI transactions (typical
> >> case on ARM), we check all MSI controllers are IRQ remapping
> >> capable. If not the IRQ assignment may be unsafe.
> >>
> >> At this stage the arm-smmu-(v3) still advertise the
> >> IOMMU_CAP_INTR_REMAP capability at IOMMU level. This will be
> >> removed in subsequent patches.
> >>
> >> Signed-off-by: Eric Auger <eric.auger@redhat.com
> <mailto:eric.auger@redhat.com>>
> >> ---
> >> drivers/vfio/vfio_iommu_type1.c | 9 ++++++---
> >> 1 file changed, 6 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/vfio/vfio_iommu_type1.c
> b/drivers/vfio/vfio_iommu_type1.c
> >> index d07fe73..a05648b 100644
> >> --- a/drivers/vfio/vfio_iommu_type1.c
> >> +++ b/drivers/vfio/vfio_iommu_type1.c
> >> @@ -37,6 +37,7 @@
> >> #include <linux/vfio.h>
> >> #include <linux/workqueue.h>
> >> #include <linux/dma-iommu.h>
> >> +#include <linux/irqdomain.h>
> >>
> >> #define DRIVER_VERSION "0.2"
> >> #define DRIVER_AUTHOR "Alex Williamson
> <alex.williamson at redhat.com <mailto:alex.williamson@redhat.com>>"
> >> @@ -765,7 +766,7 @@ static int vfio_iommu_type1_attach_group(void
> *iommu_data,
> >> struct vfio_domain *domain, *d;
> >> struct bus_type *bus = NULL;
> >> int ret;
> >> - bool resv_msi;
> >> + bool resv_msi, msi_remap;
> >> phys_addr_t resv_msi_base;
> >>
> >> mutex_lock(&iommu->lock);
> >> @@ -818,8 +819,10 @@ static int
> vfio_iommu_type1_attach_group(void *iommu_data,
> >> INIT_LIST_HEAD(&domain->group_list);
> >> list_add(&group->next, &domain->group_list);
> >>
> >> - if (!allow_unsafe_interrupts &&
> >> - !iommu_capable(bus, IOMMU_CAP_INTR_REMAP)) {
> >> + msi_remap = resv_msi ? irq_domain_check_msi_remap() :
> >> + iommu_capable(bus, IOMMU_CAP_INTR_REMAP);
> >> +
> >> + if (!allow_unsafe_interrupts && !msi_remap) {
> >> pr_warn("%s: No interrupt remapping support. Use
> the module param \"allow_unsafe_interrupts\" to enable VFIO IOMMU
> support on this platform\n",
> >> __func__);
> >> ret = -EPERM;
> >
> > I tested your v4.9-reserved-v4 branch on a ITS capable hardware (NXP
> > LS2080), so I did not set allow_unsafe_interrupts. It fails here
> > complaining that the there is no interrupt remapping support. The
> > irq_domain_check_msi_remap function returns false as none of the
> checked
> > domains has the IRQ_DOMAIN_FLAG_MSI_REMAP flag set. I think the reason
> > is that the flags are not propagated through the domain hierarchy when
> > the domain is created.
>
> Hum OK. Please apologize for the inconvenience, all the more so this is
> the second time you report the same issue for different cause :-( At the
> moment I can't test on a GICv3 ITS based system. I will try to fix that
> though.
>
> I would like to get the confirmation introducing this flag is the right
> direction though.
>
> Thanks
>
> Eric
> >
> > Thanks,
> >
> > Diana
> >
> >
> >
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> <mailto:linux-arm-kernel@lists.infradead.org>
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> <http://lists.infradead.org/mailman/listinfo/linux-arm-kernel>
>
>
WARNING: multiple messages have this Message-ID (diff)
From: Auger Eric <eric.auger@redhat.com>
To: Geetha Akula <geethasowjanya.akula@gmail.com>
Cc: Diana Madalina Craciun <diana.craciun@nxp.com>,
"eric.auger.pro@gmail.com" <eric.auger.pro@gmail.com>,
"christoffer.dall@linaro.org" <christoffer.dall@linaro.org>,
"marc.zyngier@arm.com" <marc.zyngier@arm.com>,
"robin.murphy@arm.com" <robin.murphy@arm.com>,
"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
"will.deacon@arm.com" <will.deacon@arm.com>,
"joro@8bytes.org" <joro@8bytes.org>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"jason@lakedaemon.net" <jason@lakedaemon.net>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"drjones@redhat.com" <drjones@redhat.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"punit.agrawal@arm.com" <punit.agrawal@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"pranav.sawargaonkar@gmail.com" <pranav.sawargaonkar@gmail.com>,
Bharat Bhushan <bharat.bhushan@nxp.com>,
"shankerd@codeaurora.org" <shankerd@codeaurora.org>,
"gpkulkarni@gmail.com" <gpkulkarni@gmail.com>
Subject: Re: [RFC v4 15/16] vfio/type1: Check MSI remapping at irq domain level
Date: Fri, 23 Dec 2016 16:13:24 +0100 [thread overview]
Message-ID: <72057deb-cc71-33f1-e96a-ed2c96a99c3b@redhat.com> (raw)
In-Reply-To: <CANHdaibH3GCFhM4nXh1KJoFhZCodtWo7KfP7AcSoVD0HwjDWfg@mail.gmail.com>
Hi Geetha,
On 23/12/2016 14:33, Geetha Akula wrote:
> Hi Eric,
>
> Seeing same issue reported by Diana on ThunderX with you
> v4.9-reserved-v4 branch.
> Vfio passthough work fine when allow_unsafe_interrupts is set.
Thank you for testing! I will fix the security assessment by better
studying flag propagation in domain hierarchy.
Best Regards
Eric
>
>
> Thank you,
> Geetha.
>
> On Thu, Dec 22, 2016 at 6:32 PM, Auger Eric <eric.auger@redhat.com
> <mailto:eric.auger@redhat.com>> wrote:
>
> Hi Diana,
>
> On 22/12/2016 13:41, Diana Madalina Craciun wrote:
> > Hi Eric,
> >
> > On 12/13/2016 10:32 PM, Eric Auger wrote:
> >> In case the IOMMU does not bypass MSI transactions (typical
> >> case on ARM), we check all MSI controllers are IRQ remapping
> >> capable. If not the IRQ assignment may be unsafe.
> >>
> >> At this stage the arm-smmu-(v3) still advertise the
> >> IOMMU_CAP_INTR_REMAP capability at IOMMU level. This will be
> >> removed in subsequent patches.
> >>
> >> Signed-off-by: Eric Auger <eric.auger@redhat.com
> <mailto:eric.auger@redhat.com>>
> >> ---
> >> drivers/vfio/vfio_iommu_type1.c | 9 ++++++---
> >> 1 file changed, 6 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/vfio/vfio_iommu_type1.c
> b/drivers/vfio/vfio_iommu_type1.c
> >> index d07fe73..a05648b 100644
> >> --- a/drivers/vfio/vfio_iommu_type1.c
> >> +++ b/drivers/vfio/vfio_iommu_type1.c
> >> @@ -37,6 +37,7 @@
> >> #include <linux/vfio.h>
> >> #include <linux/workqueue.h>
> >> #include <linux/dma-iommu.h>
> >> +#include <linux/irqdomain.h>
> >>
> >> #define DRIVER_VERSION "0.2"
> >> #define DRIVER_AUTHOR "Alex Williamson
> <alex.williamson@redhat.com <mailto:alex.williamson@redhat.com>>"
> >> @@ -765,7 +766,7 @@ static int vfio_iommu_type1_attach_group(void
> *iommu_data,
> >> struct vfio_domain *domain, *d;
> >> struct bus_type *bus = NULL;
> >> int ret;
> >> - bool resv_msi;
> >> + bool resv_msi, msi_remap;
> >> phys_addr_t resv_msi_base;
> >>
> >> mutex_lock(&iommu->lock);
> >> @@ -818,8 +819,10 @@ static int
> vfio_iommu_type1_attach_group(void *iommu_data,
> >> INIT_LIST_HEAD(&domain->group_list);
> >> list_add(&group->next, &domain->group_list);
> >>
> >> - if (!allow_unsafe_interrupts &&
> >> - !iommu_capable(bus, IOMMU_CAP_INTR_REMAP)) {
> >> + msi_remap = resv_msi ? irq_domain_check_msi_remap() :
> >> + iommu_capable(bus, IOMMU_CAP_INTR_REMAP);
> >> +
> >> + if (!allow_unsafe_interrupts && !msi_remap) {
> >> pr_warn("%s: No interrupt remapping support. Use
> the module param \"allow_unsafe_interrupts\" to enable VFIO IOMMU
> support on this platform\n",
> >> __func__);
> >> ret = -EPERM;
> >
> > I tested your v4.9-reserved-v4 branch on a ITS capable hardware (NXP
> > LS2080), so I did not set allow_unsafe_interrupts. It fails here
> > complaining that the there is no interrupt remapping support. The
> > irq_domain_check_msi_remap function returns false as none of the
> checked
> > domains has the IRQ_DOMAIN_FLAG_MSI_REMAP flag set. I think the reason
> > is that the flags are not propagated through the domain hierarchy when
> > the domain is created.
>
> Hum OK. Please apologize for the inconvenience, all the more so this is
> the second time you report the same issue for different cause :-( At the
> moment I can't test on a GICv3 ITS based system. I will try to fix that
> though.
>
> I would like to get the confirmation introducing this flag is the right
> direction though.
>
> Thanks
>
> Eric
> >
> > Thanks,
> >
> > Diana
> >
> >
> >
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> <mailto:linux-arm-kernel@lists.infradead.org>
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> <http://lists.infradead.org/mailman/listinfo/linux-arm-kernel>
>
>
next prev parent reply other threads:[~2016-12-23 15:13 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-13 20:30 [RFC v4 00/16] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions Eric Auger
2016-12-13 20:30 ` Eric Auger
2016-12-13 20:30 ` Eric Auger
[not found] ` <1481661034-3088-1-git-send-email-eric.auger-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-12-13 20:30 ` [RFC v4 01/16] iommu/dma: Allow MSI-only cookies Eric Auger
2016-12-13 20:30 ` Eric Auger
2016-12-13 20:30 ` [RFC v4 02/16] iommu: Rename iommu_dm_regions into iommu_resv_regions Eric Auger
2016-12-13 20:30 ` Eric Auger
2016-12-13 20:30 ` [RFC v4 03/16] iommu: Add a new type field in iommu_resv_region Eric Auger
2016-12-13 20:30 ` Eric Auger
2016-12-13 20:30 ` [RFC v4 04/16] iommu: iommu_alloc_resv_region Eric Auger
2016-12-13 20:30 ` Eric Auger
2016-12-13 20:30 ` [RFC v4 05/16] iommu: Only map direct mapped regions Eric Auger
2016-12-13 20:30 ` Eric Auger
2016-12-13 20:30 ` [RFC v4 06/16] iommu: iommu_get_group_resv_regions Eric Auger
2016-12-13 20:30 ` Eric Auger
2016-12-13 20:30 ` [RFC v4 07/16] iommu: Implement reserved_regions iommu-group sysfs file Eric Auger
2016-12-13 20:30 ` Eric Auger
2016-12-13 20:30 ` [RFC v4 08/16] iommu/vt-d: Implement reserved region get/put callbacks Eric Auger
2016-12-13 20:30 ` Eric Auger
2016-12-13 20:30 ` [RFC v4 09/16] iommu/arm-smmu: " Eric Auger
2016-12-13 20:30 ` Eric Auger
2016-12-13 20:30 ` [RFC v4 10/16] iommu/arm-smmu-v3: " Eric Auger
2016-12-13 20:30 ` Eric Auger
2016-12-13 20:30 ` [RFC v4 11/16] irqdomain: Add IRQ_DOMAIN_FLAG_MSI_REMAP value Eric Auger
2016-12-13 20:30 ` Eric Auger
2016-12-13 20:30 ` [RFC v4 12/16] irqdomain: irq_domain_check_msi_remap Eric Auger
2016-12-13 20:30 ` Eric Auger
2016-12-13 20:30 ` [RFC v4 13/16] irqchip/gicv3-its: Sets IRQ_DOMAIN_FLAG_MSI_REMAP Eric Auger
2016-12-13 20:30 ` Eric Auger
2016-12-13 20:30 ` [RFC v4 14/16] vfio/type1: Allow transparent MSI IOVA allocation Eric Auger
2016-12-13 20:30 ` Eric Auger
2016-12-13 20:30 ` [RFC v4 15/16] vfio/type1: Check MSI remapping at irq domain level Eric Auger
2016-12-13 20:30 ` Eric Auger
2016-12-22 12:41 ` Diana Madalina Craciun
2016-12-22 12:41 ` Diana Madalina Craciun
2016-12-22 12:41 ` Diana Madalina Craciun
2016-12-22 13:02 ` Auger Eric
2016-12-22 13:02 ` Auger Eric
[not found] ` <3ead0cc1-7798-3e39-da56-c18a5989c00c-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-12-23 13:33 ` Geetha Akula
[not found] ` <CANHdaibH3GCFhM4nXh1KJoFhZCodtWo7KfP7AcSoVD0HwjDWfg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-12-23 15:13 ` Auger Eric [this message]
2016-12-23 15:13 ` Auger Eric
2016-12-23 15:13 ` Auger Eric
2016-12-13 20:30 ` [RFC v4 16/16] iommu/arm-smmu: Do not advertise IOMMU_CAP_INTR_REMAP anymore Eric Auger
2016-12-13 20:30 ` Eric Auger
2016-12-20 4:45 ` [RFC v4 00/16] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions Bharat Bhushan
2016-12-20 4:45 ` Bharat Bhushan
2016-12-20 4:45 ` Bharat Bhushan
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=72057deb-cc71-33f1-e96a-ed2c96a99c3b@redhat.com \
--to=eric.auger-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
--cc=christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=drjones-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=eric.auger.pro-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=geethasowjanya.akula-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=gpkulkarni-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org \
--cc=kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=marc.zyngier-5wv7dgnIgG8@public.gmane.org \
--cc=pranav.sawargaonkar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=punit.agrawal-5wv7dgnIgG8@public.gmane.org \
--cc=shankerd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
--cc=tglx-hfZtesqFncYOwBW4kG4KsQ@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.