From: will.deacon@arm•com (Will Deacon)
To: linux-arm-kernel@lists•infradead.org
Subject: [RFC PATCH v6 04/20] iommu/arm-smmu: add capability IOMMU_CAP_INTR_REMAP
Date: Fri, 27 Jun 2014 09:47:22 +0100 [thread overview]
Message-ID: <20140627084722.GB26276@arm.com> (raw)
In-Reply-To: <1403811384.31091.151.camel@ul30vt.home>
On Thu, Jun 26, 2014 at 08:36:24PM +0100, Alex Williamson wrote:
> On Thu, 2014-06-26 at 19:10 +0000, Chalamarla, Tirumalesh wrote:
> > Thanks for the clarification Alex, That?s exactly my point, why are we
> > relying on QEMU or something else to emulate the MSI space when we can
> > directly give access to devices using ITS (of course with a small
> > emulation code). This way we are also benefited from all ITS services
> > like VCPU migration etc.
>
> I have no idea what ITS is.
ITS is the MSI doorbell for GICv3 (ARM's latest interrupt controller).
I agree that we will need an ITS emulation if we want to use MSIs in the
guest, and I believe that Marc (CC'd) had already started thinking about
that.
> > What about non QEMU VFIO users, for example, if I wanted to use VFIO to
> > assign a device to a user process I don't need to depend on QEMU. I
> > thought this is one of the main goals of vfio to make it independent of
> > hypervisors.
>
> Where did QEMU become a requirement? Maybe I'm missing something in the
> ARM part of the conversation that got chopped off, but this is exactly
> why we have the VFIO/QEMU split that we do. VFIO provides basic
> virtualization for config space and restricts access to other areas that
> users shouldn't be allowed to change. QEMU is just one example of a
> userspace VFIO driver. QEMU takes the decomposed device exposed through
> the VFIO ABI and re-creates a PCI device out of it. VFIO itself has no
> dependency on QEMU. Thanks,
I also don't understand the QEMU part here. The MSI emulation would be in
the kernel, just like the GICv2 emulation that we already have. For
userspace drivers, wouldn't you just use eventfd rather than bother with
emulating MSIs?
Finally, the interrupt remapping part is about the SMMU preventing MSI
writes to arbitrary portions of the host address space. The ITS is about
routing interrupts to CPUs.
Will
next prev parent reply other threads:[~2014-06-27 8:47 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
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 [this message]
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=20140627084722.GB26276@arm.com \
--to=will.deacon@arm$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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