From: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
To: "Isaac J. Manjarres" <isaacm@codeaurora.org>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org, iommu@lists.linux-foundation.org,
linux-arm-kernel@lists.infradead.org
Cc: kernel-team@android.com, robin.murphy@arm.com, joro@8bytes.org,
will.deacon@arm.com, lmark@codeaurora.org, robh+dt@kernel.org,
bhelgaas@google.com, frowand.list@gmail.com,
pratikp@codeaurora.org
Subject: Re: [RFC/PATCH 0/4] Initial support for modular IOMMU drivers
Date: Tue, 21 May 2019 17:07:18 +0100 [thread overview]
Message-ID: <2379c1cf-be1b-503f-7dbc-51110650e91f@arm.com> (raw)
In-Reply-To: <1558118857-16912-1-git-send-email-isaacm@codeaurora.org>
Hi Isaac,
On 17/05/2019 19:47, Isaac J. Manjarres wrote:
> This series adds initial support for being able to use the ARM
> SMMU driver as a loadable kernel module. The series also adds
> to the IOMMU framework, so that it can defer probing for devices
> that depend on an IOMMU driver that may be a loadable module.
>
> The primary reason behind these changes is that having the ARM
> SMMU driver as a module allows for the same kernel image to be
> used across different platforms. For example, if one platform
> contains an IOMMU that implements one version of the ARM SMMU
> specification, and another platform simply does not have an
> IOMMU, the only way that these platforms can share the same
> kernel image is if the ARM SMMU driver is compiled into the
> kernel image.
>
> This solution is not scalable, as it will lead to bloating the
> kernel image with support for several future versions of the
> SMMU specification to maintain a common kernel image that works
> across all platforms. Having the ARM SMMU driver as a module allows
> for a common kernel image to be supported across all platforms,
> while yielding a smaller kernel image size, since the correct
> SMMU driver can be loaded at runtime, if necessary.
It can also be useful if IOMMU drivers want to rely on components that
distros usually build as modules. I have that problem with virtio-iommu,
where the whole virtio transport is usually modular.
> Patchset Summary:
>
> 1. Since the ARM SMMU driver depends on symbols being exported from
> several subsystems, the first three patches are dedicated to exporting
> the necessary symbols.
>
> 2. Similar to how the pinctrl framework handles deferring probes,
> the subsequent patch makes it so that the IOMMU framework will defer
> probes indefinitely if there is a chance that the IOMMU driver that a
> device is waiting for is a module. Otherwise, it upholds the current
> behavior of stopping probe deferrals once all of the builtin drivers
> have finished probing.
>
> The ARM SMMU driver currently has support for the deprecated
> "mmu-masters" binding, which relies on the notion of initcall
> ordering for setting the bus ops to ensure that all SMMU devices
> have been bound to the driver. This poses a problem with
> making the driver a module, as there is no such notion with
> loadable modules. Will support for this be completely deprecated?
> If not, might it be useful to leverage the device tree ordering,
> and assign a property to the last SMMU device, and set the bus ops
> at that point? Or perhaps have some deferred timer based approach
> to know when to set the bus ops?
Another problem is module unloading: if the user calls rmmod on an IOMMU
module, we have to ensure that endpoints aren't performing DMA anymore.
It could be solved by declaring consumers of an IOMMU with
device_link_add(), so that device drivers are unbound before the IOMMU
module is unloaded.
Thanks,
Jean
>
> Thanks,
> Isaac
>
> Isaac J. Manjarres (4):
> of: Export of_phandle_iterator_args() to modules
> PCI: Export PCI ACS and DMA searching functions to modules
> iommu: Export core IOMMU functions to kernel modules
> iommu: Add probe deferral support for IOMMU kernel modules
>
> drivers/iommu/iommu-sysfs.c | 3 +++
> drivers/iommu/iommu.c | 6 ++++++
> drivers/iommu/of_iommu.c | 8 ++++++--
> drivers/of/base.c | 1 +
> drivers/pci/pci.c | 1 +
> drivers/pci/search.c | 1 +
> 6 files changed, 18 insertions(+), 2 deletions(-)
>
next prev parent reply other threads:[~2019-05-21 16:07 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-17 18:47 [RFC/PATCH 0/4] Initial support for modular IOMMU drivers Isaac J. Manjarres
2019-05-17 18:47 ` [RFC/PATCH 1/4] of: Export of_phandle_iterator_args() to modules Isaac J. Manjarres
2019-05-17 22:06 ` Rob Herring
2019-05-17 18:47 ` [RFC/PATCH 2/4] PCI: Export PCI ACS and DMA searching functions " Isaac J. Manjarres
2019-05-22 21:00 ` Bjorn Helgaas
2019-05-17 18:47 ` [RFC/PATCH 3/4] iommu: Export core IOMMU functions to kernel modules Isaac J. Manjarres
2019-05-17 18:47 ` [RFC/PATCH 4/4] iommu: Add probe deferral support for IOMMU " Isaac J. Manjarres
2019-05-21 16:07 ` Jean-Philippe Brucker [this message]
2019-05-21 16:08 ` [RFC/PATCH 0/4] Initial support for modular IOMMU drivers Robin Murphy
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=2379c1cf-be1b-503f-7dbc-51110650e91f@arm.com \
--to=jean-philippe.brucker@arm.com \
--cc=bhelgaas@google.com \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=iommu@lists.linux-foundation.org \
--cc=isaacm@codeaurora.org \
--cc=joro@8bytes.org \
--cc=kernel-team@android.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lmark@codeaurora.org \
--cc=pratikp@codeaurora.org \
--cc=robh+dt@kernel.org \
--cc=robin.murphy@arm.com \
--cc=will.deacon@arm.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).