ant enough to argue.
v1:
https://lore.kernel.org/r/0-v1-720585788a7d+811b-iommu_fwspec_p1_...@nvidia.com
Jason Gunthorpe (7):
iommu: Remove struct iommu_ops *iommu from arch_setup_dma_ops()
iommmu/of: Do not return struct iommu_ops from of_iommu_configure()
iommu/of: Use -ENODEV co
tin
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/amd/iommu.c | 2 --
drivers/iommu/apple-dart.c | 1 -
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 1 -
drivers/iommu/arm/arm-smmu/arm-smmu.c | 1 -
drivers/iommu/intel/iommu.c | 2 --
driv
Snitselaar
Reviewed-by: Lu Baolu
Reviewed-by: Moritz Fischer
Acked-by: Christoph Hellwig
Acked-by: Rob Herring
Tested-by: Hector Martin
Signed-off-by: Jason Gunthorpe
---
arch/arc/mm/dma.c | 2 +-
arch/arm/mm/dma-mapping-nommu.c | 2 +-
arch/arm/mm/dma-mapping.c | 10
Nothing needs this pointer. Return a normal error code with the usual
IOMMU semantic that ENODEV means 'there is no IOMMU driver'.
Acked-by: Rafael J. Wysocki
Reviewed-by: Jerry Snitselaar
Reviewed-by: Lu Baolu
Reviewed-by: Moritz Fischer
Tested-by: Hector Martin
Signed-off-by: Jason
Allocation of dev->iommu must be done under the
iommu_probe_device_lock. Mark this with lockdep to discourage future
mistakes.
Reviewed-by: Jerry Snitselaar
Tested-by: Hector Martin
Reviewed-by: Lu Baolu
Reviewed-by: Moritz Fischer
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/iomm
Nothing needs this pointer. Return a normal error code with the usual
IOMMU semantic that ENODEV means 'there is no IOMMU driver'.
Reviewed-by: Jerry Snitselaar
Reviewed-by: Lu Baolu
Acked-by: Rob Herring
Tested-by: Hector Martin
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/of_iommu.c
led configure functions thought there was an iommu and we should try to
probe it. Remove it.
Reviewed-by: Jerry Snitselaar
Reviewed-by: Moritz Fischer
Tested-by: Hector Martin
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/of_iommu.c | 49
1 file changed,
This API was defined to formalize the access to internal iommu details on
some Tegra SOCs, but a few callers got missed. Add them.
The helper already masks by 0x so remove this code from the callers.
Suggested-by: Thierry Reding
Reviewed-by: Thierry Reding
Signed-off-by: Jason Gunthorpe
On Thu, Nov 30, 2023 at 02:10:48PM +, Robin Murphy wrote:
> > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> > index 7673bb82945b6c..309378e76a9bc9 100644
> > --- a/drivers/iommu/Kconfig
> > +++ b/drivers/iommu/Kconfig
> > @@ -318,6 +318,7 @@ config ARM_SMMU
> > select
On Thu, Nov 30, 2023 at 12:12:26PM +0100, Lorenzo Pieralisi wrote:
> On Wed, Nov 29, 2023 at 03:12:40PM -0400, Jason Gunthorpe wrote:
> > On Wed, Nov 29, 2023 at 01:55:04PM +0100, Lorenzo Pieralisi wrote:
> >
> > > I don't think it should be done this way. Is the goal co
On Wed, Nov 29, 2023 at 05:23:13PM +0100, Thierry Reding wrote:
> > diff --git a/drivers/memory/tegra/tegra186.c
> > b/drivers/memory/tegra/tegra186.c
> > index 533f85a4b2bdb7..3e4fbe94dd666e 100644
> > --- a/drivers/memory/tegra/tegra186.c
> > +++ b/drivers/memory/tegra/tegra186.c
> > @@ -111,21
On Wed, Nov 29, 2023 at 01:55:04PM +0100, Lorenzo Pieralisi wrote:
> I don't think it should be done this way. Is the goal compile testing
> IORT code ?
Yes
> If so, why are we forcing it through the SMMU (only because
> it can be compile tested while eg SMMUv3 driver can't ?) menu entry ?
On Wed, Nov 29, 2023 at 05:58:08PM +, Robin Murphy wrote:
> On 29/11/2023 12:48 am, Jason Gunthorpe wrote:
> > The iommu_device_lock protects the iommu_device_list which is only read by
> > iommu_ops_from_fwnode().
> >
> > This is now always called under the iom
led configure functions thought there was an iommu and we should try to
probe it. Remove it.
Reviewed-by: Jerry Snitselaar
Tested-by: Hector Martin
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/of_iommu.c | 49
1 file changed, 15 insertions(+), 34 deleti
Nothing needs this pointer. Return a normal error code with the usual
IOMMU semantic that ENODEV means 'there is no IOMMU driver'.
Reviewed-by: Jerry Snitselaar
Acked-by: Rob Herring
Tested-by: Hector Martin
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/of_iommu.c | 31
This API was defined to formalize the access to internal iommu details on
some Tegra SOCs, but a few callers got missed. Add them.
The helper already masks by 0x so remove this code from the callers.
Suggested-by: Thierry Reding
Signed-off-by: Jason Gunthorpe
---
drivers/dma/tegra186-gpc
The arm-smmu driver can COMPILE_TEST on x86, so expand this to also
enable the IORT code so it can be COMPILE_TEST'd too.
Signed-off-by: Jason Gunthorpe
---
drivers/acpi/Kconfig| 2 --
drivers/acpi/Makefile | 2 +-
drivers/acpi/arm64/Kconfig | 1 +
drivers/acpi/arm64/Makefile | 2
Allocation of dev->iommu must be done under the
iommu_probe_device_lock. Mark this with lockdep to discourage future
mistakes.
Reviewed-by: Jerry Snitselaar
Tested-by: Hector Martin
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/iommu.c | 2 ++
1 file changed, 2 insertions(+)
diff --
Snitselaar
Reviewed-by: Lu Baolu
Reviewed-by: Moritz Fischer
Acked-by: Christoph Hellwig
Acked-by: Rob Herring
Tested-by: Hector Martin
Signed-off-by: Jason Gunthorpe
---
arch/arc/mm/dma.c | 2 +-
arch/arm/mm/dma-mapping-nommu.c | 2 +-
arch/arm/mm/dma-mapping.c | 10
The iommu_device_lock protects the iommu_device_list which is only read by
iommu_ops_from_fwnode().
This is now always called under the iommu_probe_device_lock, so we don't
need to double lock the linked list. Use the iommu_probe_device_lock on
the write side too.
Signed-off-by: Jason Gunthorpe
=
DMA_BIT_MASK(ncomp->memory_address_limit);
Because DMA_BIT_MASK returns a large ULL constant. Explicitly truncate it
to phys_addr_t.
Signed-off-by: Jason Gunthorpe
---
drivers/acpi/arm64/iort.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/arm64/iort.
tin
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/amd/iommu.c | 2 --
drivers/iommu/apple-dart.c | 1 -
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 1 -
drivers/iommu/arm/arm-smmu/arm-smmu.c | 1 -
drivers/iommu/intel/iommu.c | 2 --
driv
Nothing needs this pointer. Return a normal error code with the usual
IOMMU semantic that ENODEV means 'there is no IOMMU driver'.
Acked-by: Rafael J. Wysocki
Reviewed-by: Jerry Snitselaar
Tested-by: Hector Martin
Signed-off-by: Jason Gunthorpe
---
drivers/acpi/scan.c | 29
ed to call tegra_dev_iommu_get_stream_id()
Jason Gunthorpe (10):
iommu: Remove struct iommu_ops *iommu from arch_setup_dma_ops()
iommmu/of: Do not return struct iommu_ops from of_iommu_configure()
iommu/of: Use -ENODEV consistently in of_iommu_configure()
iommu: Mark dev_iommu_get() with lockd
Signed-off-by: Jason Gunthorpe
---
arch/s390/include/asm/pci_dma.h | 5 +++--
arch/s390/pci/pci_dma.c | 31 +--
drivers/iommu/s390-iommu.c | 15 +--
3 files changed, 29 insertions(+), 22 deletions(-)
diff --git a/arch/s390/include/asm
Follow the pattern for iommu_map() and remove iommu_map_sg_atomic().
This allows __iommu_dma_alloc_noncontiguous() to use a GFP_KERNEL
allocation here, based on the provided gfp flags.
Reviewed-by: Kevin Tian
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/dma-iommu.c | 5 +++--
drivers
These contexts are sleepable, so use the proper annotation. The GFP_ATOMIC
was added mechanically in the prior patches.
Reviewed-by: Lu Baolu
Reviewed-by: Kevin Tian
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/intel/iommu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
The internal mechanisms support this, but instead of exposting the gfp to
the caller it wrappers it into iommu_map() and iommu_map_atomic()
Fix this instead of adding more variants for GFP_KERNEL_ACCOUNT.
Reviewed-by: Kevin Tian
Signed-off-by: Jason Gunthorpe
---
arch/arm/mm/dma-mapping.c
the iommu_domain. Many drivers will allocate these at
iommu_map() time and will trivially do the right thing if we pass in
GFP_KERNEL_ACCOUNT.
Reviewed-by: Kevin Tian
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/iommufd/pages.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
This is eventually called by iommufd through intel_iommu_map_pages() and
it should not be forced to atomic. Push the GFP_ATOMIC to all callers.
Reviewed-by: Kevin Tian
Reviewed-by: Lu Baolu
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/intel/iommu.c | 14 +++---
drivers/iommu/intel
These contexts are sleepable, so use the proper annotation. The GFP_ATOMIC
was added mechanically in the prior patches.
Reviewed-by: Niklas Schnelle
Reviewed-by: Matthew Rosato
Signed-off-by: Jason Gunthorpe
---
arch/s390/pci/pci_dma.c| 2 +-
drivers/iommu/s390-iommu.c | 2 +-
2 files
Flow it down to alloc_pgtable_page() via pfn_to_dma_pte() and
__domain_mapping().
Reviewed-by: Kevin Tian
Reviewed-by: Lu Baolu
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/intel/iommu.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers
There is only one call site and it can now just pass the GFP_ATOMIC to the
normal iommu_map().
Reviewed-by: Kevin Tian
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/dma-iommu.c | 2 +-
drivers/iommu/iommu.c | 7 ---
include/linux/iommu.h | 9 -
3 files changed, 1
https://lore.kernel.org/r/0-v1-6e8b3997c46d+89e-iommu_map_gfp_...@nvidia.com
Jason Gunthorpe (10):
iommu: Add a gfp parameter to iommu_map()
iommu: Remove iommu_map_atomic()
iommu: Add a gfp parameter to iommu_map_sg()
iommu/dma: Use the gfp parameter in __iommu_dma_alloc_
and
policy bits that are only relevant for the buffer allocation before
re-using them for internal allocations.
Auditing says this is never called from an atomic context, so the
GFP_ATOMIC is the incorrect flag.
Reviewed-by: Kevin Tian
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/dma-iommu.c
On Fri, Jan 20, 2023 at 07:28:19PM +, Robin Murphy wrote:
> Overall I'm starting to wonder if it might not be better to stick a "use
> GFP_KERNEL_ACCOUNT if you allocate" flag in the domain for any level of the
> API internals to pick up as appropriate, rather than propagate per-call gfp
>
On Fri, Jan 20, 2023 at 07:28:19PM +, Robin Murphy wrote:
> On 2023-01-18 18:00, Jason Gunthorpe wrote:
> > Change the sg_alloc_table_from_pages() allocation that was hardwired to
> > GFP_KERNEL to use the gfp parameter like the other allocations in this
> > function.
&
On Fri, Jan 20, 2023 at 10:24:55AM +0100, Joerg Roedel wrote:
> On Fri, Jan 06, 2023 at 01:24:11PM -0400, Jason Gunthorpe wrote:
> > I think it is just better to follow kernel convention and have
> > allocation functions include the GFP because it is a clear signal
the iommu wrappers
- Split out the new GFP_KERNEL usages into dedicated patches so it is
easier to check. No code change after the full series
v1: https://lore.kernel.org/r/0-v1-6e8b3997c46d+89e-iommu_map_gfp_...@nvidia.com
Jason Gunthorpe (10):
iommu: Add a gfp parameter to iommu_map()
iom
Flow it down to alloc_pgtable_page() via pfn_to_dma_pte() and
__domain_mapping().
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/intel/iommu.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel
The internal mechanisms support this, but instead of exposting the gfp to
the caller it wrappers it into iommu_map() and iommu_map_atomic()
Fix this instead of adding more variants for GFP_KERNEL_ACCOUNT.
Signed-off-by: Jason Gunthorpe
---
arch/arm/mm/dma-mapping.c | 11
Change the sg_alloc_table_from_pages() allocation that was hardwired to
GFP_KERNEL to use the gfp parameter like the other allocations in this
function.
Auditing says this is never called from an atomic context, so it is safe
as is, but reads wrong.
Signed-off-by: Jason Gunthorpe
---
drivers
This is eventually called by iommufd through intel_iommu_map_pages() and
it should not be forced to atomic. Push the GFP_ATOMIC to all callers.
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/intel/iommu.c | 14 +++---
drivers/iommu/intel/iommu.h | 2 +-
drivers/iommu/intel/pasid.c
These contexts are sleepable, so use the proper annotation. The GFP_ATOMIC
was added mechanically in the prior patches.
Reviewed-by: Niklas Schnelle
Signed-off-by: Jason Gunthorpe
---
arch/s390/pci/pci_dma.c| 2 +-
drivers/iommu/s390-iommu.c | 2 +-
2 files changed, 2 insertions(+), 2
the iommu_domain. Many drivers will allocate these at
iommu_map() time and will trivially do the right thing if we pass in
GFP_KERNEL_ACCOUNT.
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/iommufd/pages.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/iommufd
dma_alloc_cpu_table() and dma_alloc_page_table() are eventually called by
iommufd through s390_iommu_map_pages() and it should not be forced to
atomic. Thread the gfp parameter through the call chain starting from
s390_iommu_map_pages().
Reviewed-by: Niklas Schnelle
Signed-off-by: Jason
There is only one call site and it can now just pass the GFP_ATOMIC to the
normal iommu_map().
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/dma-iommu.c | 2 +-
drivers/iommu/iommu.c | 7 ---
include/linux/iommu.h | 9 -
3 files changed, 1 insertion(+), 17 deletions
These contexts are sleepable, so use the proper annotation. The GFP_ATOMIC
was added mechanically in the prior patches.
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/intel/iommu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers
Follow the pattern for iommu_map() and remove iommu_map_sg_atomic().
This allows __iommu_dma_alloc_noncontiguous() to use a GFP_KERNEL
allocation here, based on the provided gfp flags.
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/dma-iommu.c | 5 +++--
drivers/iommu/iommu.c | 26
On Wed, Jan 18, 2023 at 01:18:18AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Tuesday, January 17, 2023 9:30 PM
> >
> > On Tue, Jan 17, 2023 at 03:35:08AM +, Tian, Kevin wrote:
> > > > From: Jason Gunthorpe
> > &g
On Tue, Jan 17, 2023 at 03:35:08AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Saturday, January 7, 2023 12:43 AM
> >
> > @@ -2676,7 +2676,7 @@ static int copy_context_table(struct intel_iommu
> > *iommu,
> > if (!old_ce)
On Tue, Jan 17, 2023 at 03:38:51AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Saturday, January 7, 2023 12:43 AM
> >
> > @@ -2368,7 +2372,7 @@ static int iommu_domain_identity_map(struct
> > dmar_domain *domain,
> >
> >
On Fri, Jan 06, 2023 at 05:15:28PM +, Robin Murphy wrote:
> However, echoing the recent activity over on the DMA API side of things, I
> think it's still worth proactively constraining the set of permissible
> flags, lest we end up with more weird problems if stuff that doesn't really
> make
On Fri, Jan 06, 2023 at 05:15:28PM +, Robin Murphy wrote:
> On 2023-01-06 16:42, Jason Gunthorpe wrote:
> > The internal mechanisms support this, but instead of exposting the gfp to
> > the caller it wrappers it into iommu_map() and iommu_map_atomic()
> >
> > Fix
There is only one call site and it can now just pass the GFP_ATOMIC to the
normal iommu_map().
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/dma-iommu.c | 2 +-
drivers/iommu/iommu.c | 7 ---
include/linux/iommu.h | 9 -
3 files changed, 1 insertion(+), 17 deletions
dma_alloc_cpu_table() and dma_alloc_page_table() are eventually called by
iommufd through s390_iommu_map_pages() and it should not be forced to
atomic. Thread the gfp parameter through the call chain starting from
s390_iommu_map_pages().
Signed-off-by: Jason Gunthorpe
---
arch/s390/include/asm
Flow it down to alloc_pgtable_page() via pfn_to_dma_pte() and
__domain_mapping().
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/intel/iommu.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel
Change the sg_alloc_table_from_pages() allocation that was hardwired to
GFP_KERNEL to use the gfp parameter like the other allocations in this
function.
Auditing says this is never called from an atomic context, so it is safe
as is, but reads wrong.
Signed-off-by: Jason Gunthorpe
---
drivers
Follow the pattern for iommu_map() and remove iommu_map_sg_atomic().
This allows __iommu_dma_alloc_noncontiguous() to use a GFP_KERNEL
allocation here, based on the provided gfp flags.
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/dma-iommu.c | 5 +++--
drivers/iommu/iommu.c | 21
The internal mechanisms support this, but instead of exposting the gfp to
the caller it wrappers it into iommu_map() and iommu_map_atomic()
Fix this instead of adding more variants for GFP_KERNEL_ACCOUNT.
Signed-off-by: Jason Gunthorpe
---
arch/arm/mm/dma-mapping.c | 11
the iommu_domain. Many drivers will allocate these at
iommu_map() time and will trivially do the right thing if we pass in
GFP_KERNEL_ACCOUNT.
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/iommufd/pages.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/iommufd
P argument and always use GFP_ATOMIC. This is
problematic for iommufd anyhow, so fix it. AMD and ARM SMMUv2/3 are
already correct.
A follow up series will be needed to capture the allocations made when the
iommu_domain itself is allocated, which will complete the job.
Jason Gunthorpe (8):
iommu:
This is eventually called by iommufd through intel_iommu_map_pages() and
it should not be forced to atomic. Push the GFP_ATOMIC to all callers.
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/intel/iommu.c | 14 +++---
drivers/iommu/intel/iommu.h | 2 +-
drivers/iommu/intel/pasid.c
On Mon, Sep 26, 2022 at 04:03:06PM +1000, Alistair Popple wrote:
> Since 27674ef6c73f ("mm: remove the extra ZONE_DEVICE struct page
> refcount") device private pages have no longer had an extra reference
> count when the page is in use. However before handing them back to the
> owning device
On Wed, Feb 09, 2022 at 02:53:51PM +0100, Christoph Hellwig wrote:
> On Wed, Feb 09, 2022 at 08:29:56AM -0400, Jason Gunthorpe wrote:
> > It is nice, but the other series are still impacted by the fsdax mess
> > - they still stuff pages into ptes without proper refcounts and ha
On Wed, Feb 09, 2022 at 07:23:45AM +0100, Christoph Hellwig wrote:
> On Tue, Feb 08, 2022 at 07:30:11PM -0800, Dan Williams wrote:
> > Interesting. I had expected that to really fix the refcount problem
> > that fs/dax.c would need to start taking real page references as pages
> > were added to a
fs/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
Makes sense, but leaves me wonder why a kconfig randomizer didn't hit
this.. Or maybe it means some of the function stubs on !ZONE_DEVICE
are unnecessary now..
Reviewed-by: Jason Gunthorpe
Jason
> include/linux/mm.h | 20
> lib/test_hmm.c | 1 +
> mm/memremap.c | 6 +-
> 14 files changed, 34 insertions(+), 22 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
de/linux/mm.h | 34 ++
> mm/memremap.c | 20 +---
> mm/swap.c | 10 +-
> 3 files changed, 20 insertions(+), 44 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
-
> mm/memremap.c | 21 +
> mm/swap.c | 23 ---
> 3 files changed, 21 insertions(+), 24 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
On Mon, Feb 07, 2022 at 07:32:43AM +0100, Christoph Hellwig wrote:
> __KERNEL__ ifdefs don't make sense outside of include/uapi/.
>
> Signed-off-by: Christoph Hellwig
> ---
> include/linux/mm.h | 4
> 1 file changed, 4 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
eletions(-)
Reviewed-by: Jason Gunthorpe
Jason
-
> mm/memremap.c| 57
> mm/migrate.c | 6 ---
> mm/swap.c| 16 ++-
> 13 files changed, 36 insertions(+), 83 deletions(-)
It looks like a good next step to me
Reviewed
1 +
> drivers/gpu/drm/nouveau/nouveau_dmem.c | 1 +
> include/linux/hmm.h | 9 ++---
> lib/test_hmm.c | 2 ++
> 4 files changed, 6 insertions(+), 7 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
> Sorry for the noise.
Not at all, it is good that more people understand things!
Jason
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
On Tue, May 18, 2021 at 07:45:05PM -0400, Peter Xu wrote:
> On Tue, May 18, 2021 at 08:03:27PM -0300, Jason Gunthorpe wrote:
> > Logically during fork all these device exclusive pages should be
> > reverted back to their CPU pages, write protected and the CPU page PTE
> &g
On Tue, May 18, 2021 at 04:29:14PM -0400, Peter Xu wrote:
> On Tue, May 18, 2021 at 04:45:09PM -0300, Jason Gunthorpe wrote:
> > On Tue, May 18, 2021 at 02:01:36PM -0400, Peter Xu wrote:
> > > > > Indeed it'll be odd for a COW page since for COW page then it means
> >
On Tue, May 18, 2021 at 02:01:36PM -0400, Peter Xu wrote:
> > > Indeed it'll be odd for a COW page since for COW page then it means after
> > > parent/child writting to the page it'll clone into two, then it's a
> > > mistery on
> > > which one will be the one that "exclusived owned" by the
On Tue, May 18, 2021 at 01:27:42PM -0400, Peter Xu wrote:
> I also have a pure and high level question regarding a process fork() when
> there're device exclusive ptes: would the two processes then own the device
> together? Is this a real usecase?
If the pages are MAP_SHARED then yes. All VMAs
On Thu, Apr 01, 2021 at 01:20:05PM +1100, Alistair Popple wrote:
> On Thursday, 1 April 2021 11:48:13 AM AEDT Jason Gunthorpe wrote:
> > On Thu, Apr 01, 2021 at 11:45:57AM +1100, Alistair Popple wrote:
> > > On Thursday, 1 April 2021 12:46:04 AM AEDT Jason Gunthorpe wrote:
>
On Thu, Apr 01, 2021 at 11:45:57AM +1100, Alistair Popple wrote:
> On Thursday, 1 April 2021 12:46:04 AM AEDT Jason Gunthorpe wrote:
> > On Thu, Apr 01, 2021 at 12:27:52AM +1100, Alistair Popple wrote:
> > > On Thursday, 1 April 2021 12:18:54 AM AEDT Jason Gunthorpe wrote:
>
On Thu, Apr 01, 2021 at 12:27:52AM +1100, Alistair Popple wrote:
> On Thursday, 1 April 2021 12:18:54 AM AEDT Jason Gunthorpe wrote:
> > On Wed, Mar 31, 2021 at 11:59:28PM +1100, Alistair Popple wrote:
> >
> > > I guess that makes sense as the split could go either way a
On Wed, Mar 31, 2021 at 11:59:28PM +1100, Alistair Popple wrote:
> I guess that makes sense as the split could go either way at the
> moment but I should add a check to make sure this isn't used with
> pinned pages anyway.
Is it possible to have a pinned page under one of these things? If I
pin
On Wed, Mar 31, 2021 at 03:15:47PM +1100, Alistair Popple wrote:
> On Wednesday, 31 March 2021 2:56:38 PM AEDT John Hubbard wrote:
> > On 3/30/21 3:56 PM, Alistair Popple wrote:
> > ...
> > >> +1 for renaming "munlock*" items to "mlock*", where applicable. good
> grief.
> > >
> > > At least the
On Wed, Mar 31, 2021 at 09:09:30AM +1100, Alistair Popple wrote:
> > > @@ -1796,8 +1821,7 @@ bool try_to_unmap(struct page *page, enum ttu_flags
> flags)
> > > void try_to_munlock(struct page *page)
> > > {
> >
> > But this is also called try_to_munlock ??
>
> As far as I can tell this has
On Fri, Mar 26, 2021 at 11:08:02AM +1100, Alistair Popple wrote:
> diff --git a/mm/memory.c b/mm/memory.c
> index 3a5705cfc891..33d11527ef77 100644
> +++ b/mm/memory.c
> @@ -781,6 +781,27 @@ copy_nonpresent_pte(struct mm_struct *dst_mm, struct
> mm_struct *src_mm,
>
On Fri, Mar 26, 2021 at 11:08:00AM +1100, Alistair Popple wrote:
> +static bool try_to_munlock_one(struct page *page, struct vm_area_struct *vma,
> + unsigned long address, void *arg)
> +{
Is this function name right?
> + struct page_vma_mapped_walk pvmw = {
> +
emory.c | 10 +++---
> mm/migrate.c| 6 ++--
> mm/page_vma_mapped.c| 6 ++--
> 10 files changed, 50 insertions(+), 81 deletions(-)
Looks good
Reviewed-by: Jason Gunthorpe
> diff --git a/mm/hmm.c b/mm/hmm.c
> index 943cb2ba4442..3b2dda71d0ed 100644
>
On Tue, Mar 02, 2021 at 07:57:58PM +1100, Alistair Popple wrote:
> The intent was a driver could use HMM or some other mechanism to keep PTEs
> synchronised if required. However I just looked at patch 8 in the series
> again
> and it appears I got this wrong when converting from the old
On Fri, Feb 26, 2021 at 06:18:29PM +1100, Alistair Popple wrote:
> +/**
> + * make_device_exclusive_range() - Mark a range for exclusive use by a device
> + * @mm: mm_struct of assoicated target process
> + * @start: start of the region to mark for exclusive device access
> + * @end: end address
ols/testing/selftests/vm/hmm-tests.c | 219 +
> 3 files changed, 345 insertions(+)
Please get Ralph to review this, otherwise:
Acked-by: Jason Gunthorpe
Jason
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https
On Fri, Feb 26, 2021 at 06:18:29PM +1100, Alistair Popple wrote:
> Some devices require exclusive write access to shared virtual
> memory (SVM) ranges to perform atomic operations on that memory. This
> requires CPU page tables to be updated to deny access whilst atomic
> operations are occurring.
changed, 100 insertions(+), 62 deletions(-)
Reviewed-by: Jason Gunthorpe
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
On Fri, Feb 26, 2021 at 06:18:25PM +1100, Alistair Popple wrote:
> Remove the migration and device private entry_to_page() and
> entry_to_pfn() inline functions and instead open code them directly.
> This results in shorter code which is easier to understand.
>
> Signed-off-by: Alistair Popple
>
On Fri, Feb 26, 2021 at 06:18:27PM +1100, Alistair Popple wrote:
> The behaviour of try_to_unmap_one() is difficult to follow because it
> performs different operations based on a fairly large set of flags used
> in different combinations.
>
> TTU_MUNLOCK is one such flag. However it is
On Fri, Feb 19, 2021 at 09:47:41AM +, Christoph Hellwig wrote:
> > diff --git a/include/linux/hmm.h b/include/linux/hmm.h
> > index 866a0fa104c4..5d28ff6d4d80 100644
> > +++ b/include/linux/hmm.h
> > @@ -109,6 +109,10 @@ struct hmm_range {
> > */
> > int hmm_range_fault(struct hmm_range
On Tue, Feb 09, 2021 at 12:53:27PM -0800, John Hubbard wrote:
> This direction sounds at least...possible. Using MMU notifiers instead of pins
> is definitely appealing. I'm not quite clear on the callback idea above, but
> overall it seems like taking advantage of the ZONE_DEVICE tracking of
On Tue, Feb 09, 2021 at 04:17:38PM -0500, Jerome Glisse wrote:
> > > Yes, I would like to avoid the long term pin constraints as well if
> > > possible I
> > > just haven't found a solution yet. Are you suggesting it might be
> > > possible to
> > > add a callback in the page migration logic
On Wed, Feb 10, 2021 at 02:40:10PM +1100, Alistair Popple wrote:
> On Wednesday, 10 February 2021 12:39:32 AM AEDT Jason Gunthorpe wrote:
> > On Tue, Feb 09, 2021 at 12:07:14PM +1100, Alistair Popple wrote:
> > > Device private pages are used to represent device memory that is
On Tue, Feb 09, 2021 at 02:39:51PM +0100, Daniel Vetter wrote:
> Either way ZONE_DEVICE for not vram/device memory sounds wrong. Is
> that really going on here?
My read was this was doing non-coherent atomics on CPU memory.
Atomics on GPU memory is just called migration to GPU memory, it
1 - 100 of 345 matches
Mail list logo
