Hi Alex,
On Wed, May 04, 2022 at 10:29:56AM -0600, Alex Williamson wrote:
> Done, and thanks for the heads-up. Please try to cc me when the
> vfio-notifier-fix branch is merged back into your next branch. Thanks,
This has happened now, the vfio-notifier-fix branch got the fix and is
merged
On Tue, May 10, 2022 at 05:01:06PM +0100, Will Deacon wrote:
> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git
> tags/arm-smmu-updates
Pulled, thanks Will.
___
iommu mailing list
iommu@lists.linux-foundation.org
On Tue, May 10, 2022 at 10:33:59AM +0800, Lu Baolu wrote:
> This includes patches queued for v5.19. It includes:
>
> - Domain force snooping improvement.
> - Cleanups, no intentional functional changes.
>
> Please consider them for v5.19.
>
> [This series cannot be directly applied to vt-d
On Mon, May 09, 2022 at 11:16:08AM +0100, Robin Murphy wrote:
> drivers/iommu/dma-iommu.c | 13 -
> drivers/pci/of.c | 8 +---
> 2 files changed, 13 insertions(+), 8 deletions(-)
Applied, thanks.
___
iommu mailing list
On Mon, May 09, 2022 at 02:48:15AM -0500, Suravee Suthikulpanit wrote:
> 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,
On Sat, May 07, 2022 at 04:52:03PM +0800, yf.w...@mediatek.com wrote:
> drivers/iommu/dma-iommu.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
Applied, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
On Thu, May 05, 2022 at 09:27:30PM +0800, Miles Chen wrote:
> drivers/iommu/mtk_iommu.c| 6 ++
> drivers/iommu/mtk_iommu_v1.c | 7 +++
> 2 files changed, 13 insertions(+)
Applied, thanks.
___
iommu mailing list
On Mon, May 09, 2022 at 01:19:19PM -0300, Jason Gunthorpe wrote:
> drivers/iommu/iommu.c | 127 ++
> 1 file changed, 91 insertions(+), 36 deletions(-)
Applied, thanks. Will back-merge the branch into next now.
Ashish Mhetre (1):
iommu: arm-smmu: disable large page mappings for Nvidia arm-smmu
David Stevens (1):
iommu/vt-d: Calculate mask for non-aligned flushes
Hector Martin (1):
iommu/dart: Add missing module owner to ops structure
Joerg Roedel
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
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!
to point to the found one,
> and remove the unneeded check for 'iommu->dev->of_node != spec->np'
> outside the loop.
>
> Cc: sta...@vger.kernel.org
> Fixes: f78ebca8ff3d6 ("iommu/msm: Add support for generic master bindings")
> Signed-off-by: Xiaomeng Tong
>
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
ommu/renesas,ipmmu-vmsa.yaml | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Acked-by: Joerg Roedel
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
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.
Hi Vasant,
On Fri, Apr 29, 2022 at 08:15:49PM +0530, Vasant Hegde wrote:
> We still need to parse IVHD to find max devices supported by each PCI segment
> (same as the way its doing it today). Hence we need all these variables.
>From what I have seen since a few years the IVRS tables enumerate
On Thu, Apr 07, 2022 at 04:32:28PM +0800, Yong Wu wrote:
> Yong Wu (2):
> dt-bindings: mediatek: mt8186: Add binding for MM iommu
> iommu/mediatek: Add mt8186 iommu support
>
> .../bindings/iommu/mediatek,iommu.yaml| 4 +
> drivers/iommu/mtk_iommu.c | 17 ++
>
On Thu, Apr 28, 2022 at 08:54:11AM -0300, Jason Gunthorpe wrote:
> Can we get this on a topic branch so Alex can pull it? There are
> conflicts with other VFIO patches
Right, we already discussed this. Moved the patches to a separate topic
branch. It will appear as 'vfio-notifier-fix' once I
On Thu, Apr 28, 2022 at 04:52:39PM +0800, xkernel.w...@foxmail.com wrote:
> From: Xiaoke Wang
>
> kzalloc() is a memory allocation function which can return NULL when
> some internal memory errors happen. So it is better to check it to
> prevent potential wrong memory access.
>
> Besides, to
Hi Vasant, Hi Suravee,
On Mon, Apr 25, 2022 at 05:03:38PM +0530, Vasant Hegde wrote:
> Newer AMD systems can support multiple PCI segments, where each segment
> contains one or more IOMMU instances. However, an IOMMU instance can only
> support a single PCI segment.
Thanks for doing this, making
On Mon, Apr 25, 2022 at 05:04:15PM +0530, Vasant Hegde wrote:
> + seg_id = (iommu_fault->sbdf >> 16) & 0x;
> + devid = iommu_fault->sbdf & 0x;
This deserves some macros for readability.
___
iommu mailing list
On Mon, Apr 25, 2022 at 05:04:05PM +0530, Vasant Hegde wrote:
> From: Suravee Suthikulpanit
>
> Replace global amd_iommu_dev_table with per PCI segment device table.
> Also remove "dev_table_size".
>
> Co-developed-by: Vasant Hegde
> Signed-off-by: Vasant Hegde
> Signed-off-by: Suravee
On Mon, Apr 25, 2022 at 05:03:49PM +0530, Vasant Hegde wrote:
> + /* Size of the device table */
> + u32 dev_table_size;
Same here and with all other size indicators. If they are always going
to have their maximum value anyways, we can drop them.
On Mon, Apr 25, 2022 at 05:03:48PM +0530, Vasant Hegde wrote:
> + /* Largest PCI device id we expect translation requests for */
> + u16 last_bdf;
How does the IVRS table look like on these systems? Do they still
enumerate the whole PCI Bus/Dev/Fn space? If so I am fine with getting
rid
On Mon, Apr 25, 2022 at 05:03:39PM +0530, Vasant Hegde wrote:
Subject: iommu/amd: Update struct iommu_dev_data defination
^^ Typo
___
iommu mailing list
iommu@lists.linux-foundation.org
Hi Vasant,
On Mon, Apr 25, 2022 at 05:03:40PM +0530, Vasant Hegde wrote:
> +/*
> + * This structure contains information about one PCI segment in the system.
> + */
> +struct amd_iommu_pci_seg {
> + struct list_head list;
The purpose of this list_head needs a comment.
> +
> + /* PCI
On Mon, Apr 25, 2022 at 05:08:26PM +0800, Yang Yingliang wrote:
> It will cause null-ptr-deref in resource_size(), if platform_get_resource()
> returns NULL, move calling resource_size() after devm_ioremap_resource() that
> will check 'res' to avoid null-ptr-deref.
> And use
On Fri, Apr 22, 2022 at 02:21:03PM -0500, Rob Herring wrote:
> There's no need to show consumer side in provider examples. The ones
> used here are undocumented or undocumented in schemas which results in
> warnings.
>
> Signed-off-by: Rob Herring
Applied, thanks Rob.
On Fri, Apr 22, 2022 at 12:22:34PM +0100, Will Deacon wrote:
> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git
> tags/arm-smmu-fixes
Pulled, thanks Will.
___
iommu mailing list
iommu@lists.linux-foundation.org
On Mon, Apr 18, 2022 at 08:49:49AM +0800, Lu Baolu wrote:
> Lu Baolu (10):
> iommu: Add DMA ownership management interfaces
> driver core: Add dma_cleanup callback in bus_type
> amba: Stop sharing platform_dma_configure()
> bus: platform,amba,fsl-mc,PCI: Add device DMA ownership management
On Tue, Apr 12, 2022 at 06:12:11PM +0200, Sven Peter wrote:
> It's the same people anyway.
>
> Signed-off-by: Sven Peter
> ---
> MAINTAINERS | 10 ++
> 1 file changed, 2 insertions(+), 8 deletions(-)
Applied, thanks.
___
iommu mailing list
On Sat, Apr 23, 2022 at 04:23:29PM +0800, Lu Baolu wrote:
> Hi Joerg,
>
> One fix is queued for v5.18. It aims to fix:
>
> - Handle PCI stop marker messages in IOMMU driver to meet the
>requirement of I/O page fault handling framework.
>
> Please consider it for the iommu/fix branch.
>
>
On Sun, Apr 10, 2022 at 09:35:32AM +0800, Lu Baolu wrote:
> Hi Joerg,
>
> One fix is queued for v5.18. It aims to fix:
>
> - Calculate a feasible mask for non-aligned page-selective
>IOTLB invalidation.
>
> Please consider it for the iommu/fix branch.
>
> Best regards,
> Lu Baolu
>
>
On Mon, Apr 11, 2022 at 12:16:04PM -0300, Jason Gunthorpe wrote:
> Jason Gunthorpe (4):
> iommu: Introduce the domain op enforce_cache_coherency()
> vfio: Move the Intel no-snoop control off of IOMMU_CACHE
> iommu: Redefine IOMMU_CAP_CACHE_COHERENCY as the cap flag for
> IOMMU_CACHE
>
On Thu, Apr 07, 2022 at 08:26:04AM +0200, Christoph Hellwig wrote:
> Hi all,
>
> this removes a bit of dead code and methods from the iommu code and the
> cleans up the arm-smmu-v3 driver a little bit based on that.
>
> Diffstat:
> drivers/iommu/amd/iommu.c |1
>
On Mon, Apr 04, 2022 at 03:47:21PM -0500, Mario Limonciello wrote:
> Mario Limonciello (2):
> iommu/amd: Enable swiotlb in all cases
> dma-iommu: Check that swiotlb is active before trying to use it
>
> drivers/iommu/amd/iommu.c | 7 ---
> drivers/iommu/dma-iommu.c | 5 +
> 2 files
On Sat, Apr 02, 2022 at 12:08:38PM +0200, Christophe Leroy wrote:
> powerpc's asm/prom.h brings some headers that it doesn't
> need itself.
>
> In order to clean it up, first add missing headers in
> users of asm/prom.h
>
> Signed-off-by: Christophe Leroy
> ---
> drivers/iommu/fsl_pamu.c
On Tue, Mar 29, 2022 at 05:53:22AM +, cgel@gmail.com wrote:
> From: Lv Ruyi
>
> kmem_cache_zalloc is a memory allocation function which can return NULL
> when some internal memory errors happen. Add null pointer check to avoid
> dereferencing null pointer.
>
> Reported-by: Zeal Robot
>
st | 2 +-
> Documentation/x86/intel-iommu.rst | 115
> Documentation/x86/iommu.rst | 143 ++
> 3 files changed, 144 insertions(+), 116 deletions(-)
> delete mode 100644 Documentation/x86/intel-iommu.rst
> create mode
On Sun, Mar 27, 2022 at 01:35:58PM +0800, Xiaomeng Tong wrote:
> @@ -617,23 +617,17 @@ static int qcom_iommu_of_xlate(struct device *dev,
> {
> struct msm_iommu_dev *iommu;
> unsigned long flags;
> - int ret = 0;
>
> spin_lock_irqsave(_iommu_lock, flags);
>
On Fri, Mar 25, 2022 at 10:08:01AM +0800, xkernel.w...@foxmail.com wrote:
> From: Xiaoke Wang
>
> kzalloc() is a memory allocation function which can return NULL when
> some internal memory errors happen. So it is better to check it to
> prevent potential wrong memory access.
>
> Signed-off-by:
On Mon, Mar 14, 2022 at 12:32:26PM +0530, Vasant Hegde wrote:
> smatch static checker warning:
> drivers/iommu/amd/init.c:1989 amd_iommu_init_pci()
> warn: duplicate check 'ret' (previous on line 1978)
>
> Reported-by: Dan Carpenter
> Fixes: 06687a03805e ("iommu/amd: Improve error handling
On Sun, Mar 13, 2022 at 09:43:21PM -0500, Suravee Suthikulpanit wrote:
> Smatch static checker warns:
> drivers/iommu/amd/iommu_v2.c:133 free_device_state()
> warn: sleeping in atomic context
>
> Fixes by storing the list of struct device_state in a temporary
> list, and then free the
On Fri, Apr 08, 2022 at 11:17:47AM -0300, Jason Gunthorpe wrote:
> You might consider using a linear tree instead of the topic branches,
> topics are tricky and I'm not sure it helps a small subsystem so much.
> Conflicts between topics are a PITA for everyone, and it makes
> handling conflicts
On Fri, Apr 08, 2022 at 09:23:52AM -0300, Jason Gunthorpe wrote:
> Why rc3? It has been 4 weeks now with no futher comments.
Because I start applying new code to branches based on -rc3. In the past
I used different -rc's for the topic branches (usually the latest -rc
available when I started
Hi Linus,
The following changes since commit 3123109284176b1532874591f7c81f3837bbdc17:
Linux 5.18-rc1 (2022-04-03 14:08:21 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
tags/iommu-fix-v5.18-rc1
for you to fetch changes up to
On Thu, Apr 07, 2022 at 08:39:05AM +0300, Tony Lindgren wrote:
> Can you guys please get this fix into the -rc series? Or ack it so
> I can pick it up into my fixes branch?
Sorry for the delay, Covid catched me so I was away from email for
almost 2 week. This patch is picked-up now and I will
On Mon, Mar 14, 2022 at 09:21:25PM -0300, Jason Gunthorpe wrote:
> Joerg, are we good for the coming v5.18 merge window now? There are
> several things backed up behind this series.
I usually don't apply bigger changes like this after -rc7, so it didn't
make it. Please re-send after -rc3 is out
ion
iommu/arm-smmu-v3: Simplify memory allocation
David Heidelberg (1):
iommu/msm: Simplify with dev_err_probe()
Jiasheng Jiang (1):
iommu/ipmmu-vmsa: Check for error num after setting mask
Joerg Roedel (3):
Merge branch 'core' into x86/vt-d
Merge tag 'arm-smmu-updates' of
On Tue, Mar 08, 2022 at 10:18:10AM +, Will Deacon wrote:
> Hi Joerg,
>
> Please pull this handful of Arm SMMU updates for 5.18. Summary in the tag.
Pulled, thanks Will.
___
iommu mailing list
iommu@lists.linux-foundation.org
On Fri, Mar 04, 2022 at 06:37:01PM +0800, Lu Baolu wrote:
> It's based on this series:
>
> https://lore.kernel.org/linux-iommu/yhy%2fawftokqll...@8bytes.org/
>
> which contains some cleanup in vt-d driver as well.
>
> If I re-base the series onto the vt-d branch, there will also be
> conflicts
Hi Linus,
The following changes since commit 754e0b0e35608ed5206d6a67a791563c631cec07:
Linux 5.17-rc4 (2022-02-13 12:13:30 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
tags/iommu-fixes-v5.17-rc6
for you to fetch changes up to
On Fri, Mar 04, 2022 at 05:57:19PM +0800, Yong Wu wrote:
> Thanks for this info. I will re-send this patchset after the next -rc1.
>
> Could you help apply Dafna's patchset at this time? This patchset
> depends on it and it won't conflict with the others.
Alright, picked up Dafna's patch-set.
On Wed, Dec 08, 2021 at 02:07:39PM +0200, Dafna Hirschfeld wrote:
> Sebastian Reichel (1):
> iommu/mediatek: Always check runtime PM status in tlb flush range
> callback
>
> Yong Wu (4):
> iommu/mediatek: Remove for_each_m4u in tlb_sync_all
> iommu/mediatek: Remove the power status
On Fri, Mar 04, 2022 at 07:36:46AM +0800, Miles Chen wrote:
> Hi Robin,
>
> > For various reasons based on the allocator behaviour and typical
> > use-cases at the time, when the max32_alloc_size optimisation was
> > introduced it seemed reasonable to couple the reset of the tracked
> > size to
On Tue, Mar 01, 2022 at 02:26:21PM +0530, Vasant Hegde wrote:
> This series contains various cleanup and trivial fixes.
>
> Changes in v2:
> - Fixed error log message in patch 1 as suggested by Joerg.
>
>
> Suravee Suthikulpanit (2):
> iommu/amd: Improve error handling for
Hi Baolu,
On Tue, Mar 01, 2022 at 10:01:47AM +0800, Lu Baolu wrote:
> This includes patches queued for v5.18. It includes:
>
> - [PATCH 1 ~ 11] Various cleanups, no intentional functional changes.
> - [PATCH 12] Enable ATS in SoC-integrated devices listed in ACPI/SATC
> table.
>
On Tue, Mar 01, 2022 at 03:49:18PM +0800, Yong Wu wrote:
> https://patchwork.kernel.org/project/linux-mediatek/list/?series=592275
Okay, thanks for the clarification. So I can't include linux-next in my
tree, so I think the best option is to wait until v5.18-rc1 (or rather
-rc3, which is where I
On Mon, Feb 21, 2022 at 01:33:48PM +0800, Lu Baolu wrote:
> Fixes: 474dd1c65064 ("iommu/vt-d: Fix clearing real DMA device's
> scalable-mode context entries")
> Cc: sta...@vger.kernel.org # v5.14+
> Signed-off-by: Adrian Huang
> Link:
On Mon, Feb 21, 2022 at 10:29:11AM +0530, Vasant Hegde wrote:
> This series contains various cleanup and trivial fixes.
>
> Suravee Suthikulpanit (2):
> iommu/amd: Improve error handling for amd_iommu_init_pci
> iommu/amd: Improve amd_iommu_v2_exit()
>
> Vasant Hegde (3):
> iommu/amd: Call
On Mon, Feb 21, 2022 at 10:29:12AM +0530, Vasant Hegde wrote:
> From: Suravee Suthikulpanit
>
> Add error messages to prevent silent failure.
>
> Signed-off-by: Suravee Suthikulpanit
> Signed-off-by: Vasant Hegde
> ---
> drivers/iommu/amd/init.c | 12 +---
> 1 file changed, 9
Hi Yong Wu,
On Thu, Feb 17, 2022 at 07:34:19PM +0800, Yong Wu wrote:
> Yong Wu (34):
> dt-bindings: mediatek: mt8195: Add binding for MM IOMMU
> dt-bindings: mediatek: mt8195: Add binding for infra IOMMU
> iommu/mediatek: Fix 2 HW sharing pgtable issue
> iommu/mediatek: Add list_del in
On Wed, Feb 16, 2022 at 10:52:40AM +0800, Lu Baolu wrote:
> Lu Baolu (9):
> iommu/vt-d: Remove guest pasid related callbacks
> iommu: Remove guest pasid related interfaces and definitions
> iommu/vt-d: Remove aux-domain related callbacks
> iommu: Remove aux-domain related interfaces and
On Fri, Jan 07, 2022 at 08:09:11AM +, Miaoqian Lin wrote:
> The reference taken by 'of_find_device_by_node()' must be released when
> not needed anymore.
> Add the corresponding 'put_device()' in the error handling path.
>
> Fixes: 765a9d1d02b2 ("iommu/tegra-smmu: Fix mc errors on
ocated PASID lifetime bound to the life time of the process.
>
> Get rid of the refcounting mechanisms and replace/rename the interfaces
> to reflect this new approach.
>
> Suggested-by: Dave Hansen
> Signed-off-by: Fenghua Yu
>
Hi Baolu,
On Tue, Feb 15, 2022 at 10:05:42AM +0800, Lu Baolu wrote:
> Do you want me to send a new version with below changes:
>
> - Remove WARN_ON() in dev_iommu_ops();
> - Merge above two patches.
>
> Or, you can change above yourself?
Please make the changes and send a new version. I will
On Mon, Feb 14, 2022 at 11:00:59AM -0400, Jason Gunthorpe wrote:
> On Mon, Feb 14, 2022 at 03:23:07PM +0100, Joerg Roedel wrote:
>
> > Device drivers calling into iommu_attach_device() is seldom a good
> > idea. In this case the sound device has some generic hardwar
On Mon, Feb 14, 2022 at 11:46:26AM -0400, Jason Gunthorpe wrote:
> On Mon, Feb 14, 2022 at 03:18:31PM +, Robin Murphy wrote:
>
> > Arguably, iommu_attach_device() could be renamed something like
> > iommu_attach_group_for_dev(), since that's effectively the semantic that all
> > the existing
On Thu, Feb 03, 2022 at 05:59:20PM +0800, John Garry wrote:
> Currently the rcache structures are allocated for all IOVA domains, even if
> they do not use "fast" alloc+free interface. This is wasteful of memory.
>
> In addition, fails in init_iova_rcaches() are not handled safely, which is
>
On Mon, Feb 14, 2022 at 09:03:13AM -0400, Jason Gunthorpe wrote:
> Groups should disappear into an internal implementation detail, not be
> so prominent in the API.
Not going to happen, IOMMU groups are ABI and todays device assignment
code, including user-space, relies on them.
Groups implement
On Mon, Feb 14, 2022 at 10:02:36AM -0400, Jason Gunthorpe wrote:
> That works for VFIO, but it doesn't work for other in-kernel
> drivers.. Is there something ensuring the group is only the GPU and
> sound device? Is the GPU never an addin card?
GPUs supporting this functionality are always
On Mon, Feb 14, 2022 at 09:55:28AM +0800, Lu Baolu wrote:
> v3:
> - Remove ops check when dev_iommu_ops() is used.
> - This version of series is available on github:
>https://github.com/LuBaolu/intel-iommu/commits/iommu-domain-ops-v3
>
> Lu Baolu (10):
> iommu/vt-d: Remove guest pasid
On Mon, Feb 14, 2022 at 09:15:44AM -0400, Jason Gunthorpe wrote:
> But how does the sound device know that this has been done to it?
>
> eg how do we know the sound device hasn't been bound to VFIO or
> something at this point?
The iommu_attach_group() call will fail when the group (which
On Mon, Feb 07, 2022 at 04:12:40PM +0200, Andy Shevchenko wrote:
> diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
> index 69230fd695ea..1036c1900b5c 100644
> --- a/include/linux/intel-iommu.h
> +++ b/include/linux/intel-iommu.h
> @@ -813,6 +813,8 @@ bool
On Sun, Feb 06, 2022 at 09:29:45PM +0100, David Heidelberg wrote:
> Use the dev_err_probe() helper to simplify error handling during probe.
> This also handle scenario, when EDEFER is returned and useless error is
> printed.
>
> Fixes warnings as:
> msm_iommu 750.iommu: could not get
On Fri, Feb 04, 2022 at 10:34:05PM +0100, Heiko Stuebner wrote:
> Am Freitag, 4. Februar 2022, 21:16:41 CET schrieb Robin Murphy:
> > It's been a long time since there was any reason to register IOMMU
> > drivers early. Convert to the standard platform driver helper.
> >
> > CC: Heiko Stuebner
>
On Thu, Feb 10, 2022 at 12:29:05PM +, Robin Murphy wrote:
> Implementing ops->capable to always return false is pointless since it's
> the default behaviour anyway. Clean up the unnecessary implementations.
>
> Signed-off-by: Robin Murphy
> ---
>
> Spinning this out of my bus ops stuff
On Tue, Feb 08, 2022 at 09:20:28AM +0900, Yoshihiro Shimoda wrote:
> This patch series is based on renesas-drivers-2022-01-11-v5.16 [1].
> Note that we have to prepare the following registers' setting
> in a bootloader (U-Boot) because the registers are protected.
> Otherwise, data mismatch
s://lore.kernel.org/r/20211218074546.1772553-1-baolu...@linux.intel.com
> Reviewed-by: Christoph Hellwig
> Reviewed-by: Jason Gunthorpe
Acked-by: Joerg Roedel
I guess this is picked up by the DRM maintainers?
___
iommu mailing list
iommu@lists
On Mon, Feb 14, 2022 at 09:55:35AM +0800, Lu Baolu wrote:
> +static inline const struct iommu_ops *dev_iommu_ops(struct device *dev)
> +{
> + /*
> + * Assume that valid ops must be installed if iommu_probe_device()
> + * has succeeded. The device ops are essentially for internal use
On Mon, Feb 14, 2022 at 12:32:21PM +, Robin Murphy wrote:
> In this particular case it cannot fail on any system the driver actually
> runs on - it's a platform device so the dma_mask pointer is always
> initialised, then dma_direct_supported() on arm64 will always return true
> for any mask
On Tue, Feb 01, 2022 at 07:11:40PM +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Replace acpi_bus_get_device() that is going to be dropped with
> acpi_fetch_acpi_dev().
>
> No intentional functional impact.
>
> Signed-off-by: Rafael J. Wysocki
> ---
>
unching VM w/ pass-through devices.
>
> Fix by freeing the memory used for page table before updating the mode.
>
> Cc: Joerg Roedel
> Reported-by: Daniel Jordan
> Tested-by: Daniel Jordan
> Signed-off-by: Suravee Suthikulpanit
> Fixes: e42ba0633064 ("iommu/amd
Adding more potential reviewers.
On Thu, Jan 06, 2022 at 10:43:02AM +0800, Jiasheng Jiang wrote:
> Because of the possible failure of the dma_supported(), the
> dma_set_mask_and_coherent() may return error num.
> Therefore, it should be better to check it and return the error if
> fails.
>
>
On Thu, Jan 06, 2022 at 10:20:48AM +0800, Lu Baolu wrote:
> int iommu_attach_device(struct iommu_domain *domain, struct device *dev)
> {
> struct iommu_group *group;
> - int ret;
> + int ret = 0;
> +
> + if (domain->type != IOMMU_DOMAIN_UNMANAGED)
> + return
On Thu, Jan 06, 2022 at 10:33:45AM -0400, Jason Gunthorpe wrote:
> But I'm not sure how this can work with multi-device groups - this
> seems to assigns a domain setup for direct map, so perhaps this only
> works if all devices are setup for direct map?
Right, at boot all devices in this group
Hi Jacob,
On Wed, Feb 09, 2022 at 01:52:49PM -0800, Jacob Pan wrote:
> Another option Ashok and I discussed is that we can make DMAR cache persist
> (which should be for explicitly listed devices in each DRHD) across PCI
> remove-rescan cycle, then we don't need the DMAR PCI bus notifier at all.
: Fix potential memory leak in intel_setup_irq_remapping()
Joerg Roedel (1):
iommu/amd: Fix loop timeout issue in iommu_ga_log_enable()
John Garry (1):
iommu: Fix some W=1 warnings
Vijayanand Jitta (1):
iommu: Fix potential use-after-free during probe
drivers/iommu/amd/init.c
From: Joerg Roedel
The polling loop for the register change in iommu_ga_log_enable() needs
to have a udelay() in it. Otherwise the CPU might be faster than the
IOMMU hardware and wrongly trigger the WARN_ON() further down the code
stream. Use a 10us for udelay(), has there is some hardware
On Mon, Jan 31, 2022 at 05:06:03PM +, John Garry wrote:
> > diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
> > index dc338acf3338..d2e09d53851f 100644
> > --- a/drivers/iommu/amd/init.c
> > +++ b/drivers/iommu/amd/init.c
> > @@ -834,6 +834,7 @@ static int
On Tue, Feb 01, 2022 at 11:19:18AM -0800, Jacob Pan wrote:
> Do you mean having an IRQ remapping notifier regardless IOMMU-API is
> enabled, right?
> It make sense, I will give it a try.
Yeah, that would be best. I really don't like to use two notifiers just
to work around ordering issues.
From: Joerg Roedel
The polling loop for the register change in iommu_ga_log_enable() needs
to have a udelay() in it. Otherwise the CPU might be faster than the
IOMMU hardware and wrongly trigger the WARN_ON() further down the code
stream.
Fixes: 8bda0cfbdc1a ("iommu/amd: Detect and initi
On Fri, Jan 28, 2022 at 11:10:02AM +0800, Lu Baolu wrote:
> From: Guoqing Jiang
>
> After commit e3beca48a45b ("irqdomain/treewide: Keep firmware node
> unconditionally allocated"). For tear down scenario, fn is only freed
> after fail to allocate ir_domain, though it also should be freed in
On Mon, Jan 31, 2022 at 01:53:06PM +, Robin Murphy wrote:
> Indeed I very nearly asked whether we couldn't just call these from
> intel_iommu_{probe,release}_device() directly, but it looks like they also
> interact with the interrupt remapping stuff which can be built independently
> of the
On Fri, Jan 28, 2022 at 06:44:33PM +0800, John Garry wrote:
> The code is mostly free of W=1 warning, so fix the following:
>
> drivers/iommu/iommu.c:996: warning: expecting prototype for
> iommu_group_for_each_dev(). Prototype was for __iommu_group_for_each_dev()
> instead
>
On Mon, Jan 31, 2022 at 12:42:35PM +0530, Vijayanand Jitta wrote:
> drivers/iommu/iommu.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
Applied, thanks Vijayanand.
___
iommu mailing list
iommu@lists.linux-foundation.org
Thierry,
does this look correct to you?
Thanks,
Joerg
On Fri, Jan 07, 2022 at 08:09:11AM +, Miaoqian Lin wrote:
> The reference taken by 'of_find_device_by_node()' must be released when
> not needed anymore.
> Add the corresponding 'put_device()' in the error handling path.
>
>
Hi Jacob, Baolu,
On Fri, Jan 28, 2022 at 11:10:01AM +0800, Lu Baolu wrote:
> During PCI bus rescan, adding new devices involve two notifiers.
> 1. dmar_pci_bus_notifier()
> 2. iommu_bus_notifier()
> The current code sets #1 as low priority (INT_MIN) which resulted in #2
> being invoked first. The
1 - 100 of 3386 matches
Mail list logo
