Re: [PATCH 0/2] Change order of linkage in kernel makefiles for amdkfd

For this series: Reviewed-by: Christian König christian.koe...@amd.com Am 22.12.2014 um 12:07 schrieb Oded Gabbay: This small patch-set, was created to solve the bug described at https://bugzilla.kernel.org/show_bug.cgi?id=89661 (Kernel panic when trying use amdkfd driver on Kaveri

Re: [PATCH 0/2] Change order of linkage in kernel makefiles for amdkfd

Am 29.12.2014 um 09:16 schrieb Laurent Pinchart: Hi Oded, On Sunday 28 December 2014 13:36:50 Oded Gabbay wrote: On 12/26/2014 11:19 AM, Laurent Pinchart wrote: On Thursday 25 December 2014 14:20:59 Thierry Reding wrote: On Mon, Dec 22, 2014 at 01:07:13PM +0200, Oded Gabbay wrote: This

Re: [RFT v2] iommu/amd: use subsys_initcall() on amdv2 iommu

Am 11.04.2016 um 15:39 schrieb Oded Gabbay: On Mon, Apr 11, 2016 at 4:28 PM, Christian König <christian.koe...@amd.com> wrote: Am 09.04.2016 um 02:25 schrieb Luis R. Rodriguez: On Tue, Mar 29, 2016 at 10:41 AM, Luis R. Rodriguez <mcg...@kernel.org> wrote: We need to ensure

Re: Feature Request: Ability to decode bus/dma address back into physical address

Am 02.08.2017 um 19:33 schrieb Jerome Glisse: On Wed, Aug 02, 2017 at 07:23:58PM +0200, Christian König wrote: Am 02.08.2017 um 19:13 schrieb Jerome Glisse: On Wed, Aug 02, 2017 at 07:05:11PM +0200, Christian König wrote: Am 02.08.2017 um 18:43 schrieb Jerome Glisse: On Wed, Aug 02, 2017

Re: Feature Request: Ability to decode bus/dma address back into physical address

Hi Jerome, sorry for being a bit late to the discussion and the top posting. But I think you miss a very important point here, which makes the whole discussion on how to implement completely superfluous: We already have a functionality to access the content of BOs in a process for debugging

Re: [patch net-next 0/3] net/sched: Improve getting objects by indexes

Am 16.08.2017 um 04:12 schrieb Chris Mi: Using current TC code, it is very slow to insert a lot of rules. In order to improve the rules update rate in TC, we introduced the following two changes: 1) changed cls_flower to use IDR to manage the filters. 2) changed all act_xxx

Re: Feature Request: Ability to decode bus/dma address back into physical address

Am 02.08.2017 um 18:43 schrieb Jerome Glisse: On Wed, Aug 02, 2017 at 10:26:40AM +0200, Christian König wrote: [SNIP] So to summarize you are saying you do not trust the value you get from pci_map_page() ? Well, what we don't trust is that we actually get this value correctly into our page

Re: Feature Request: Ability to decode bus/dma address back into physical address

Am 02.08.2017 um 19:13 schrieb Jerome Glisse: On Wed, Aug 02, 2017 at 07:05:11PM +0200, Christian König wrote: Am 02.08.2017 um 18:43 schrieb Jerome Glisse: On Wed, Aug 02, 2017 at 10:26:40AM +0200, Christian König wrote: [SNIP] So to summarize you are saying you do not trust the value you

Re: [PATCH] swiotlb: Fix inversed DMA_ATTR_NO_WARN test

Am 02.05.2018 um 18:59 schrieb Michel Dänzer: On 2018-05-02 06:21 PM, Christoph Hellwig wrote: On Wed, May 02, 2018 at 04:31:09PM +0200, Michel Dänzer wrote: No. __GFP_NOWARN (and gfp_t flags in general) are the wrong interface for dma allocations and just cause problems. I actually plan to

Re: [PATCH] swiotlb: Fix inversed DMA_ATTR_NO_WARN test

allocation" Signed-off-by: Michel Dänzer <michel.daen...@amd.com> Good catch, looked at the code multiple times and haven't seen that myself :) Reviewed-by: Christian König <christian.koe...@amd.com>. Christian. --- lib/swiotlb.c | 2 +- 1 file changed, 1 insertion(+), 1 d

Re: consolidate swiotlb dma_map implementations

Am 16.01.2018 um 09:28 schrieb Christoph Hellwig: On Tue, Jan 16, 2018 at 09:22:52AM +0100, Christian König wrote: Hi Konrad, can you send the first patch to Linus for inclusion in 4.15 if you haven't already done so? It's in the 4.16 queue with a cc to stable. I guess we're ok

Re: consolidate swiotlb dma_map implementations

Hi Konrad, can you send the first patch to Linus for inclusion in 4.15 if you haven't already done so? I'm still getting reports from people complaining about the error message. Thanks, Christian. Am 16.01.2018 um 08:53 schrieb Christoph Hellwig: I've pulled this into the dma-mapping

Re: consolidate swiotlb dma_map implementations

Acked-by: Christian König <christian.koe...@amd.com> for the whole series. Regards, Christian. Am 10.01.2018 um 09:09 schrieb Christoph Hellwig: A lot of architectures have essentially identical dma_map_ops implementations to use swiotlb. This series adds new generic swiotlb_allo

Re: [PATCH 11/13] drm/amdgpu: add DRM_AMDGPU_ATC config option

Adding Jean and the IOMMU list as well. Am 31.01.2018 um 13:43 schrieb Oded Gabbay: On Tue, Jan 30, 2018 at 6:53 PM, Felix Kuehling wrote: [SNIP] There was some discussion last year about a generic PASID allocator in the iommu subsystem:

Re: [PATCH 02/37] iommu/sva: Bind process address spaces to devices

Am 15.02.2018 um 11:21 schrieb j...@8bytes.org: On Tue, Feb 13, 2018 at 12:57:23PM +, Jean-Philippe Brucker wrote: * bind_device() fails if the device's group has more than one device, otherwise calls __bind_device(). This prevents device drivers that are oblivious to IOMMU groups from

Re: [PATCH v2 01/40] iommu: Introduce Shared Virtual Addressing API

Am 07.09.2018 um 17:45 schrieb Jean-Philippe Brucker: On 07/09/2018 09:55, Christian König wrote: I will take this as an opportunity to summarize some of the requirements we have for PASID management from the amdgpu driver point of view: That's incredibly useful, thanks :) 1. We need

Re: [PATCH v2 01/40] iommu: Introduce Shared Virtual Addressing API

Am 06.09.2018 um 13:09 schrieb Jean-Philippe Brucker: Hi Eric, Thanks for reviewing On 05/09/2018 12:29, Auger Eric wrote: +int iommu_sva_device_init(struct device *dev, unsigned long features, + unsigned int max_pasid) what about min_pasid? No one asked for it...

Re: [PATCH v2 01/40] iommu: Introduce Shared Virtual Addressing API

Am 06.09.2018 um 14:45 schrieb Jean-Philippe Brucker: On 06/09/2018 12:12, Christian König wrote: Am 06.09.2018 um 13:09 schrieb Jean-Philippe Brucker: Hi Eric, Thanks for reviewing On 05/09/2018 12:29, Auger Eric wrote: +int iommu_sva_device_init(struct device *dev, unsigned long features

Re: [PATCH v2 01/40] iommu: Introduce Shared Virtual Addressing API

Am 07.09.2018 um 23:25 schrieb Jacob Pan: On Fri, 7 Sep 2018 20:02:54 +0200 Christian König wrote: [SNIP] iommu-sva expects everywhere that the device has an iommu_domain, it's the first thing we check on entry. Bypassing all of this would call idr_alloc() directly, and wouldn't have any code

Re: [PATCH 03/37] iommu/sva: Manage process address spaces

Am 01.03.2018 um 07:52 schrieb Lu Baolu: Hi Jean, On 02/13/2018 02:33 AM, Jean-Philippe Brucker wrote: [SNIP] + pasid = idr_alloc_cyclic(_pasid_idr, io_mm, dev_param->min_pasid, +dev_param->max_pasid + 1, GFP_ATOMIC); Can the pasid management code be

Re: [PATCH V2] drm/amdgpu: limit DMA size to PAGE_SIZE for scatter-gather buffers

Am 12.04.2018 um 08:26 schrieb Christoph Hellwig: On Wed, Apr 11, 2018 at 01:03:59PM +0100, Robin Murphy wrote: On 10/04/18 21:59, Sinan Kaya wrote: Code is expecing to observe the same number of buffers returned from dma_map_sg() function compared to sg_alloc_table_from_pages(). This doesn't

Re: amdgpu/TTM oopses since merging swiotlb_dma_ops into the dma_direct code

Am 10.01.19 um 14:57 schrieb Christoph Hellwig: On Thu, Jan 10, 2019 at 10:59:02AM +0100, Michel Dänzer wrote: Hi Christoph, https://bugs.freedesktop.org/109234 (please ignore comments #6-#9) was bisected to your commit 55897af63091 "dma-direct: merge swiotlb_dma_ops into the dma_direct

Re: [PATCH v2 01/40] iommu: Introduce Shared Virtual Addressing API

Am 12.09.2018 um 14:40 schrieb Jean-Philippe Brucker: On 08/09/2018 08:29, Christian König wrote: Yes, exactly. I just need a PASID which is never used by the OS for a process and we can easily give that back when the last FD reference is closed. Alright, iommu-sva can get its PASID from

Re: [RFC PATCH 1/5] pci/p2p: add a function to test peer to peer capability

Am 29.01.19 um 21:24 schrieb Logan Gunthorpe: On 2019-01-29 12:56 p.m., Alex Deucher wrote: On Tue, Jan 29, 2019 at 12:47 PM wrote: From: Jérôme Glisse device_test_p2p() return true if two devices can peer to peer to each other. We add a generic function as different inter-connect can

Re: [PATCH v3 hmm 08/11] drm/radeon: use mmu_notifier_get/put for struct radeon_mn

to the interval tree after release are already impossible as only current->mm is used during the add. Signed-off-by: Jason Gunthorpe Acked-by: Christian König But I'm wondering if we shouldn't completely drop radeon userptr support. It's just to buggy, Christian. --- drivers/gpu/drm/rad

Re: [PATCH v2] iommu/amd: Disable IOMMU on Stoney Ridge systems

Am 04.12.19 um 17:08 schrieb Deucher, Alexander: -Original Message- From: Deucher, Alexander Sent: Monday, December 2, 2019 11:37 AM To: Lucas Stach ; Kai-Heng Feng ; j...@8bytes.org; Koenig, Christian (christian.koe...@amd.com) Cc: iommu@lists.linux-foundation.org;

Re: [PATCH v5 02/25] iommu/sva: Manage process address spaces

Am 20.04.20 um 13:55 schrieb Christoph Hellwig: On Mon, Apr 20, 2020 at 01:44:56PM +0200, Christian König wrote: Am 20.04.20 um 10:10 schrieb Christoph Hellwig: On Mon, Apr 20, 2020 at 09:42:13AM +0200, Jean-Philippe Brucker wrote: Right, I can see the appeal. I still like having a single mmu

Re: [PATCH v5 02/25] iommu/sva: Manage process address spaces

Am 20.04.20 um 10:10 schrieb Christoph Hellwig: On Mon, Apr 20, 2020 at 09:42:13AM +0200, Jean-Philippe Brucker wrote: Right, I can see the appeal. I still like having a single mmu notifier per mm because it ensures we allocate a single PASID per mm (as required by x86). I suppose one

Re: [RFC 02/17] drm: amdgpu: fix sg_table nents vs. orig_nents misuse

of entries passed to dma_map_sg. The sg_table->nents in turn holds the result of the dma_map_sg call as stated in include/linux/scatterlist.h. Adapt the code to obey those rules. Signed-off-by: Marek Szyprowski Reviewed-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c

Re: [RFC 10/17] drm: radeon: fix sg_table nents vs. orig_nents misuse

of entries passed to dma_map_sg. The sg_table->nents in turn holds the result of the dma_map_sg call as stated in include/linux/scatterlist.h. Adapt the code to obey those rules. Signed-off-by: Marek Szyprowski Reviewed-by: Christian König --- drivers/gpu/drm/radeon/radeon_ttm.c |

Re: [PATCH 0/2] iommu/amd: Fix IOMMUv2 devices when SME is active

UPP; + } + #ifdef CONFIG_DRM_AMDGPU_SI if (!amdgpu_si_support) { switch (flags & AMD_ASIC_MASK) { -- 2.25.4 Looks good to me, thanks. Acked-by: Joerg Roedel This is really unfortunate, but I don't see any other solution either.

Re: [PATCH v7 04/36] drm: amdgpu: fix common struct sg_table related issues

and copy/paste safe. Signed-off-by: Marek Szyprowski Reviewed-by: Christian König Any objection that we pick this one and the radeon up into our branches for upstreaming? That should about clashes with other driver changes. Thanks, Christian. --- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c

Re: [PATCH] drm/ttm: use dma_alloc_pages for the page pool

Am 11.05.21 um 10:50 schrieb Christoph Hellwig: On Tue, May 11, 2021 at 09:35:20AM +0200, Christian König wrote: We certainly going to need the drm_need_swiotlb() for userptr support (unless we add some approach for drivers to opt out of swiotlb). swiotlb use is driven by three things: 1

Re: [PATCH] drm/ttm: use dma_alloc_pages for the page pool

Am 11.05.21 um 08:05 schrieb Christoph Hellwig: Use the dma_alloc_pages allocator for the TTM pool allocator. This allocator is a front end to the page allocator which takes the DMA mask of the device into account, thus offering the best of both worlds of the two existing allocator versions.

Re: [RFC PATCH v2 04/11] PCI/P2PDMA: Introduce pci_p2pdma_should_map_bus() and pci_p2pdma_bus_offset()

Am 24.03.21 um 18:21 schrieb Jason Gunthorpe: On Mon, Mar 15, 2021 at 10:27:08AM -0600, Logan Gunthorpe wrote: In this case the WARN_ON is just to guard against misuse of the function. It should never happen unless a developer changes the code in a way that is incorrect. So I think that's the

Re: [PATCH 1/1] drm/amdkfd: fix build error with AMD_IOMMU_V2=m

Am 09.03.21 um 18:59 schrieb Alex Deucher: On Tue, Mar 9, 2021 at 12:55 PM Jean-Philippe Brucker wrote: Hi Felix, On Tue, Mar 09, 2021 at 11:30:19AM -0500, Felix Kuehling wrote: I think the proper fix would be to not rely on custom hooks into a particular IOMMU driver, but to instead ensure

Re: I got an IOMMU IO page fault. What to do now?

Hi Paul, not sure how the IOMMU gives out addresses, but the printed ones look suspicious to me. Something like we are using an invalid address like -1 or similar. Can you try that on an up to date kernel as well? E.g. ideally bleeding edge amd-staging-drm-next from Alex repository.

Re: [PATCH 00/11] Implement generic prot_guest_has() helper function

only one end user of this, but at least from the high level point of view that makes totally sense to me. Feel free to add an Acked-by: Christian König . We could run that through the AMD GPU unit tests, but I fear we actually don't test on a system with SEV/SME active. Going to raise

Re: [PATCH v3 19/20] PCI/P2PDMA: introduce pci_mmap_p2pmem()

Am 04.10.21 um 15:27 schrieb Jason Gunthorpe: On Mon, Oct 04, 2021 at 03:22:22PM +0200, Christian König wrote: That use case is completely unrelated to GUP and when this doesn't work we have quite a problem. My read is that unmap_mapping_range() guarentees the physical TLB hardware

Re: [PATCH v3 19/20] PCI/P2PDMA: introduce pci_mmap_p2pmem()

I'm not following this discussion to closely, but try to look into it from time to time. Am 01.10.21 um 19:45 schrieb Jason Gunthorpe: On Fri, Oct 01, 2021 at 11:01:49AM -0600, Logan Gunthorpe wrote: In device-dax, the refcount is only used to prevent the device, and therefore the pages,

Re: [PATCH v3 19/20] PCI/P2PDMA: introduce pci_mmap_p2pmem()

Am 04.10.21 um 15:11 schrieb Jason Gunthorpe: On Mon, Oct 04, 2021 at 08:58:35AM +0200, Christian König wrote: I'm not following this discussion to closely, but try to look into it from time to time. Am 01.10.21 um 19:45 schrieb Jason Gunthorpe: On Fri, Oct 01, 2021 at 11:01:49AM -0600, Logan

Re: I got an IOMMU IO page fault. What to do now?

Hi Robin, Am 25.10.21 um 18:01 schrieb Robin Murphy: On 2021-10-25 12:23, Christian König wrote: Hi Paul, not sure how the IOMMU gives out addresses, but the printed ones look suspicious to me. Something like we are using an invalid address like -1 or similar. FWIW those look like