On Fri, May 13, 2022 at 10:09:46AM +0800, Baolu Lu wrote:
> On 2022/5/13 07:12, Steve Wahl wrote:
> > On Thu, May 12, 2022 at 10:13:09AM -0500, Steve Wahl wrote:
> > > To support up to 64 sockets with 10 DMAR units each (640), make the
> > > value of DMAR_UNITS_SUPPORTED adjustable by a config
On Wed, 2022-05-18 at 16:14 -0300, Jason Gunthorpe wrote:
> On Wed, May 18, 2022 at 02:50:36PM -0400, Eric Farman wrote:
>
> > I got a heads up from Matt about the s390 KVM vfio- variants
> > failing on
> > linux-next.
> >
> > For vfio-ap and vfio-ccw, they fail on the above error. Both calls
>
On Wed, May 18, 2022 at 02:50:36PM -0400, Eric Farman wrote:
> I got a heads up from Matt about the s390 KVM vfio- variants failing on
> linux-next.
>
> For vfio-ap and vfio-ccw, they fail on the above error. Both calls to
> __iommu_domain_alloc fail because while dev->dev->bus is non-NULL (it
>
On Mon, 2022-05-09 at 13:19 -0300, Jason Gunthorpe via iommu wrote:
> Once the group enters 'owned' mode it can never be assigned back to
> the
> default_domain or to a NULL domain. It must always be actively
> assigned to
> a current domain. If the caller hasn't provided a domain then the
> core
On Wed, May 18, 2022 at 11:42:04AM -0700, Jacob Pan wrote:
> > Yes.. It seems inefficient to iterate over that xarray multiple times
> > on the flush hot path, but maybe there is little choice. Try to use
> > use the xas iterators under the xa_lock spinlock..
> >
> xas_for_each takes a max
On Wed, May 18, 2022 at 12:07:58PM +0100, Robin Murphy wrote:
> On 2022-05-18 09:29, AngeloGioacchino Del Regno wrote:
> > Il 17/05/22 16:12, Robin Murphy ha scritto:
> > > On 2022-05-17 14:21, AngeloGioacchino Del Regno wrote:
> > > > This driver will get support for more SoCs and the list of
On Wed, May 18, 2022 at 10:14:43AM +0200, AngeloGioacchino Del Regno wrote:
> Il 18/05/22 03:41, Rob Herring ha scritto:
> > On Tue, May 17, 2022 at 03:21:06PM +0200, AngeloGioacchino Del Regno wrote:
> > > Both MT2712 and MT8173 got a mediatek,infracfg phandle: add that to
> > > the required
On Sat, May 14, 2022 at 09:43:15AM +0800, Lu Baolu wrote:
> Hi folks,
>
> The include/linux/intel-iommu.h should be private to the Intel IOMMU
> driver. Other drivers or components should interact with the IOMMU
> drivers through the kAPIs provided by the iommu core.
>
> This series cleanups all
Hi Jason,
On Wed, 11 May 2022 15:29:08 -0300, Jason Gunthorpe wrote:
> On Wed, May 11, 2022 at 10:25:21AM -0700, Jacob Pan wrote:
> > Hi Jason,
> >
> > On Wed, 11 May 2022 14:00:25 -0300, Jason Gunthorpe
> > wrote:
> > > On Wed, May 11, 2022 at 10:02:16AM -0700, Jacob Pan wrote:
> > > > >
Supervisor PASID for SVA/SVM is no longer supported, delete the unused
flag.
Signed-off-by: Jacob Pan
---
drivers/iommu/intel/svm.c | 2 +-
include/linux/intel-svm.h | 13 -
2 files changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/iommu/intel/svm.c
IOMMU group maintains a PASID array which stores the associated IOMMU
domains. This patch introduces a helper function to do domain to PASID
look up. It will be used by TLB flush and device-PASID attach verification.
Signed-off-by: Jacob Pan
---
drivers/iommu/iommu.c | 22 ++
The current in-kernel supervisor PASID support is based on the SVM/SVA
machinery in SVA lib. The binding between a kernel PASID and kernel
mapping has many flaws. See discussions in the link below.
This patch enables in-kernel DMA by switching from SVA lib to the
standard DMA mapping APIs. Since
DMA mapping API is the de facto standard for in-kernel DMA. It operates
on a per device/RID basis which is not PASID-aware.
Some modern devices such as Intel Data Streaming Accelerator, PASID is
required for certain work submissions. To allow such devices use DMA
mapping API, we need the
Some modern accelerators such as Intel's Data Streaming Accelerator (DSA)
require PASID in DMA requests to be operational. Specifically, the work
submissions with ENQCMD on shared work queues require PASIDs. The use cases
include both user DMA with shared virtual addressing (SVA) and in-kernel
DMA
DMA requests tagged with PASID can target individual IOMMU domains.
Introduce a domain-wide PASID for DMA API, it will be used on the same
mapping as legacy DMA without PASID. Let it be IOVA or PA in case of
identity domain.
Signed-off-by: Jacob Pan
---
include/linux/iommu.h | 2 ++
1 file
On VT-d platforms with scalable mode enabled, devices issue DMA requests
with PASID need to attach PASIDs to given IOMMU domains. The attach
operation involves the following:
- Programming the PASID into the device's PASID table
- Tracking device domain and the PASID relationship
- Managing IOTLB
For devices stuck behind a conventional PCI bus, saving extra cycles at
33MHz is probably fairly significant. However since native PCI Express
is now the norm for high-performance devices, the optimisation to always
prefer 32-bit addresses for the sake of avoiding DAC is starting to look
rather
On Sun, May 15, 2022 at 12:35:44PM +0200, Janne Grunau wrote:
> Hej,
>
> I'm working on the display controller for Apple silicon SoCs and will
> add some comments with support for it in mind.
>
> added as...@lists.linux.dev to CC for the Apple silicon related aspects
>
> On 2022-05-12 21:00:47
On 2022-05-18 14:12, Christoph Hellwig wrote:
On Tue, May 17, 2022 at 11:40:52AM +0100, Robin Murphy wrote:
Indeed, sorry but NAK for this being nonsense. As I've said at least once
before, if the unnecessary SAC address allocation attempt slows down your
workload, make it not do that in the
On Tue, May 17, 2022 at 01:02:00PM +0100, Robin Murphy wrote:
>> So how to inform the SCSI driver of this caching limit then so that it may
>> limit the SGL length?
>
> Driver-specific mechanism; block-layer-specific mechanism; redefine this
> whole API to something like dma_opt_mapping_size(),
On Tue, May 17, 2022 at 11:40:52AM +0100, Robin Murphy wrote:
> Indeed, sorry but NAK for this being nonsense. As I've said at least once
> before, if the unnecessary SAC address allocation attempt slows down your
> workload, make it not do that in the first place. If you don't like the
>
On Sun, May 15, 2022 at 12:45:54PM +0200, Janne Grunau wrote:
> On 2022-05-12 21:00:48 +0200, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > This adds the "iommu-addresses" property to reserved-memory nodes, which
> > allow describing the interaction of memory regions with IOMMUs. Two
On Sun, May 15, 2022 at 01:10:38PM +0200, Janne Grunau wrote:
> On 2022-05-12 21:00:49 +0200, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > This is an implementation that IOMMU drivers can use to obtain reserved
> > memory regions from a device tree node. It uses the reserved-memory DT
Il 18/05/22 13:29, Matthias Brugger ha scritto:
On 18/05/2022 12:04, AngeloGioacchino Del Regno wrote:
Add properties "mediatek,infracfg" and "mediatek,pericfg" to let the
mtk_iommu driver retrieve phandles to the infracfg and pericfg syscon(s)
instead of performing a per-soc compatible
On 18/05/2022 12:04, AngeloGioacchino Del Regno wrote:
Add properties "mediatek,infracfg" and "mediatek,pericfg" to let the
mtk_iommu driver retrieve phandles to the infracfg and pericfg syscon(s)
instead of performing a per-soc compatible lookup.
Signed-off-by: AngeloGioacchino Del Regno
On 2022-05-18 09:29, AngeloGioacchino Del Regno wrote:
Il 17/05/22 16:12, Robin Murphy ha scritto:
On 2022-05-17 14:21, AngeloGioacchino Del Regno wrote:
This driver will get support for more SoCs and the list of infracfg
compatibles is expected to grow: in order to prevent getting this
Add bindings for the MediaTek Helio X10 (MT6795) IOMMU/M4U.
Signed-off-by: AngeloGioacchino Del Regno
---
.../bindings/iommu/mediatek,iommu.yaml| 4 +
include/dt-bindings/memory/mt6795-larb-port.h | 96 +++
2 files changed, 100 insertions(+)
create mode 100644
Add support for the M4Us found in the MT6795 Helio X10 SoC.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/iommu/mtk_iommu.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index
In an effort to give some love to the apparently forgotten MT6795 SoC,
I am upstreaming more components that are necessary to support platforms
powered by this one apart from a simple boot to serial console.
This series introduces support for the IOMMUs found on this SoC.
Tested on a MT6795 Sony
On 17/05/2022 15:21, AngeloGioacchino Del Regno wrote:
On some SoCs (of which only MT8195 is supported at the time of writing),
the "R" and "W" (I/O) enable bits for the IOMMUs are in the pericfg_ao
register space and not in the IOMMU space: as it happened already with
infracfg, it is
Both MT2712 and MT8173 got a mediatek,infracfg phandle: add that to
the required properties for these SoCs to deprecate the old way of
looking for SoC-specific infracfg compatible in the entire devicetree.
Signed-off-by: AngeloGioacchino Del Regno
Acked-by: Rob Herring
---
On some SoCs (of which only MT8195 is supported at the time of writing),
the "R" and "W" (I/O) enable bits for the IOMMUs are in the pericfg_ao
register space and not in the IOMMU space: as it happened already with
infracfg, it is expected that this list will grow.
Instead of specifying pericfg
This driver will get support for more SoCs and the list of infracfg
compatibles is expected to grow: in order to prevent getting this
situation out of control and see a long list of compatible strings,
add support to retrieve a handle to infracfg's regmap through a
new "mediatek,infracfg" phandle.
The IOMMU has registers in the infracfg and/or pericfg iospaces: as
for the currently supported SoCs, MT2712 and MT8173 need a phandle to
infracfg, while MT8195 needs one to pericfg.
Before this change, the driver was checking for a SoC-specific infra/peri
compatible but, sooner or later, these
The IOMMU driver now looks for the "mediatek,infracfg" phandle as a
new way to retrieve a syscon to that:
even though the old way is retained, it has been deprecated and the
driver will write a message in kmsg advertising to use the phandle
way instead.
For this reason, assign the right phandle
The IOMMU driver now looks for the "mediatek,infracfg" phandle as a
new way to retrieve a syscon to that:
even though the old way is retained, it has been deprecated and the
driver will write a message in kmsg advertising to use the phandle
way instead.
For this reason, assign the right phandle
The MT8195 SoC has IOMMU related registers in the pericfg_ao iospace:
require a phandle to that.
Signed-off-by: AngeloGioacchino Del Regno
Acked-by: Rob Herring
---
.../devicetree/bindings/iommu/mediatek,iommu.yaml | 10 ++
1 file changed, 10 insertions(+)
diff --git
Add properties "mediatek,infracfg" and "mediatek,pericfg" to let the
mtk_iommu driver retrieve phandles to the infracfg and pericfg syscon(s)
instead of performing a per-soc compatible lookup.
Signed-off-by: AngeloGioacchino Del Regno
---
.../devicetree/bindings/iommu/mediatek,iommu.yaml
On 17/05/2022 15:21, AngeloGioacchino Del Regno wrote:
Add property "mediatek,infracfg" to let the mtk_iommu driver retrieve
a phandle to the infracfg syscon instead of performing a per-soc
compatible lookup.
Signed-off-by: AngeloGioacchino Del Regno
---
Il 17/05/22 16:12, Robin Murphy ha scritto:
On 2022-05-17 14:21, AngeloGioacchino Del Regno wrote:
This driver will get support for more SoCs and the list of infracfg
compatibles is expected to grow: in order to prevent getting this
situation out of control and see a long list of compatible
Il 18/05/22 03:41, Rob Herring ha scritto:
On Tue, May 17, 2022 at 03:21:06PM +0200, AngeloGioacchino Del Regno wrote:
Both MT2712 and MT8173 got a mediatek,infracfg phandle: add that to
the required properties for these SoCs to deprecate the old way of
looking for SoC-specific infracfg
On 2022/5/17 19:13, Jason Gunthorpe wrote:
On Tue, May 17, 2022 at 10:05:43AM +0800, Baolu Lu wrote:
Hi Jason,
On 2022/5/17 02:06, Jason Gunthorpe wrote:
+static __init int tboot_force_iommu(void)
+{
+ if (!tboot_enabled())
+ return 0;
+
+ if (no_iommu ||
On 2022/5/17 21:13, Jason Gunthorpe wrote:
On Tue, May 17, 2022 at 01:43:03PM +0100, Robin Murphy wrote:
FWIW from my point of view I'm happy with having a .detach_dev_pasid op
meaning implicitly-blocked access for now.
If this is the path then lets not call it attach/detach
please.
43 matches
Mail list logo
