On Wed, Jun 01, 2022 at 12:07:03AM -0700, Saravana Kannan wrote:
> Now that deferred_probe_timeout is non-zero by default, fw_devlink will
> never permanently block the probing of devices. It'll try its best to
> probe the devices in the right order and then finally let devices probe
> even if
On 2022-06-22 02:36, Baolu Lu wrote:
On 2022/6/21 23:14, Robin Murphy wrote:
Since .release_device is now called through per-device ops, any call
which gets as far as a driver definitely*is* for that driver, for a
device which has successfully passed .probe_device, so all the checks to
that
: arm64-randconfig-r021-20220622
(https://download.01.org/0day-ci/archive/20220622/202206221557.laes8ynq-...@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project
8b8d126598ce7bd5243da7f94f69fa1104288bee)
reproduce (this is a W=1 build):
wget
https
On Wed, Jun 22, 2022 at 04:14:45PM +0800, Zhangfei Gao wrote:
> Hi, Greg
>
> On 2022/6/21 下午3:44, Greg Kroah-Hartman wrote:
> > On Tue, Jun 21, 2022 at 03:37:31PM +0800, Zhangfei Gao wrote:
> > >
> > > On 2022/6/20 下午9:36, Greg Kroah-Hartman wrote:
> > > > On Mon, Jun 20, 2022 at 02:24:31PM
I'd really like to hear something from the driver maintainers. The
cod change itself looks fine, we just need to make sure it does not
break any driver assumptions.
And I think at least for the PCIe P2P and NTB cases I fear it might
break them. The proper logic for those is in the p2p helpers,
On 2022-06-16 02:55, Suravee Suthikulpanit wrote:
From: Brijesh Singh
To support SNP, IOMMU needs to be enabled, and prohibits IOMMU
configurations where DTE[Mode]=0, which means it cannot be supported with
IOMMU passthrough domain (a.k.a IOMMU_DOMAIN_IDENTITY),
and when AMD IOMMU driver is
Hi,
在 2022/6/22 12:41, Lu Baolu 写道:
The IOMMU driver shares the pasid table for PCI alias devices. When the
RID2PASID entry of the shared pasid table has been filled by the first
device, the subsequent devices will encounter the "DMAR: Setup RID2PASID
failed" failure as the pasid entry has
On Wed, Jun 22, 2022 at 10:44 AM Linus Walleij wrote:
> On Wed, Jun 22, 2022 at 9:48 AM Sascha Hauer wrote:
...
> > This patch has the effect that console UART devices which have "dmas"
> > properties specified in the device tree get deferred for 10 to 20
> > seconds. This happens on i.MX and
On 2022-06-16 02:55, Suravee Suthikulpanit wrote:
Once SNP is enabled (by executing SNP_INIT command), IOMMU can no longer
support the passthrough domain (i.e. IOMMU_DOMAIN_IDENTITY).
The SNP_INIT command is called early in the boot process, and would fail
if the kernel is configure to default
On 2022-06-16 23:23, Nicolin Chen wrote:
On Thu, Jun 16, 2022 at 06:40:14AM +, Tian, Kevin wrote:
The domain->ops validation was added, as a precaution, for mixed-driver
systems. However, at this moment only one iommu driver is possible. So
remove it.
It's true on a physical platform.
Recap discussion on the other thread.
https://lore.kernel.org/linux-mm/camkat6qorwbaxapacasm0sc9o2uq9zqzb6s1kbkvav2d4tk...@mail.gmail.com/#t
On 6/16/2022 8:55 AM, Suravee Suthikulpanit wrote:
+int amd_iommu_snp_enable(void)
+{
+ /*
+* The SNP support requires that IOMMU must be
On Wed, Jun 22, 2022 at 9:48 AM Sascha Hauer wrote:
> This patch has the effect that console UART devices which have "dmas"
> properties specified in the device tree get deferred for 10 to 20
> seconds. This happens on i.MX and likely on other SoCs as well. On i.MX
> the dma channel is only
On 2022-06-21 20:57, Sam Protsenko wrote:
Hi Marek,
On Fri, 21 Jan 2022 at 14:31, Marek Szyprowski wrote:
[snip]
Well, for starting point the existing exynos-iommu driver is really
enough. I've played a bit with newer Exyos SoCs some time ago. If I
remember right, if you limit the iommu
Hi Joerg,
On 6/7/2022 4:17 PM, Vasant Hegde wrote:
> Hello Joerg,
>
>
> On 5/20/2022 5:42 PM, Vasant Hegde wrote:
>> Joerg,
>>
>>
>> On 5/20/2022 3:33 PM, Joerg Roedel wrote:
>>> Hi Vasant,
>>>
>>> On Fri, May 20, 2022 at 03:25:38PM +0530, Vasant Hegde wrote:
Ping. Did you get a chance to
On 22.06.2022 11:14, Robin Murphy wrote:
> On 2022-06-21 20:57, Sam Protsenko wrote:
>> Hi Marek,
>>
>> On Fri, 21 Jan 2022 at 14:31, Marek Szyprowski
>> wrote:
>>
>> [snip]
>>
>>>
>>> Well, for starting point the existing exynos-iommu driver is really
>>> enough. I've played a bit with newer
Thanks,
this looks pretty good to me. A few comments below:
On Fri, Jun 17, 2022 at 10:47:41AM -0400, Tianyu Lan wrote:
> +/**
> + * struct io_tlb_area - IO TLB memory area descriptor
> + *
> + * This is a single area with a single lock.
> + *
> + * @used:The number of used IO TLB block.
>
On Wed, Jun 22, 2022 at 12:52:02PM +0200, Andy Shevchenko wrote:
> On Wed, Jun 22, 2022 at 10:44 AM Linus Walleij
> wrote:
> > On Wed, Jun 22, 2022 at 9:48 AM Sascha Hauer wrote:
>
> ...
>
> > > This patch has the effect that console UART devices which have "dmas"
> > > properties specified
On 2022/6/22 15:17, Robin Murphy wrote:
On 2022-06-22 02:36, Baolu Lu wrote:
On 2022/6/21 23:14, Robin Murphy wrote:
Since .release_device is now called through per-device ops, any call
which gets as far as a driver definitely*is* for that driver, for a
device which has successfully passed
Use the new interface to check the capabilities for our device
specifically.
Signed-off-by: Robin Murphy
---
drivers/vfio/vfio.c | 2 +-
drivers/vfio/vfio_iommu_type1.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
Since IOMMU groups are mandatory for drivers to support, it stands to
reason that any device which has been successfully be added to a group
must be on a bus supported by that IOMMU driver, and therefore a domain
viable for any device in the group must be viable for all devices in
the group. This
Hi, Greg
On 2022/6/21 下午3:44, Greg Kroah-Hartman wrote:
On Tue, Jun 21, 2022 at 03:37:31PM +0800, Zhangfei Gao wrote:
On 2022/6/20 下午9:36, Greg Kroah-Hartman wrote:
On Mon, Jun 20, 2022 at 02:24:31PM +0100, Jean-Philippe Brucker wrote:
On Fri, Jun 17, 2022 at 02:05:21PM +0800, Zhangfei Gao
From: Joerg Roedel
The IOMMU mailing list will move from lists.linux-foundation.org to
lists.linux.dev. The hard switch of the archive will happen on July
5th, but add the new list now already so that people start using the
list when sending patches.
Signed-off-by: Joerg Roedel
---
Thanks,
I've applied all 4 to the dma-mapping tree for Linux 5.20.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On 6/22/2022 3:35 PM, Robin Murphy wrote:
Overall though, this is way nicer than v1, and it's definitely the right name
in the right place now, thanks! FWIW, with those nits picked one way or another:
Reviewed-by: Robin Murphy
Cheers,
Robin.
Thanks for your review. I'll send out v3 w/
Please re-send with
Robin Murphy
in Cc.
On Mon, May 30, 2022 at 08:07:45PM +0800, yf.w...@mediatek.com wrote:
> From: Yunfei Wang
>
> When many devices share the same iova domain, iommu_dma_init_domain()
> may be called at the same time. The checking of iovad->start_pfn will
> all
On Wed, Jun 22, 2022 at 02:27:57PM +0100, Robin Murphy wrote:
> Apologies, I did spot this before, I've just been tied up with other things
> and dropping everything non-critical on the floor, so didn't get round to
> replying before it slipped my mind again.
>
> In summary, I hate it, but mostly
Hi Joerg,
On 22/06/2022 15:44, Joerg Roedel wrote:
On Thu, Jun 16, 2022 at 01:08:25PM +0200, AngeloGioacchino Del Regno wrote:
AngeloGioacchino Del Regno (5):
dt-bindings: iommu: mediatek: Add mediatek,infracfg phandle
iommu/mediatek: Lookup phandle to retrieve syscon to infracfg
Hi Joerg,
On 22/06/2022 15:44, Joerg Roedel wrote:
On Thu, Jun 16, 2022 at 01:08:25PM +0200, AngeloGioacchino Del Regno wrote:
AngeloGioacchino Del Regno (5):
dt-bindings: iommu: mediatek: Add mediatek,infracfg phandle
iommu/mediatek: Lookup phandle to retrieve syscon to infracfg
The variable (and enum) was removed in commit c6af2aa9ffc9 ("swiotlb:
make the swiotlb_init interface more useful") but the declaration was
left in swiotlb.h. Tidy up by removing the declaration as well.
Signed-off-by: Steven Price
---
include/linux/swiotlb.h | 2 --
1 file changed, 2
On Wed, Jun 22, 2022 at 08:05:12AM -0700, Jerry Snitselaar wrote:
> On Wed, Jun 22, 2022 at 7:52 AM Baolu Lu wrote:
> >
> > On 2022/6/16 02:36, 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 Fri, Jun 17, 2022 at 10:01:07AM +0900, Yoshihiro Shimoda wrote:
> Fix compatible string for R-Car Gen4.
>
> Fixes: ae684caf465b ("iommu/ipmmu-vmsa: Add support for R-Car Gen4")
> Signed-off-by: Yoshihiro Shimoda
> ---
> drivers/iommu/ipmmu-vmsa.c | 2 +-
> 1 file changed, 1 insertion(+), 1
On 2022/6/22 17:09, Ethan Zhao wrote:
在 2022/6/22 12:41, Lu Baolu 写道:
The IOMMU driver shares the pasid table for PCI alias devices. When the
RID2PASID entry of the shared pasid table has been filled by the first
device, the subsequent devices will encounter the "DMAR: Setup RID2PASID
failed"
On Wed, Jun 22, 2022 at 7:52 AM Baolu Lu wrote:
>
> On 2022/6/16 02:36, 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 variable,
> > CONFIG_DMAR_UNITS_SUPPORTED, and make it's default 1024 when
On Thu, Jun 09, 2022 at 04:12:10PM +0100, Robin Murphy wrote:
> firmware bindings by now. Let's be brave and default it to off in the
I don't have an overall good feeling about this, but as you said, let's
be brave. This is applied now to the core branch.
If it causes too much trouble we can
On 2022-06-22 13:46, Joerg Roedel wrote:
Please re-send with
Robin Murphy
in Cc.
Apologies, I did spot this before, I've just been tied up with other
things and dropping everything non-critical on the floor, so didn't get
round to replying before it slipped my mind again.
In
On Thu, Jun 16, 2022 at 10:05:55PM -0400, Bo Liu wrote:
> Use ida_alloc_xxx()/ida_free() instead of
> ida_simple_get()/ida_simple_remove().
> The latter is deprecated and more verbose.
>
> Signed-off-by: Bo Liu
> ---
> drivers/iommu/iommu.c | 6 +++---
> 1 file changed, 3 insertions(+), 3
On Thu, Jun 16, 2022 at 01:08:25PM +0200, AngeloGioacchino Del Regno wrote:
> AngeloGioacchino Del Regno (5):
> dt-bindings: iommu: mediatek: Add mediatek,infracfg phandle
> iommu/mediatek: Lookup phandle to retrieve syscon to infracfg
> arm64: dts: mediatek: mt8173: Add mediatek,infracfg
On Wed, Jun 08, 2022 at 02:16:55AM +, Ke Liu wrote:
> Use ida_alloc()/ida_free() instead of deprecated
> ida_simple_get()/ida_simple_remove().
>
> Signed-off-by: Ke Liu
> Reviewed-by: Jason Gunthorpe
> Signed-off-by: Michael S. Tsirkin
> ---
> v2 subject change to iommu
> ---
>
I will build the next RFC version of 64-bit swiotlb on top of this patch (or
next version of this patch), so that it will render a more finalized view of
32-bt/64-bit plus multiple area.
Thank you very much!
Dongli Zhang
On 6/22/22 3:54 AM, Christoph Hellwig wrote:
> Thanks,
>
> this looks
On 22/06/2022 15:32, Christoph Hellwig wrote:
> On Wed, Jun 22, 2022 at 03:29:52PM +0100, Steven Price wrote:
>> The variable (and enum) was removed in commit c6af2aa9ffc9 ("swiotlb:
>> make the swiotlb_init interface more useful") but the declaration was
>> left in swiotlb.h. Tidy up by removing
On 2022/6/16 02:36, 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 variable,
CONFIG_DMAR_UNITS_SUPPORTED, and make it's default 1024 when MAXSMP is
set.
If the available hardware exceeds
On 2022-06-22 13:59, Joerg Roedel wrote:
On Thu, Jun 09, 2022 at 04:12:10PM +0100, Robin Murphy wrote:
firmware bindings by now. Let's be brave and default it to off in the
I don't have an overall good feeling about this, but as you said, let's
be brave. This is applied now to the core
On Wed, Jun 22, 2022 at 03:29:52PM +0100, Steven Price wrote:
> The variable (and enum) was removed in commit c6af2aa9ffc9 ("swiotlb:
> make the swiotlb_init interface more useful") but the declaration was
> left in swiotlb.h. Tidy up by removing the declaration as well.
>
> Signed-off-by: Steven
The function check_feature_on_all_iommus() checks to ensure if an IOMMU
feature support bit is set on the Extended Feature Register (EFR).
Current logic iterates through all IOMMU, and returns false when it
found the first unset bit.
To provide more thorough checking, modify the logic to iterate
The ACPI IVRS table can contain multiple IVHD blocks. Each block contains
information used to initialize each IOMMU instance.
Currently, init_iommu_all sequentially process IVHD block and initialize
IOMMU instance one-by-one. However, certain features require all IOMMUs
to be configured in the
From: Brijesh Singh
To support SNP, IOMMU needs to be enabled, and prohibits IOMMU
configurations where DTE[Mode]=0, which means it cannot be supported with
IOMMU passthrough domain (a.k.a IOMMU_DOMAIN_IDENTITY),
and when AMD IOMMU driver is configured to not use the IOMMU host (v1) page
table.
On AMD system with SNP enabled, IOMMU hardware checks the host translation
valid (TV) and guest translation valid (GV) bits in the device table entry
(DTE) before accessing the corresponded page tables.
However, current IOMMU driver sets the TV bit for all devices regardless
of whether the host
SNP-enabled system requires IOMMU v1 page table to be configured with
non-zero DTE[Mode] for DMA-capable devices. This effects a number of
usecases such as IOMMU pass-through mode and AMD IOMMUv2 APIs for
binding/unbinding pasid.
The series introduce a global variable to check SNP-enabled state
Once SNP is enabled (by executing SNP_INIT command), IOMMU can no longer
support the passthrough domain (i.e. IOMMU_DOMAIN_IDENTITY).
The SNP_INIT command is called early in the boot process, and would fail
if the kernel is configure to default to passthrough mode.
After the system is already
EFR[SNPSup] needs to be checked early in the boot process, since it is
used to determine how IOMMU driver configures other IOMMU features
and data structures. This check can be done as soon as the IOMMU driver
finishes parsing IVHDs.
Introduce a variable for tracking the SNP support status, which
The IOMMUv2 APIs (for supporting shared virtual memory with PASID)
configures the domain with IOMMU v2 page table, and sets DTE[Mode]=0.
This configuration cannot be supported on SNP-enabled system.
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu/amd/init.c | 7 ++-
1 file changed, 6
On Sat, Apr 23, 2022 at 07:46:50PM +0200, Christoph Hellwig wrote:
> Sigh. In theory drivers should never declare coherent memory like
> this, and there has been some work to fix remoteproc in that regard.
>
> But I guess until that is merged we'll need somthing like this fix.
Should I take
The third parameter of dma_set_encrypted() is a size in bytes rather than
the number of pages.
Fixes: 4d0564785bb0 ("dma-direct: factor out dma_set_{de,en}crypted helpers")
Signed-off-by: Dexuan Cui
---
kernel/dma/direct.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git
On Tue, Jun 21, 2022 at 9:59 PM Tony Lindgren wrote:
>
> Hi,
>
> * Saravana Kannan [220621 19:29]:
> > On Tue, Jun 21, 2022 at 12:28 AM Tony Lindgren wrote:
> > >
> > > Hi,
> > >
> > > * Saravana Kannan [700101 02:00]:
> > > > Now that fw_devlink=on by default and fw_devlink supports
> > > >
On Wed, Jun 22, 2022 at 1:44 AM Linus Walleij wrote:
>
> On Wed, Jun 22, 2022 at 9:48 AM Sascha Hauer wrote:
>
> > This patch has the effect that console UART devices which have "dmas"
> > properties specified in the device tree get deferred for 10 to 20
> > seconds. This happens on i.MX and
On Wed, Jun 22, 2022 at 12:40 PM Saravana Kannan wrote:
>
> On Wed, Jun 22, 2022 at 1:44 AM Linus Walleij
> wrote:
> >
> > On Wed, Jun 22, 2022 at 9:48 AM Sascha Hauer wrote:
> >
> > > This patch has the effect that console UART devices which have "dmas"
> > > properties specified in the
On 2022/6/23 10:51, Jerry Snitselaar wrote:
The real problem here is that the iommu sequence ID overflows if
DMAR_UNITS_SUPPORTED is not big enough. This is purely a software
implementation issue, I am not sure whether user opt-in when building a
kernel package could help a lot here.
Is this
> From: Robin Murphy
> Sent: Wednesday, June 22, 2022 3:55 PM
>
> On 2022-06-16 23:23, Nicolin Chen wrote:
> > On Thu, Jun 16, 2022 at 06:40:14AM +, Tian, Kevin wrote:
> >
> >>> The domain->ops validation was added, as a precaution, for mixed-
> driver
> >>> systems. However, at this moment
Hi Robin,
I love your patch! Yet something to improve:
[auto build test ERROR on v5.19-rc3]
[also build test ERROR on linus/master next-20220622]
[cannot apply to awilliam-vfio/next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest
On Wed, Jun 22, 2022 at 3:32 PM Peng Fan wrote:
>
> > Subject: [PATCH v1 0/2] Fix console probe delay due to fw_devlink
> >
> > fw_devlink.strict=1 has been enabled by default. This was delaying the probe
> > of console devices. This series fixes that.
> >
> > Sasha/Peng,
> >
> > Can you test
On Wed, Jun 22, 2022 at 1:35 PM Saravana Kannan wrote:
>
> On Wed, Jun 22, 2022 at 12:40 PM Saravana Kannan wrote:
> >
> > On Wed, Jun 22, 2022 at 1:44 AM Linus Walleij
> > wrote:
> > >
> > > On Wed, Jun 22, 2022 at 9:48 AM Sascha Hauer wrote:
> > >
> > > > This patch has the effect that
> Subject: [PATCH v1 0/2] Fix console probe delay due to fw_devlink
>
> fw_devlink.strict=1 has been enabled by default. This was delaying the probe
> of console devices. This series fixes that.
>
> Sasha/Peng,
>
> Can you test this please?
Thanks, just give a test on i.MX8MP-EVK, works well
Commit 71066545b48e ("driver core: Set fw_devlink.strict=1 by default")
enabled iommus and dmas dependency enforcement by default. On some
systems, this caused the console device's probe to get delayed until the
deferred_probe_timeout expires.
We need consoles to work as soon as possible, so mark
When firmware sets the FWNODE_FLAG_BEST_EFFORT flag for a fwnode,
fw_devlink will do a best effort ordering for that device where it'll
only enforce the probe/suspend/resume ordering of that device with
suppliers that have drivers. The driver of that device can then decide
if it wants to defer
fw_devlink.strict=1 has been enabled by default. This was delaying the
probe of console devices. This series fixes that.
Sasha/Peng,
Can you test this please?
-Saravana
Cc: Sascha Hauer
Cc: Peng Fan
Cc: Kevin Hilman
Cc: Ulf Hansson
Cc: Len Brown
Cc: Pavel Machek
Cc: Joerg Roedel
Cc:
On Wed, 22 Jun 2022 13:04:11 +0100
Robin Murphy wrote:
> Since IOMMU groups are mandatory for drivers to support, it stands to
> reason that any device which has been successfully be added to a group
s/be //
> must be on a bus supported by that IOMMU driver, and therefore a domain
> viable for
On 2022/6/22 20:04, Robin Murphy wrote:
Since IOMMU groups are mandatory for drivers to support, it stands to
reason that any device which has been successfully be added to a group
must be on a bus supported by that IOMMU driver, and therefore a domain
viable for any device in the group must be
On 2022/6/22 20:04, Robin Murphy wrote:
Use the new interface to check the capabilities for our device
specifically.
Signed-off-by: Robin Murphy
---
drivers/vfio/vfio.c | 2 +-
drivers/vfio/vfio_iommu_type1.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
On Thu, 2022-06-16 at 11:31 +0100, Robin Murphy wrote:
> On 2022-06-16 11:08, Yong Wu wrote:
> > On Thu, 2022-06-16 at 09:59 +0100, Robin Murphy wrote:
> > > On 2022-06-16 06:42, Yong Wu wrote:
> > > > The mtk_iommu_mm_dts_parse will parse the smi larbs nodes. if
> > > > the
> > > > i+1
> > > >
On Thu, 2022-06-16 at 15:49 +0200, Matthias Brugger wrote:
>
> On 16/06/2022 07:42, Yong Wu wrote:
> > The mtk_iommu_mm_dts_parse will parse the smi larbs nodes. if the
> > i+1
> > larb is parsed fail(return -EINVAL), we should of_node_put for the
> > 0..i
> > larbs. In the fail path, one
On 2022/6/22 23:05, Jerry Snitselaar wrote:
On Wed, Jun 22, 2022 at 7:52 AM Baolu Lu wrote:
On 2022/6/16 02:36, 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 variable,
CONFIG_DMAR_UNITS_SUPPORTED, and
On Thu, Jun 23, 2022 at 10:29:35AM +0800, Baolu Lu wrote:
> On 2022/6/22 23:05, Jerry Snitselaar wrote:
> > On Wed, Jun 22, 2022 at 7:52 AM Baolu Lu wrote:
> > > On 2022/6/16 02:36, Steve Wahl wrote:
> > > > To support up to 64 sockets with 10 DMAR units each (640), make the
> > > > value of
On Wed, Jun 22, 2022 at 10:25:40AM -0600, Mathieu Poirier wrote:
> On Sat, Apr 23, 2022 at 07:46:50PM +0200, Christoph Hellwig wrote:
> > Sigh. In theory drivers should never declare coherent memory like
> > this, and there has been some work to fix remoteproc in that regard.
> >
> > But I guess
On Wed, Jun 22, 2022 at 12:14:24PM -0700, Dexuan Cui wrote:
> The third parameter of dma_set_encrypted() is a size in bytes rather than
> the number of pages.
>
> Fixes: 4d0564785bb0 ("dma-direct: factor out dma_set_{de,en}crypted helpers")
> Signed-off-by: Dexuan Cui
see:
commit
74 matches
Mail list logo
