linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Will Deacon <will.deacon@arm.com>
To: Joerg Roedel <joro@8bytes.org>
Cc: Christoffer Dall <christoffer.dall@linaro.org>,
	Antonios Motakis <a.motakis@virtualopensystems.com>,
	"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"tech@virtualopensystems.com" <tech@virtualopensystems.com>,
	"a.rigo@virtualopensystems.com" <a.rigo@virtualopensystems.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"kim.phillips@freescale.com" <kim.phillips@freescale.com>,
	"stuart.yoder@freescale.com" <stuart.yoder@freescale.com>,
	"eric.auger@linaro.org" <eric.auger@linaro.org>,
	"moderated list:ARM SMMU DRIVER" 
	<linux-arm-kernel@lists.infradead.org>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH v6 04/20] iommu/arm-smmu: add capability IOMMU_CAP_INTR_REMAP
Date: Mon, 16 Jun 2014 16:13:29 +0100	[thread overview]
Message-ID: <20140616151329.GQ16758@arm.com> (raw)
In-Reply-To: <20140616145344.GD18986@8bytes.org>

On Mon, Jun 16, 2014 at 03:53:44PM +0100, Joerg Roedel wrote:
> On Sun, Jun 08, 2014 at 12:31:29PM +0200, Christoffer Dall wrote:
> > On Thu, Jun 05, 2014 at 07:03:12PM +0200, Antonios Motakis wrote:
> > > With an ARM SMMU, interrupt remapping should always be safe from the
> > > SMMU's point of view, as it is properly handled by the GIC.
> > > 
> > > Signed-off-by: Antonios Motakis <a.motakis@virtualopensystems.com>
> > > ---
> > >  drivers/iommu/arm-smmu.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> > > index 15ab2af..ff29402 100644
> > > --- a/drivers/iommu/arm-smmu.c
> > > +++ b/drivers/iommu/arm-smmu.c
> > > @@ -1544,7 +1544,7 @@ static int arm_smmu_domain_has_cap(struct iommu_domain *domain,
> > >  	if (smmu_domain->root_cfg.smmu->features & ARM_SMMU_FEAT_COHERENT_WALK)
> > >  		caps |= IOMMU_CAP_CACHE_COHERENCY;
> > >  
> > > -	caps |= IOMMU_CAP_NOEXEC;
> > > +	caps |= IOMMU_CAP_NOEXEC | IOMMU_CAP_INTR_REMAP;
> > >  
> > >  	return !!(cap & caps);
> > >  }
> > > -- 
> > > 1.8.3.2
> > > 
> > What does IOMMU_CAP_INTR_REMAP signify exactly?  Is there docs/examples
> > somewhere I can look at?  (A quick scan of the Linux souce code doesn't
> > reveal much, and I'm not sure if this is purely MSI related or what...)
> 
> The flag was introduced for x86 IOMMUs to detect whether an IOMMU in the
> system has and enables interrupt remapping to allow safe device
> assignment to KVM guests. Without interrupt remapping a malicious guest
> could attack the host with MSIs from the attached device.
> 
> How are PCI MSIs implemented on ARM with SMMU and GIC enabled. MSIs are
> only memory dma transactions in the end, is it guaranteed on ARM that a
> device only sends MSI transactions it is allowed to?

MSIs look just like memory accesses made by the device, so the SMMU will
translate them to point at the GIC ITS (doorbell). The ITS then has tables
to work out how to route the MSI.

So, if IOMMU_CAP_INTR_REMAP is simply supposed to indicate that the SMMU can
translate MSIs to point somewhere else, then the ARM SMMU can always do it.
If it's supposed to indicate that the actual MSI payload can be
filtered/routed, then that requires the GIC ITS.

The part I'm unsure of is how VFIO knows where to map the MSIs to. That
requires knowledge of the physical and virtual doorbell pages -- is that
discoverable in the API?

Will

  reply	other threads:[~2014-06-16 15:13 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1401987808-23596-1-git-send-email-a.motakis@virtualopensystems.com>
2014-06-05 17:03 ` [RFC PATCH v6 01/20] iommu/arm-smmu: change IOMMU_EXEC to IOMMU_NOEXEC Antonios Motakis
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 20:03   ` Alex Williamson
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-16 15:04   ` Will Deacon
2014-06-16 15:25     ` Alex Williamson
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 18:31   ` Varun Sethi
2014-06-08 10:31   ` Christoffer Dall
2014-06-16 14:53     ` Joerg Roedel
2014-06-16 15:13       ` Will Deacon [this message]
2014-06-16 15:21         ` Joerg Roedel
2014-06-16 15:25           ` Will Deacon
2014-06-16 15:38             ` Joerg Roedel
2014-06-26 18:08               ` Chalamarla, Tirumalesh
2014-06-26 18:15                 ` Chalamarla, Tirumalesh
2014-06-26 18:41                   ` Chalamarla, Tirumalesh
2014-06-26 19:00                     ` Alex Williamson
2014-06-26 19:10                       ` Chalamarla, Tirumalesh
2014-06-26 19:36                         ` Alex Williamson
2014-06-27  8:47                           ` Will Deacon
2014-06-27 21:57                             ` Chalamarla, Tirumalesh
2014-06-28  7:05                               ` Marc Zyngier
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 ` [RFC PATCH v6 06/20] vfio: introduce the VFIO_DMA_MAP_FLAG_NOEXEC flag Antonios Motakis
2014-06-05 17:03 ` [RFC PATCH v6 07/20] vfio/iommu_type1: implement " Antonios Motakis
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 ` [RFC PATCH v6 09/20] vfio/platform: initial skeleton of VFIO support for platform devices 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 21:14   ` Alex Williamson
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 ` [RFC PATCH v6 12/20] vfio/platform: support MMAP of MMIO regions Antonios Motakis
2014-06-05 17:03 ` [RFC PATCH v6 13/20] vfio/platform: return IRQ info Antonios Motakis
2014-06-05 17:03 ` [RFC PATCH v6 14/20] vfio/platform: initial interrupts support Antonios Motakis
2014-06-08 10:09   ` Christoffer Dall
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-08 10:17   ` Christoffer Dall
2014-09-02 16:06     ` Antonios Motakis
2014-09-10 10:13       ` Christoffer Dall
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 ` [RFC PATCH v6 17/20] vfio: add local lock in virqfd instead of depending on VFIO PCI Antonios Motakis
2014-06-05 22:19   ` Alex Williamson
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 ` [RFC PATCH v6 19/20] vfio: initialize the virqfd workqueue in VFIO generic code Antonios Motakis
2014-06-05 17:03 ` [RFC PATCH v6 20/20] vfio/platform: implement IRQ masking/unmasking via an eventfd 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=20140616151329.GQ16758@arm.com \
    --to=will.deacon@arm.com \
    --cc=a.motakis@virtualopensystems.com \
    --cc=a.rigo@virtualopensystems.com \
    --cc=alex.williamson@redhat.com \
    --cc=christoffer.dall@linaro.org \
    --cc=eric.auger@linaro.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=kim.phillips@freescale.com \
    --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=stuart.yoder@freescale.com \
    --cc=tech@virtualopensystems.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).