On 2022/5/31 23:59, Jason Gunthorpe wrote:
On Tue, May 31, 2022 at 02:52:28PM +0100, Robin Murphy wrote:
+ break;
+ pgtable_walk_level(m, phys_to_virt(phys_addr),
Also, obligatory reminder that pfn_valid() only means that pfn_to_page()
gets you a valid struct page.
Hi Robin,
Thank you for the comments.
On 2022/5/31 21:52, Robin Murphy wrote:
On 2022-05-31 04:02, Baolu Lu wrote:
On 2022/5/30 20:14, Jason Gunthorpe wrote:
On Sun, May 29, 2022 at 01:14:46PM +0800, Baolu Lu wrote:
[--snip--]
diff --git a/drivers/iommu/intel/debugfs.c
On Tue, May 31, 2022 at 03:19:45PM -0700, Rob Clark wrote:
> um, quite.. tbf that was in the context of a WIP igt test for
> shrinker which was trying to cycle thru ~2x RAM size worth of GEM
> buffers on something like 72 threads. So it could just be threads
> that had gotten past the
> From: Jacob Pan
> Sent: Wednesday, June 1, 2022 4:44 AM
>
> Hi Jason,
>
> On Tue, 31 May 2022 16:05:50 -0300, Jason Gunthorpe
> wrote:
>
> > On Tue, May 31, 2022 at 10:29:55AM -0700, Jacob Pan wrote:
> >
> > > The reason why I store PASID at IOMMU domain is for IOTLB flush within
> > > the
> From: Jacob Pan
> Sent: Wednesday, June 1, 2022 1:30 AM
> > >
> > > In both cases the pasid is stored in the attach data instead of the
> > > domain.
> > >
> So during IOTLB flush for the domain, do we loop through the attach data?
Yes and it's required.
>
> > > DMA API pasid is no special
On Tue, 31 May 2022, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> The main purpose of this binding is to communicate Xen specific
> information using generic IOMMU device tree bindings (which is
> a good fit here) rather than introducing a custom property.
>
> Introduce Xen
On Tue, May 31, 2022 at 10:22:32PM +0100, Robin Murphy wrote:
> There are only 3 instances where we'll free a table while the domain is
> live. The first is the one legitimate race condition, where two map requests
> targeting relatively nearby PTEs both go to fill in an intermediate level of
>
On Tue, May 31, 2022 at 3:00 PM Robin Murphy wrote:
>
> On 2022-05-31 22:51, Rob Clark wrote:
> > From: Rob Clark
> >
> > Ratelimit the error msg to avoid flooding the console.
> >
> > Signed-off-by: Rob Clark
> > ---
> > kernel/dma/debug.c | 2 +-
> > 1 file changed, 1 insertion(+), 1
On 5/31/22 17:54, Keith Busch wrote:
> On Tue, May 31, 2022 at 02:23:44PM -0400, Tony Battersby wrote:
>> dma_pool_free() scales poorly when the pool contains many pages because
>> pool_find_page() does a linear scan of all allocated pages. Improve its
>> scalability by replacing the linear scan
On 2022-05-31 22:51, Rob Clark wrote:
From: Rob Clark
Ratelimit the error msg to avoid flooding the console.
Signed-off-by: Rob Clark
---
kernel/dma/debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/dma/debug.c b/kernel/dma/debug.c
index
On 2022-05-31 20:52, Tony Battersby wrote:
On 5/31/22 15:48, Robin Murphy wrote:
On 2022-05-31 19:17, Tony Battersby wrote:
pool->name, blocks,
-(size_t) pages *
-(pool->allocation / pool->size),
On Tue, May 31, 2022 at 02:23:44PM -0400, Tony Battersby wrote:
> dma_pool_free() scales poorly when the pool contains many pages because
> pool_find_page() does a linear scan of all allocated pages. Improve its
> scalability by replacing the linear scan with a red-black tree lookup.
> In big O
From: Rob Clark
Ratelimit the error msg to avoid flooding the console.
Signed-off-by: Rob Clark
---
kernel/dma/debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/dma/debug.c b/kernel/dma/debug.c
index f8ff598596b8..683966f0247b 100644
--- a/kernel/dma/debug.c
On Tue, May 31, 2022 at 02:22:21PM -0400, Tony Battersby wrote:
> +static void pool_free_page(struct dma_pool *pool,
> +struct dma_page *page,
> +bool destroying_pool)
'destroying_pool' is always true, so I don't think you need it.
On 2022-05-31 19:51, Jason Gunthorpe wrote:
On Tue, May 31, 2022 at 07:07:32PM +0100, Robin Murphy wrote:
And we expect the iommu driver to be unable to free page table levels
that have IOVA boundaries in them?
I'm not entirely sure what you mean there, but in general an unmap request
is
On Tue, May 31, 2022 at 9:19 AM Will Deacon wrote:
>
> On Tue, May 31, 2022 at 09:15:22AM -0700, Rob Clark wrote:
> > On Tue, May 31, 2022 at 8:46 AM Will Deacon wrote:
> > >
> > > On Fri, May 27, 2022 at 11:28:56PM +0200, Konrad Dybcio wrote:
> > > > From: AngeloGioacchino Del Regno
> > > >
>
Hi Jason,
On Tue, 31 May 2022 16:05:50 -0300, Jason Gunthorpe wrote:
> On Tue, May 31, 2022 at 10:29:55AM -0700, Jacob Pan wrote:
>
> > The reason why I store PASID at IOMMU domain is for IOTLB flush within
> > the domain. Device driver is not aware of domain level IOTLB flush. We
> > also
On 5/31/22 15:48, Robin Murphy wrote:
> On 2022-05-31 19:17, Tony Battersby wrote:
>
>> pool->name, blocks,
>> - (size_t) pages *
>> - (pool->allocation / pool->size),
>> + (size_t)
On 2022-05-31 19:17, Tony Battersby wrote:
The "total number of blocks in pool" debug statistic currently does not
take the boundary value into account, so it diverges from the "total
number of blocks in use" statistic when a boundary is in effect. Add a
calculation for the number of blocks per
On 2022-05-31 19:22, Tony Battersby wrote:
Remove a small amount of code duplication between dma_pool_destroy() and
pool_free_page() in preparation for adding more code without having to
duplicate it. No functional changes.
Signed-off-by: Tony Battersby
---
mm/dmapool.c | 34
On Tue, May 31, 2022 at 10:29:55AM -0700, Jacob Pan wrote:
> The reason why I store PASID at IOMMU domain is for IOTLB flush within the
> domain. Device driver is not aware of domain level IOTLB flush. We also
> have iova_cookie for each domain which essentially is for RIDPASID.
You need to make
On Tue, May 31, 2022 at 07:07:32PM +0100, Robin Murphy wrote:
> > And we expect the iommu driver to be unable to free page table levels
> > that have IOVA boundaries in them?
>
> I'm not entirely sure what you mean there, but in general an unmap request
> is expected to match some previous map
To represent the size of a single allocation, dmapool currently uses
'unsigned int' in some places and 'size_t' in other places. Standardize
on 'unsigned int' to reduce overhead, but use 'size_t' when counting all
the blocks in the entire pool.
Signed-off-by: Tony Battersby
---
This puts an
This patch series improves dmapool scalability by replacing linear scans
with red-black trees.
History:
In 2018 this patch series made it through 4 versions. v1 used red-black
trees; v2 - v4 put the dma pool info directly into struct page and used
virt_to_page() to get at it. v4 made a brief
dmapool originally tried to support pools without a device because
dma_alloc_coherent() supports allocations without a device. But nobody
ended up using dma pools without a device, so the current checks in
dmapool.c for pool->dev == NULL are both insufficient and causing bloat.
Remove them.
Fix the boundary comparison when constructing the list of free blocks
for the case that 'size' is a power of two. Since 'boundary' is also a
power of two, that would make 'boundary' a multiple of 'size', in which
case a single block would never cross the boundary. This bug would
cause some of
On 2022-05-31 19:12, Tony Battersby wrote:
dmapool originally tried to support pools without a device because
dma_alloc_coherent() supports allocations without a device. But nobody
ended up using dma pools without a device, so the current checks in
dmapool.c for pool->dev == NULL are both
dma_pool_free() scales poorly when the pool contains many pages because
pool_find_page() does a linear scan of all allocated pages. Improve its
scalability by replacing the linear scan with a red-black tree lookup.
In big O notation, this improves the algorithm from O(n^2) to O(n * log n).
dma_pool_alloc() scales poorly when allocating a large number of pages
because it does a linear scan of all previously-allocated pages before
allocating a new one. Improve its scalability by maintaining a separate
list of pages that have free blocks ready to (re)allocate. In big O
notation, this
Remove a small amount of code duplication between dma_pool_destroy() and
pool_free_page() in preparation for adding more code without having to
duplicate it. No functional changes.
Signed-off-by: Tony Battersby
---
mm/dmapool.c | 34 --
1 file changed, 20
Avoid double-memset of the same allocated memory in dma_pool_alloc()
when both DMAPOOL_DEBUG is enabled and init_on_alloc=1.
Signed-off-by: Tony Battersby
---
mm/dmapool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/dmapool.c b/mm/dmapool.c
index
There are two cases:
1) In the normal case that the memory is being freed correctly, then
DMAPOOL_DEBUG will memset the memory anyway, so speed things up by
avoiding a double-memset of the same memory.
2) In the abnormal case that DMAPOOL_DEBUG detects that a driver passes
incorrect parameters
Prevent a possible endless loop with DMAPOOL_DEBUG enabled if a buggy
driver corrupts DMA pool memory.
Signed-off-by: Tony Battersby
---
mm/dmapool.c | 37 ++---
1 file changed, 30 insertions(+), 7 deletions(-)
diff --git a/mm/dmapool.c b/mm/dmapool.c
index
The "total number of blocks in pool" debug statistic currently does not
take the boundary value into account, so it diverges from the "total
number of blocks in use" statistic when a boundary is in effect. Add a
calculation for the number of blocks per allocation that takes the
boundary into
On 2022-05-31 17:21, Jason Gunthorpe wrote:
On Tue, May 31, 2022 at 05:01:46PM +0100, Robin Murphy wrote:
The DMA API doesn't need locking, partly since it can trust itself not to do
stupid things, and mostly because it's DMA API performance that's
fundamentally incompatible with serialisation
Hi Baolu,
On Tue, 31 May 2022 20:45:28 +0800, Baolu Lu
wrote:
> On 2022/5/31 18:12, Tian, Kevin wrote:
> +++ b/include/linux/iommu.h
> @@ -105,6 +105,8 @@ struct iommu_domain {
> enum iommu_page_response_code (*iopf_handler)(struct
> >> iommu_fault *fault,
>
On 31.05.22 14:52, Krzysztof Kozlowski wrote:
Hello Krzysztof
On 30/05/2022 23:00, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Thank you for your patch. There is something to discuss/improve.
diff --git a/Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml
The pull request you sent on Tue, 31 May 2022 14:37:42 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
> tags/iommu-updates-v5.19
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e1cbc3b96a9974746b2a80c3a6c8a0f7eff7b1b5
Thank you!
--
On 2022-05-31 16:59, Jason Gunthorpe wrote:
On Tue, May 31, 2022 at 02:52:28PM +0100, Robin Murphy wrote:
+ break;
+ pgtable_walk_level(m, phys_to_virt(phys_addr),
Also, obligatory reminder that pfn_valid() only means that pfn_to_page()
gets you a valid struct page.
On 2022-05-31 16:55, Will Deacon wrote:
On Fri, May 27, 2022 at 11:28:57PM +0200, Konrad Dybcio wrote:
From: AngeloGioacchino Del Regno
As also stated in the arm-smmu driver, we must write the TCR before
writing the TTBRs, since the TCR determines the access behavior of
some fields.
Where
On Tue, May 31, 2022 at 05:01:46PM +0100, Robin Murphy wrote:
> The DMA API doesn't need locking, partly since it can trust itself not to do
> stupid things, and mostly because it's DMA API performance that's
> fundamentally incompatible with serialisation anyway. Why do you think we
> have a
On Tue, May 31, 2022 at 09:15:22AM -0700, Rob Clark wrote:
> On Tue, May 31, 2022 at 8:46 AM Will Deacon wrote:
> >
> > On Fri, May 27, 2022 at 11:28:56PM +0200, Konrad Dybcio wrote:
> > > From: AngeloGioacchino Del Regno
> > >
> > >
> > > As specified in this driver, the context banks are
On Tue, May 31, 2022 at 8:46 AM Will Deacon wrote:
>
> On Fri, May 27, 2022 at 11:28:56PM +0200, Konrad Dybcio wrote:
> > From: AngeloGioacchino Del Regno
> >
> > As specified in this driver, the context banks are 0x1000 apart.
> > Problem is that sometimes the context number (our asid) does not
On Tue, May 31, 2022 at 08:45:28PM +0800, Baolu Lu wrote:
> My understanding is that device driver owns its PASID policy.
I'm not sure this is actually useful, the core code should provide the
allocator as I can't think of any device that actually needs a special
allocator.
> If ENQCMD is
On 2022-05-31 16:13, Jason Gunthorpe wrote:
On Tue, May 31, 2022 at 04:01:04PM +0100, Robin Murphy wrote:
On 2022-05-31 15:53, Jason Gunthorpe wrote:
On Tue, May 31, 2022 at 10:11:18PM +0800, Baolu Lu wrote:
On 2022/5/31 21:10, Jason Gunthorpe wrote:
On Tue, May 31, 2022 at 11:02:06AM +0800,
On Tue, May 31, 2022 at 02:52:28PM +0100, Robin Murphy wrote:
> > + break;
> > + pgtable_walk_level(m, phys_to_virt(phys_addr),
>
> Also, obligatory reminder that pfn_valid() only means that pfn_to_page()
> gets you a valid struct page. Whether that page is
On Fri, May 27, 2022 at 11:28:57PM +0200, Konrad Dybcio wrote:
> From: AngeloGioacchino Del Regno
>
> As also stated in the arm-smmu driver, we must write the TCR before
> writing the TTBRs, since the TCR determines the access behavior of
> some fields.
Where is this stated in the arm-smmu
On 5/31/22 13:39, Suravee Suthikulpanit wrote:
> On 4/29/22 4:09 AM, Joao Martins wrote:
>> AMD implementation of unmap_read_dirty() is pretty simple as
>> mostly reuses unmap code with the extra addition of marshalling
>> the dirty bit into the bitmap as it walks the to-be-unmapped
>> IOPTE.
>>
On Fri, May 27, 2022 at 11:28:56PM +0200, Konrad Dybcio wrote:
> From: AngeloGioacchino Del Regno
>
> As specified in this driver, the context banks are 0x1000 apart.
> Problem is that sometimes the context number (our asid) does not
> match this logic and we end up using the wrong one: this
On 5/31/22 12:34, Suravee Suthikulpanit wrote:
> Joao,
>
> On 4/29/22 4:09 AM, Joao Martins wrote:
>> .
>> +static int amd_iommu_set_dirty_tracking(struct iommu_domain *domain,
>> +bool enable)
>> +{
>> +struct protection_domain *pdomain =
On Tue, May 31, 2022 at 04:01:04PM +0100, Robin Murphy wrote:
> On 2022-05-31 15:53, Jason Gunthorpe wrote:
> > On Tue, May 31, 2022 at 10:11:18PM +0800, Baolu Lu wrote:
> > > On 2022/5/31 21:10, Jason Gunthorpe wrote:
> > > > On Tue, May 31, 2022 at 11:02:06AM +0800, Baolu Lu wrote:
> > > >
> >
On 2022-05-31 15:53, Jason Gunthorpe wrote:
On Tue, May 31, 2022 at 10:11:18PM +0800, Baolu Lu wrote:
On 2022/5/31 21:10, Jason Gunthorpe wrote:
On Tue, May 31, 2022 at 11:02:06AM +0800, Baolu Lu wrote:
For case 2, it is a bit weird. I tried to add a rwsem lock to make the
iommu_unmap() and
On Tue, May 31, 2022 at 10:11:18PM +0800, Baolu Lu wrote:
> On 2022/5/31 21:10, Jason Gunthorpe wrote:
> > On Tue, May 31, 2022 at 11:02:06AM +0800, Baolu Lu wrote:
> >
> > > For case 2, it is a bit weird. I tried to add a rwsem lock to make the
> > > iommu_unmap() and dumping tables in debugfs
From: h...@lst.de Sent: Tuesday, May 31, 2022 12:17 AM
>
> On Mon, May 30, 2022 at 01:52:37AM +, Michael Kelley (LINUX) wrote:
> > B) The contents of the memory buffer must transition between
> > encrypted and not encrypted. The hardware doesn't provide
> > any mechanism to do such a
On 2022/5/31 21:10, Jason Gunthorpe wrote:
On Tue, May 31, 2022 at 11:02:06AM +0800, Baolu Lu wrote:
For case 2, it is a bit weird. I tried to add a rwsem lock to make the
iommu_unmap() and dumping tables in debugfs exclusive. This does not
work because debugfs may depend on the DMA of the
On 2022-05-31 04:02, Baolu Lu wrote:
On 2022/5/30 20:14, Jason Gunthorpe wrote:
On Sun, May 29, 2022 at 01:14:46PM +0800, Baolu Lu wrote:
From 1e87b5df40c6ce9414cdd03988c3b52bfb17af5f Mon Sep 17 00:00:00 2001
From: Lu Baolu
Date: Sun, 29 May 2022 10:18:56 +0800
Subject: [PATCH 1/1]
On Tue, May 31, 2022 at 11:02:06AM +0800, Baolu Lu wrote:
> For case 2, it is a bit weird. I tried to add a rwsem lock to make the
> iommu_unmap() and dumping tables in debugfs exclusive. This does not
> work because debugfs may depend on the DMA of the devices to work. It
> seems that what we
On 2022/5/31 18:12, Tian, Kevin wrote:
+++ b/include/linux/iommu.h
@@ -105,6 +105,8 @@ struct iommu_domain {
enum iommu_page_response_code (*iopf_handler)(struct
iommu_fault *fault,
void *data);
void *fault_data;
+
On 4/29/22 4:09 AM, Joao Martins wrote:
AMD implementation of unmap_read_dirty() is pretty simple as
mostly reuses unmap code with the extra addition of marshalling
the dirty bit into the bitmap as it walks the to-be-unmapped
IOPTE.
Extra care is taken though, to switch over to cmpxchg as
Hi Linus,
Apologies for the late pull request, I know you prefer the main stuff in
the first week. Some vacation and a public holiday came in between here.
So here are the IOMMU updates for 5.19. Some patches are probably
arleady merged via the VFIO tree, namely everyting from the
Hi Suravee ,
On 2022/5/31 19:34, Suravee Suthikulpanit wrote:
On 4/29/22 4:09 AM, Joao Martins wrote:
.
+static int amd_iommu_set_dirty_tracking(struct iommu_domain *domain,
+ bool enable)
+{
+ struct protection_domain *pdomain = to_pdomain(domain);
+ struct
On 30/05/2022 23:00, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
Thank you for your patch. There is something to discuss/improve.
> diff --git a/Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml
> b/Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml
> new file
Joao,
On 4/29/22 4:09 AM, Joao Martins wrote:
.
+static int amd_iommu_set_dirty_tracking(struct iommu_domain *domain,
+ bool enable)
+{
+ struct protection_domain *pdomain = to_pdomain(domain);
+ struct iommu_dev_data *dev_data;
+ bool
> From: Jason Gunthorpe
> Sent: Monday, May 30, 2022 8:23 PM
>
> On Tue, May 24, 2022 at 08:17:27AM -0700, Jacob Pan wrote:
> > Hi Jason,
> >
> > On Tue, 24 May 2022 10:50:34 -0300, Jason Gunthorpe
> wrote:
> >
> > > On Wed, May 18, 2022 at 11:21:15AM -0700, Jacob Pan wrote:
> > > > DMA
On Mon, May 30, 2022 at 01:52:37AM +, Michael Kelley (LINUX) wrote:
> B) The contents of the memory buffer must transition between
> encrypted and not encrypted. The hardware doesn't provide
> any mechanism to do such a transition "in place". The only
> way to transition is for the CPU to
65 matches
Mail list logo
