On 2022/5/4 0:33, Shameer Kolothum wrote:
Hi
v11 --> v12
-Minor fix in patch #4 to address the issue reported by the kernel test
robot.
-Added R-by tags by Christoph(patch #1) and Lorenzo(patch #4).
-Added T-by from Steve to all relevant patches. Many thanks!.
Please note, this
On 2022/5/4 0:33, Shameer Kolothum wrote:
This will provide a way for SMMU drivers to retrieve StreamIDs
associated with IORT RMR nodes and use that to set bypass settings
for those IDs.
Tested-by: Steven Price
Signed-off-by: Shameer Kolothum
Reviewed-by: Hanjun Guo
Thanks
Hanjun
On 2022/5/4 0:33, Shameer Kolothum wrote:
Parse through the IORT RMR nodes and populate the reserve region list
corresponding to a given IOMMU and device(optional). Also, go through
the ID mappings of the RMR node and retrieve all the SIDs associated
with it.
Reviewed-by: Lorenzo Pieralisi
As enforce_cache_coherency has been introduced into the iommu_domain_ops,
the kernel component which owns the iommu domain is able to opt-in its
requirement for force snooping support. The iommu driver has no need to
hard code the page snoop control bit in the PASID table entries anymore.
The IOMMU force snooping capability is not required to be consistent
among all the IOMMUs anymore. Remove force snooping capability check
in the IOMMU hot-add path and domain_update_iommu_snooping() becomes
a dead code now.
Signed-off-by: Lu Baolu
Reviewed-by: Jason Gunthorpe
---
As domain->force_snooping only impacts the devices attached with the
domain, there's no need to check against all IOMMU units. At the same
time, for a brand new domain (hasn't been attached to any device), the
force_snooping field could be set, but the attach_dev callback will
return failure if it
In the attach_dev callback of the default domain ops, if the domain has
been set force_snooping, but the iommu hardware of the device does not
support SC(Snoop Control) capability, the callback should block it and
return a corresponding error code.
Signed-off-by: Lu Baolu
Reviewed-by: Jason
Hi folks,
Previously, the IOMMU capability of enforcing cache coherency was queried
through iommu_capable(IOMMU_CAP_CACHE_COHERENCY). This is a global
capability, hence the IOMMU driver reports support for this capability
only when all IOMMUs in the system has this support.
Commit 6043257b1de06
On 2022/5/4 0:33, Shameer Kolothum wrote:
Currently IORT provides a helper to retrieve HW MSI reserve regions.
Change this to a generic helper to retrieve any IORT related reserve
regions. This will be useful when we add support for RMR nodes in
subsequent patches.
[Lorenzo: For ACPI IORT]
On 2022/5/4 0:33, Shameer Kolothum wrote:
At present iort_iommu_msi_get_resv_regions() returns the number of
MSI reserved regions on success and there are no users for this.
The reserved region list will get populated anyway for platforms
that require the HW MSI region reservation. Hence, change
On Mon, May 02, 2022 at 03:34:54PM +0200, Geert Uytterhoeven wrote:
> Despite the name, R-Car V3U is the first member of the R-Car Gen4
> family. I2C on R-Car V3U also supports some extra features (e.g. Slave
> Clock Stretch Select), which are supported by other R-Car Gen4 SoCs, but
> not by any
On Mon, May 02, 2022 at 03:34:59PM +0200, Geert Uytterhoeven wrote:
> Despite the name, R-Car V3U is the first member of the R-Car Gen4
> family. Hence move its compatible value to the R-Car Gen4 section.
>
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Wolfram Sang
signature.asc
On Mon, May 02, 2022 at 03:34:58PM +0200, Geert Uytterhoeven wrote:
> Despite the name, R-Car V3U is the first member of the R-Car Gen4
> family. Hence move its compatible value to the R-Car Gen4 section.
>
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Wolfram Sang
signature.asc
On Mon, May 02, 2022 at 03:34:57PM +0200, Geert Uytterhoeven wrote:
> Despite the name, R-Car V3U is the first member of the R-Car Gen4
> family. Hence move its compatible value to the R-Car Gen4 section.
>
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Wolfram Sang
signature.asc
On Mon, May 02, 2022 at 03:34:55PM +0200, Geert Uytterhoeven wrote:
> Despite the name, R-Car V3U is the first member of the R-Car Gen4
> family. Hence move its compatible value to the R-Car Gen4 section.
>
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Wolfram Sang
signature.asc
On Mon, May 02, 2022 at 03:34:54PM +0200, Geert Uytterhoeven wrote:
> Despite the name, R-Car V3U is the first member of the R-Car Gen4
> family. I2C on R-Car V3U also supports some extra features (e.g. Slave
> Clock Stretch Select), which are supported by other R-Car Gen4 SoCs, but
> not by any
On Mon, May 02, 2022 at 03:34:53PM +0200, Geert Uytterhoeven wrote:
> Despite the name, R-Car V3U is the first member of the R-Car Gen4
> family. Hence move its compatible value to the R-Car Gen4 section.
>
> Signed-off-by: Geert Uytterhoeven
> ---
Reviewed-by: Wolfram Sang
signature.asc
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
must provide an explicit DMA blocking domain that has no DMA map.
Lazily create
The pull request you sent on Wed, 4 May 2022 17:57:47 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
> tags/iomm-fixes-v5.18-rc5
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a7391ad3572431a354c927cf8896e86e50d7d0bf
Thank you!
--
On Wed, May 04, 2022 at 04:29:24PM +0100, Robin Murphy wrote:
> On 2022-05-04 15:54, Jason Gunthorpe wrote:
> > On Wed, May 04, 2022 at 03:42:09PM +0100, Robin Murphy wrote:
> >
> > > > This fixes an oops with VFIO and SMMUv3 because VFIO will call
> > > > iommu_detach_group() and then
On Wed, 4 May 2022 10:42:07 +0200
Joerg Roedel wrote:
> On Mon, May 02, 2022 at 12:12:04PM -0400, Qian Cai wrote:
> > Reverting this series fixed an user-after-free while doing SR-IOV.
> >
> > BUG: KASAN: use-after-free in __lock_acquire
>
> Hrm, okay. I am going exclude this series from my
Hi Linus,
The following changes since commit af2d861d4cd2a4da5137f795ee3509e6f944a25b:
Linux 5.18-rc4 (2022-04-24 14:51:22 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
tags/iomm-fixes-v5.18-rc5
for you to fetch changes up to
On 2022-05-04 15:54, Jason Gunthorpe wrote:
On Wed, May 04, 2022 at 03:42:09PM +0100, Robin Murphy wrote:
This fixes an oops with VFIO and SMMUv3 because VFIO will call
iommu_detach_group() and then immediately iommu_domain_free(), but
SMMUv3 has no way to know that the domain it is holding a
On 03/05/2022 18:34, Bjorn Andersson wrote:
> Add compatible for the Qualcomm SC8280XP platform to the ARM SMMU
> DeviceTree binding.
>
> Signed-off-by: Bjorn Andersson
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
___
iommu mailing list
On Wed, May 04, 2022 at 10:55:00PM +0800, Baolu Lu wrote:
> On 2022/5/4 22:38, Jason Gunthorpe wrote:
> > > @@ -3180,7 +3181,9 @@ int iommu_group_claim_dma_owner(struct iommu_group
> > > *group, void *owner)
> > > ret = -EPERM;
> > > goto unlock_out;
> > >
On 2022/5/4 22:38, Jason Gunthorpe wrote:
@@ -3180,7 +3181,9 @@ int iommu_group_claim_dma_owner(struct iommu_group
*group, void *owner)
ret = -EPERM;
goto unlock_out;
} else {
- if (group->domain && group->domain != group->default_domain)
On Wed, May 04, 2022 at 03:42:09PM +0100, Robin Murphy wrote:
> > This fixes an oops with VFIO and SMMUv3 because VFIO will call
> > iommu_detach_group() and then immediately iommu_domain_free(), but
> > SMMUv3 has no way to know that the domain it is holding a pointer to
> > has been freed. Now
On 2022-05-04 01:11, Jason Gunthorpe 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
must provide an explicit DMA
On Wed, May 04, 2022 at 10:35:12PM +0800, Baolu Lu wrote:
> With below additional changes, this patch works on my Intel test
> machine.
Thanks!
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 513da82f2ed1..7c415e9b6906 100644
> +++ b/drivers/iommu/iommu.c
> @@ -2063,7
On 2022/5/4 21:31, Jason Gunthorpe wrote:
On Wed, May 04, 2022 at 03:25:50PM +0800, Baolu Lu wrote:
Hi Jason,
On 2022/5/2 21:05, Jason Gunthorpe wrote:
On Sun, May 01, 2022 at 07:24:31PM +0800, Lu Baolu wrote:
The SNP bit is only valid for second-level PTEs. Setting this bit in the
Hi Jason,
On 2022/5/4 08:11, Jason Gunthorpe 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
must provide an explicit
On 5/3/2022 7:33 PM, Shameer Kolothum wrote:
Hi
v11 --> v12
-Minor fix in patch #4 to address the issue reported by the kernel test
robot.
-Added R-by tags by Christoph(patch #1) and Lorenzo(patch #4).
-Added T-by from Steve to all relevant patches. Many thanks!.
Tested on a NXP
On Wed, May 04, 2022 at 03:25:50PM +0800, Baolu Lu wrote:
> Hi Jason,
>
> On 2022/5/2 21:05, Jason Gunthorpe wrote:
> > On Sun, May 01, 2022 at 07:24:31PM +0800, Lu Baolu wrote:
> > > The SNP bit is only valid for second-level PTEs. Setting this bit in the
> > > first-level PTEs has no functional
On Wed, May 04, 2022 at 01:39:58PM +0100, Robin Murphy wrote:
> Groups created by VFIO backends outside the core IOMMU API should never
> be passed directly into the API itself, however they still expose their
> standard sysfs attributes, so we can still stumble across them that way.
> Take care
Groups created by VFIO backends outside the core IOMMU API should never
be passed directly into the API itself, however they still expose their
standard sysfs attributes, so we can still stumble across them that way.
Take care to consider those cases before jumping into our normal
assumptions of a
On Wed, May 04, 2022 at 12:14:07PM +0100, Robin Murphy wrote:
> On 2022-05-04 08:53, Jan Stancek wrote:
> [...]
> > Hi,
> >
> > I'm getting panics after hunk above was applied in this patch
> > on ppc64le KVM guest, dev->iommu is NULL.
>
> Oof, this can probably be hit with vfio-noiommu too, and
On Wed, May 4, 2022 at 1:14 PM Robin Murphy wrote:
>
> On 2022-05-04 08:53, Jan Stancek wrote:
> [...]
> > Hi,
> >
> > I'm getting panics after hunk above was applied in this patch
> > on ppc64le KVM guest, dev->iommu is NULL.
>
> Oof, this can probably be hit with vfio-noiommu too, and by the
On Wed, May 04, 2022 at 01:22:00AM -0700, Nicolin Chen wrote:
> I am able to repro the issue on ARM64 and give this a quick try.
> But the patch seems to need to include the following change too.
>
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 94d99768023c..9bb108d01baa
On Wed, May 04, 2022 at 08:51:35AM -0300, Jason Gunthorpe wrote:
> Nicolin and Eric have been testing with this series on ARM for a long
> time now, it is not like it is completely broken.
Yeah, I am also optimistic this can be fixed soon. But the rule is that
the next branch should only contain
Hi Robin,
On Wed, May 04, 2022 at 12:14:07PM +0100, Robin Murphy wrote:
> Oof, this can probably be hit with vfio-noiommu too, and by the look of
> things, `echo auto > /sys/kernel/iommu_groups/0/type` would likely blow
> up as well. Does the patch below work for you?
Thanks for the quick patch!
On Wed, May 04, 2022 at 07:48:58PM +0800, Baolu Lu wrote:
> > + /*
> > +* New drivers do not implement detach_dev, so changing the domain is
> > +* done by calling attach on the new domain. Drivers should implement
> > +* this so that DMA is always translated by either the new, old,
On 2022-05-04 01:52, Dmitry Osipenko wrote:
On 4/11/22 16:46, Robin Murphy wrote:
@@ -1092,6 +1092,19 @@ static bool host1x_drm_wants_iommu(struct host1x_device
*dev)
struct host1x *host1x = dev_get_drvdata(dev->dev.parent);
struct iommu_domain *domain;
+ /* For starters,
On Wed, May 04, 2022 at 10:42:07AM +0200, Joerg Roedel wrote:
> On Mon, May 02, 2022 at 12:12:04PM -0400, Qian Cai wrote:
> > Reverting this series fixed an user-after-free while doing SR-IOV.
> >
> > BUG: KASAN: use-after-free in __lock_acquire
>
> Hrm, okay. I am going exclude this series from
Hi Jason,
On 2022/5/4 08:11, Jason Gunthorpe wrote:
+static int __iommu_group_attach_domain(struct iommu_group *group,
+ struct iommu_domain *new_domain)
{
int ret;
+ if (group->domain == new_domain)
+ return 0;
+
/*
-
On 2022-05-04 08:53, Jan Stancek wrote:
[...]
Hi,
I'm getting panics after hunk above was applied in this patch
on ppc64le KVM guest, dev->iommu is NULL.
Oof, this can probably be hit with vfio-noiommu too, and by the look of
things, `echo auto > /sys/kernel/iommu_groups/0/type` would likely
On Mon, 2 May 2022 at 10:38, Rohit Agarwal wrote:
>
> Add sdx65 SoC specific compatible string check inside qcom
> 'sdhci-msm' controller driver.
>
> Signed-off-by: Rohit Agarwal
Applied for next, thanks!
Kind regards
Uffe
> ---
> drivers/mmc/host/sdhci-msm.c | 1 +
> 1 file changed, 1
On Mon, 2 May 2022 at 10:38, Rohit Agarwal wrote:
>
> The SDHCI controller on SDX65 is based on MSM SDHCI v5 IP. Hence,
> document the compatible with "qcom,sdhci-msm-v5" as the fallback.
>
> Signed-off-by: Rohit Agarwal
Applied for next, thanks!
Kind regards
Uffe
> ---
>
On Sun, May 01, 2022 at 09:28:23PM +0800, Xiaomeng Tong wrote:
> The bug is here:
> if (!iommu || iommu->dev->of_node != spec->np) {
>
> The list iterator value 'iommu' will *always* be set and non-NULL by
> list_for_each_entry(), so it is incorrect to assume that the iterator
> value will
On 2022/5/2 21:19, Jason Gunthorpe wrote:
On Sun, May 01, 2022 at 07:24:34PM +0800, Lu Baolu wrote:
As enforce_cache_coherency has been introduced into the iommu_domain_ops,
the kernel component which owns the iommu domain is able to opt-in its
requirement for force snooping support. The iommu
On 2022/5/3 05:36, Jacob Pan wrote:
Hi BaoLu,
On Sun, 1 May 2022 19:24:33 +0800, Lu Baolu
wrote:
The IOMMU force snooping capability is not required to be consistent
among all the IOMMUs anymore. Remove force snooping capability check
in the IOMMU hot-add path and
On Mon, May 02, 2022 at 12:12:04PM -0400, Qian Cai wrote:
> Reverting this series fixed an user-after-free while doing SR-IOV.
>
> BUG: KASAN: use-after-free in __lock_acquire
Hrm, okay. I am going exclude this series from my next branch for now
until this has been sorted out.
Alex, I suggest
On Tue, May 03, 2022 at 03:13:51PM +0800, Yong Wu wrote:
> Yong Wu (36):
> dt-bindings: mediatek: mt8195: Add binding for MM IOMMU
> dt-bindings: mediatek: mt8195: Add binding for infra IOMMU
> dt-bindings: mediatek: mt8186: Add binding for MM iommu
> iommu/mediatek: Fix 2 HW sharing
On Mon, May 02, 2022 at 03:34:55PM +0200, Geert Uytterhoeven wrote:
> Despite the name, R-Car V3U is the first member of the R-Car Gen4
> family. Hence move its compatible value to the R-Car Gen4 section.
>
> Signed-off-by: Geert Uytterhoeven
> ---
>
On Mon, May 02, 2022 at 06:22:38PM +0900, Hector Martin wrote:
> This is required to make loading this as a module work.
>
> Signed-off-by: Hector Martin
> ---
> drivers/iommu/apple-dart.c | 1 +
> 1 file changed, 1 insertion(+)
Applied for v5.18, thanks.
On Tue, May 03, 2022 at 09:11:02PM -0300, Jason Gunthorpe wrote:
> This is based on Robins draft here:
>
> https://lore.kernel.org/linux-iommu/18831161-473f-e04f-4a81-1c7062ad1...@arm.com/
>
> With some rework. I re-organized the call chains instead of introducing
> iommu_group_user_attached(),
On Wed, Feb 16, 2022 at 10:52:47AM +0800, Lu Baolu wrote:
The common iommu_ops is hooked to both device and domain. When a helper
has both device and domain pointer, the way to get the iommu_ops looks
messy in iommu core. This sorts out the way to get iommu_ops. The device
related helpers go
On 2022/5/3 05:31, Jacob Pan wrote:
Hi BaoLu,
Hi Jacob,
On Sun, 1 May 2022 19:24:32 +0800, Lu Baolu
wrote:
As domain->force_snooping only impacts the devices attached with the
domain, there's no need to check against all IOMMU units. At the same
time, for a brand new domain (hasn't been
On 2022/5/2 21:17, Jason Gunthorpe wrote:
On Sun, May 01, 2022 at 07:24:32PM +0800, Lu Baolu wrote:
+static bool domain_support_force_snooping(struct dmar_domain *domain)
+{
+ struct device_domain_info *info;
+ unsigned long flags;
+ bool support = true;
+
+
Hi Jason,
On 2022/5/2 21:05, Jason Gunthorpe wrote:
On Sun, May 01, 2022 at 07:24:31PM +0800, Lu Baolu wrote:
The SNP bit is only valid for second-level PTEs. Setting this bit in the
first-level PTEs has no functional impact because the Intel IOMMU always
ignores the same bit in first-level
59 matches
Mail list logo
