From: joro@8bytes.org (Joerg Roedel)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v6 04/20] iommu/arm-smmu: add capability IOMMU_CAP_INTR_REMAP
Date: Mon, 16 Jun 2014 17:21:58 +0200 [thread overview]
Message-ID: <20140616152157.GB31771@8bytes.org> (raw)
In-Reply-To: <20140616151329.GQ16758@arm.com>
On Mon, Jun 16, 2014 at 04:13:29PM +0100, Will Deacon wrote:
> 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?
VFIO does not care about the actual routing, it only cares that the
device can not send interrupts it is not allowed to send (e.g.
interrupts to vectors used by other devices or, on x86, exception vectors).
If that is guaranteed by the SMMU or the GIC ITS hardware and driver
then it is fine to set this flag.
Joerg
next prev parent reply other threads:[~2014-06-16 15:21 UTC|newest]
Thread overview: 24+ 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 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
2014-06-16 15:21 ` Joerg Roedel [this message]
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
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=20140616152157.GB31771@8bytes.org \
--to=joro@8bytes.org \
--cc=linux-arm-kernel@lists.infradead.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).