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
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.
Regard
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
hardwa
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,
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, from
x27;m 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 rai
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
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. Thi
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 c
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 t
return -ENOTSUPP;
+ }
+
#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
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
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 |
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
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
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 alternativ
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; linux-ker...@vger.ker
ns 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.
---
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 suppo
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 code".
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 this
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 hav
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
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
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... The
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
g
by: Michel Dänzer
Good catch, looked at the code multiple times and haven't seen that
myself :)
Reviewed-by: Christian König .
Christian.
---
lib/swiotlb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index c43ec2271469..e9ac215406
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 h
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(&iommu_pasid_idr, io_mm, dev_param->min_pasid,
+dev_param->max_pasid + 1, GFP_ATOMIC);
Can the pasid management code be
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 openi
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:
https://lists.linuxfoundation.org/pipermail/iommu/2017-
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&#x
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 for-ne
Acked-by: Christian König 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_alloc/free helpers that take the attrs
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 mod
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 at
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
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
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
Am 11.04.2016 um 15:39 schrieb Oded Gabbay:
On Mon, Apr 11, 2016 at 4:28 PM, Christian König
wrote:
Am 09.04.2016 um 02:25 schrieb Luis R. Rodriguez:
On Tue, Mar 29, 2016 at 10:41 AM, Luis R. Rodriguez wrote:
We need to ensure amd iommu v2 initializes before
driver uses such as drivers/gpu
ugh proper kernel
APIs.
Cc: Oded Gabbay
Cc: Christian König
Signed-off-by: Luis R. Rodriguez
Sorry for not responding earlier. Just coming back to all the stuff on
my TODO list.
Patch is Acked-by: Christian König
Regards,
Christian.
*pok
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 small
For this series: Reviewed-by: Christian König
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). It replaces the previous patch-set
43 matches
Mail list logo
