Looks good to me, thanks!
Reviewed-by: Alistair Popple
On Thursday, 27 September 2018 4:23:11 PM AEST Mark Hairgrove wrote:
> This threshold is no longer used now that all invalidates issue a single
> ATSD to each active NPU.
>
> Signed-off-by: Mark Hairgrove
> ---
> arch
Thanks, this looks good to me.
Reviewed-by: Alistair Popple
On Thursday, 27 September 2018 4:23:09 PM AEST Mark Hairgrove wrote:
> There are two types of ATSDs issued to the NPU: invalidates targeting a
> specific virtual address and invalidates targeting the whole address
> space
> >
> > We also support 4K page sizes on PPC. If I am not mistaken this means every
> > ATSD
> > would invalidate the entire GPU TLB for a the given PID on those systems.
> > Could
> > we change the above check to `if (size <= PAGE_64K)` to avoid this?
>
> PPC supports 4K pages but the GPU ATS
Reviewed-by: Alistair Popple
On Wednesday, 3 October 2018 11:51:32 AM AEST Mark Hairgrove wrote:
> There are two types of ATSDs issued to the NPU: invalidates targeting a
> specific virtual address and invalidates targeting the whole address
> space. In both cases prior to this ch
Reviewed-By: Alistair Popple
On Wednesday, 3 October 2018 11:51:33 AM AEST Mark Hairgrove wrote:
> Prior to this change only two types of ATSDs were issued to the NPU:
> invalidates targeting a single page and invalidates targeting the whole
> address space. The crossover point happen
Reviewed-by: Alistair Popple
On Wednesday, 3 October 2018 11:51:34 AM AEST Mark Hairgrove wrote:
> This threshold is no longer used now that all invalidates issue a single
> ATSD to each active NPU.
>
> Signed-off-by: Mark Hairgrove
> ---
> arch/powerpc/platforms/powern
Hi Alexey,
Looking at the skiboot side I think we only fence the NVLink bricks as part of a
PCIe function level reset (FLR) rather than a PCI Hot or Fundamental reset which
I believe is what the code here does. So to fence the bricks you would need to
do either a FLR on the given link or alter Ski
Hi Alexey,
On Tuesday, 16 October 2018 12:37:49 PM AEDT Alexey Kardashevskiy wrote:
>
> On 16/10/2018 11:38, Alistair Popple wrote:
> > Hi Alexey,
> >
> > Looking at the skiboot side I think we only fence the NVLink bricks as part
> > of a
> > PCIe function
> reset_ntl() does what npu2_dev_procedure_reset() does plus more stuff,
> there nothing really in npu2_dev_procedure_reset() which reset_ntl()
> does not do already from the hardware standpoint. And it did stop HMIs
> for me though.
>
> but ok, what will be sufficient then if not reset_ntl()?
Ar
On Tuesday, 16 October 2018 1:22:53 PM AEDT Alexey Kardashevskiy wrote:
>
> On 16/10/2018 13:19, Alistair Popple wrote:
> >> reset_ntl() does what npu2_dev_procedure_reset() does plus more stuff,
> >> there nothing really in npu2_dev_procedure_reset() which reset_ntl()
Hi Alexey,
> > wouldn't you also need to do that somewhere? Unless the driver
> > does it at startup?
>
> VFIO performs GPU reset so I'd expect the GPUs to flush its caches
> without any software interactions. Am I hoping for too much here?
Sadly you are. It's not the GPU caches that need flushi
into this but this fencing is
> still needed, is not it?
Yes. Although without the flushing I think you may get HMI's on any subsequent
driver loads.
So from the point of view of what happens on the Skiboot/HW side this looks ok
so long as all links on an NPU are assigned to
likely to go unnoticed.
It is instead simpler to remove these operations and let the generic
DMA code print warnings (eg. via a NULL pointer deref) in cases of
buggy drivers attempting dma operations on NVLink devices.
Signed-off-by: Alistair Popple
---
arch/powerpc/platforms/powernv/npu-dma.c
Reviewed-by: Alistair Popple
On Tuesday, 13 November 2018 7:28:06 PM AEDT Alexey Kardashevskiy wrote:
> This step is to help removing the npu struct from pnv_phb so it
> can be used by pseries as well.
>
> Signed-off-by: Alexey Kardashevskiy
> Reviewed-by: David Gibson
> -
Hi Alexey,
On Tuesday, 13 November 2018 7:28:07 PM AEDT Alexey Kardashevskiy wrote:
> static struct npu *npdev_to_npu(struct pci_dev *npdev)
> {
> - struct pnv_phb *nphb;
> + struct pci_controller *hose = pci_bus_to_host(npdev->bus);
> + struct npu *npu;
>
> - nphb = pci_bus_to_
> - /*
> - * Setup the NPU context table for a particular GPU. These need to be
> - * per-GPU as we need the tables to filter ATSDs when there are no
> - * active contexts on a particular GPU. It is safe for these to be
> - * called concurrently with destroy as the OPAL call
Thanks! Looks like a reasonable cleanup. Assuming it compiles I can't see any
reason not to add:
Acked-by: Alistair Popple
On Thursday, 29 November 2018 1:11:34 PM AEDT Alexey Kardashevskiy wrote:
> Ping?
>
> On 28/09/2018 16:48, Alexey Kardashevskiy wrote:
> > The macro
et_pte_at was
> > called later).
Thanks for the fixup. I didn't realise that invalidate_range() always gets
called but I now see that is the case so this change looks good to me as well.
Reviewed-by: Alistair Popple
> > All the necessary cache invalidation should all be
Hi Alexey,
On Wednesday, 11 July 2018 7:45:10 PM AEST Alexey Kardashevskiy wrote:
> On Thu, 7 Jun 2018 17:06:07 +1000
> Alexey Kardashevskiy wrote:
>
> > This brings NPU2 in a safe mode when it does not throw HMI if GPU
> > coherent memory is gone.
It might be helpful if you you could describe
investigate. However this patch
looks good.
Acked-by: Alistair Popple
> Signed-off-by: Reza Arbab
> ---
> arch/powerpc/platforms/powernv/npu-dma.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/platforms/powernv/npu-dma.c
> b/a
Acked-by: Alistair Popple
On Tuesday, 25 February 2020 10:31:42 AM AEDT Michael Ellerman wrote:
> The 4xx platforms are no longer maintained.
>
> Cc: Alistair Popple
> Cc: Matt Porter
> Signed-off-by: Michael Ellerman
> ---
> MAINTAINERS | 5 +
> 1 file ch
Nick,
On Tuesday, 3 September 2019 1:29:31 AM AEST Nicholas Piggin wrote:
> Introduce two options to control the use of the tlbie instruction. A
> boot time option which completely disables the kernel using the
> instruction, this is currently incompatible with HASH MMU, KVM, and
> coherent accele
Section 1.3.3.
Signed-off-by: Alistair Popple
Signed-off-by: Jordan Niethe
Tested-by: Joel Stanley
---
v2: Added some clarifications to the commit message
---
arch/powerpc/include/asm/reg.h | 3 +++
arch/powerpc/kernel/cpu_setup_power.S | 6 ++
arch/powerpc/kernel/dt_cpu_ftrs.c
fix. This fixes the build errors by updating the definitions to use
the __MASK() macro which selects the appropriate suffix.
Signed-off-by: Alistair Popple
---
arch/powerpc/include/asm/reg.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/reg.h b
on reserved bits in Section 1.3.3.
Signed-off-by: Alistair Popple
Signed-off-by: Jordan Niethe
Tested-by: Joel Stanley
---
arch/powerpc/include/asm/reg.h | 3 +++
arch/powerpc/kernel/cpu_setup_power.S | 6 ++
arch/powerpc/kernel/dt_cpu_ftrs.c | 3 ++-
arch/powerpc/kvm
Those definitions were introduced in a previous commit so I've posted a new
series to fix the definitions first. Thanks.
- Alistair
On Monday, 16 September 2019 7:49:26 PM AEST Michael Ellerman wrote:
> Alistair Popple writes:
> > Currently the reserved bits of the Processor
Reviewed-by: Alistair Popple
On Friday, 4 October 2019 12:53:17 PM AEST Jordan Niethe wrote:
> kvmhv_switch_to_host() in arch/powerpc/kvm/book3s_hv_rmhandlers.S needs
> to set kvmppc_vcore->in_guest to 0 to signal secondary CPUs to continue.
> This happens after resetting the PCR. B
_IMMEDIATE(r6, PCR_MASK)
> + cmpld r0, r6
> beq 18f
> - li r0, 0
> - mtspr SPRN_PCR, r0
> + mtspr SPRN_PCR, r6
> 18:
> /* Signal secondary CPUs to continue */
> stb r0,VCORE_IN_GUEST(r5)
Easy to understand h
ug is adopted.
The kernel TLB flushing functions may also need updating (see comments
in patch 2).
[1] - https://lore.kernel.org/all/20230602011518.787006-1-sea...@google.com/
[2] - https://lore.kernel.org/linux-mm/zjmr5bw8l+bbz...@ziepe.ca/
Alistair Popple (3):
mm_notifiers: Rename invalidate_
arch_invalidate_secondary_tlbs() and update documention.
Signed-off-by: Alistair Popple
Suggested-by: Jason Gunthorpe
---
arch/x86/mm/tlb.c | 1 +-
drivers/iommu/amd/iommu_v2.c| 10 +--
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 13 ++--
drivers/iommu
e notifier callback requires a non-NULL
mm_struct. Therefore these invalidations are already not happening and
it is assumed they are not required because IOMMUs are only attached
to userspace memory maps.
Signed-off-by: Alistair Popple
Suggested-by: Jason Gunthorpe
---
As this is an RFC I haven&#
() functions.
Signed-off-by: Alistair Popple
---
include/linux/mmu_notifier.h | 56 +
kernel/events/uprobes.c | 2 +-
mm/huge_memory.c | 25 ++---
mm/hugetlb.c | 2 +-
mm/memory.c | 8 +
mm
/lore.kernel.org/all/20230602011518.787006-1-sea...@google.com/
[2] - https://lore.kernel.org/linux-mm/zjmr5bw8l+bbz...@ziepe.ca/
Alistair Popple (4):
mm_notifiers: Rename invalidate_range notifier
arm64/smmu: Use TLBI ASID when invalidating entire range
mmu_notifiers: Call arch_invalidate_s
arch_invalidate_secondary_tlbs() and update documention.
Signed-off-by: Alistair Popple
Suggested-by: Jason Gunthorpe
---
arch/x86/mm/tlb.c | 1 +-
drivers/iommu/amd/iommu_v2.c| 10 +--
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 13 ++--
drivers/iommu
: Alistair Popple
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
index aa63cff..dbc812a 100644
--- a/drivers/iommu
the IOMMUs require this.
Signed-off-by: Alistair Popple
Suggested-by: Jason Gunthorpe
---
arch/arm64/include/asm/tlbflush.h | 5 +
arch/powerpc/include/asm/book3s/64/tlbflush.h | 1 +
arch/powerpc/mm/book3s64/radix_hugetlbpage.c | 1 +
arch/powerpc/mm/book3s64/radix_tlb.c
() functions.
Signed-off-by: Alistair Popple
---
include/linux/mmu_notifier.h | 56 +
kernel/events/uprobes.c | 2 +-
mm/huge_memory.c | 25 ++---
mm/hugetlb.c | 2 +-
mm/memory.c | 8 +
mm
Andrew Morton writes:
> On Tue, 18 Jul 2023 14:57:12 -0300 Jason Gunthorpe wrote:
>
>> On Tue, Jul 18, 2023 at 05:56:15PM +1000, Alistair Popple wrote:
>> > diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
>> > index b466172..48c81b9 100644
"Tian, Kevin" writes:
>> From: Anshuman Khandual
>> Sent: Wednesday, July 19, 2023 11:04 AM
>>
>> On 7/18/23 13:26, Alistair Popple wrote:
>> > The main change is to move secondary TLB invalidation mmu notifier
>> > callbacks into th
ired.
[1] - https://lore.kernel.org/all/20230602011518.787006-1-sea...@google.com/
[2] - https://lore.kernel.org/linux-mm/zjmr5bw8l+bbz...@ziepe.ca/
Alistair Popple (5):
arm64/smmu: Use TLBI ASID when invalidating entire range
mmu_notifiers: Fixup comment in mmu_interval_read_begin()
mmu_notifiers: Call i
: Alistair Popple
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
index a5a63b1..2a19784 100644
--- a/drivers/iommu
The comment in mmu_interval_read_begin() refers to a function that
doesn't exist and uses the wrong call-back name. The op for mmu
interval notifiers is mmu_interval_notifier_ops->invalidate() so fix
the comment up to reflect that.
Signed-off-by: Alistair Popple
---
mm/mmu_notifi
the IOMMUs require this.
Signed-off-by: Alistair Popple
Suggested-by: Jason Gunthorpe
---
arch/arm64/include/asm/tlbflush.h | 5 +
arch/powerpc/include/asm/book3s/64/tlbflush.h | 1 +
arch/powerpc/mm/book3s64/radix_hugetlbpage.c | 1 +
arch/powerpc/mm/book3s64/radix_tlb.c
() functions.
Signed-off-by: Alistair Popple
---
include/linux/mmu_notifier.h | 56 +
kernel/events/uprobes.c | 2 +-
mm/huge_memory.c | 25 ++---
mm/hugetlb.c | 1 +-
mm/memory.c | 8 +
mm
arch_invalidate_secondary_tlbs() and update documention.
Signed-off-by: Alistair Popple
Suggested-by: Jason Gunthorpe
---
arch/arm64/include/asm/tlbflush.h | 6 +-
arch/powerpc/mm/book3s64/radix_hugetlbpage.c| 2 +-
arch/powerpc/mm/book3s64/radix_tlb.c| 10 ++--
arch/x86/mm/tlb.c
SeongJae Park writes:
> Hi Alistair,
>
> On Wed, 19 Jul 2023 22:18:44 +1000 Alistair Popple wrote:
>
>> The invalidate_range() is going to become an architecture specific mmu
>> notifier used to keep the TLB of secondary MMUs such as an IOMMU in
>> sync with the
: Alistair Popple
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
index a5a63b1..2a19784 100644
--- a/drivers/iommu
.787006-1-sea...@google.com/
[2] - https://lore.kernel.org/linux-mm/zjmr5bw8l+bbz...@ziepe.ca/
Alistair Popple (5):
arm64/smmu: Use TLBI ASID when invalidating entire range
mmu_notifiers: Fixup comment in mmu_interval_read_begin()
mmu_notifiers: Call invalidate_range() when invalidating TLBs
m
The comment in mmu_interval_read_begin() refers to a function that
doesn't exist and uses the wrong call-back name. The op for mmu
interval notifiers is mmu_interval_notifier_ops->invalidate() so fix
the comment up to reflect that.
Signed-off-by: Alistair Popple
---
mm/mmu_notifi
the IOMMUs require this.
Signed-off-by: Alistair Popple
Suggested-by: Jason Gunthorpe
Tested-by: SeongJae Park
---
arch/arm64/include/asm/tlbflush.h | 5 +
arch/powerpc/include/asm/book3s/64/tlbflush.h | 1 +
arch/powerpc/mm/book3s64/radix_hugetlbpage.c | 1 +
arch/powerpc/m
() functions.
Signed-off-by: Alistair Popple
---
include/linux/mmu_notifier.h | 56 +
kernel/events/uprobes.c | 2 +-
mm/huge_memory.c | 25 ++---
mm/hugetlb.c | 1 +-
mm/memory.c | 8 +
mm
arch_invalidate_secondary_tlbs() and update documention.
Signed-off-by: Alistair Popple
Suggested-by: Jason Gunthorpe
---
arch/arm64/include/asm/tlbflush.h | 6 +-
arch/powerpc/mm/book3s64/radix_hugetlbpage.c| 2 +-
arch/powerpc/mm/book3s64/radix_tlb.c| 10 ++--
arch/x86/include
Luis Chamberlain writes:
>> diff --git a/arch/x86/include/asm/tlbflush.h
>> b/arch/x86/include/asm/tlbflush.h
>> index 837e4a50281a..79c46da919b9 100644
>> --- a/arch/x86/include/asm/tlbflush.h
>> +++ b/arch/x86/include/asm/tlbflush.h
>> @@ -4,6 +4,7 @@
>>
>> #include
>> #include
>> +#in
Michael Ellerman writes:
> Alistair Popple writes:
>> The invalidate_range() is going to become an architecture specific mmu
>> notifier used to keep the TLB of secondary MMUs such as an IOMMU in
>> sync with the CPU page tables. Currently it is called from separate
>
re.kernel.org/all/20230602011518.787006-1-sea...@google.com/
[2] - https://lore.kernel.org/linux-mm/zjmr5bw8l+bbz...@ziepe.ca/
Alistair Popple (5):
arm64/smmu: Use TLBI ASID when invalidating entire range
mmu_notifiers: Fixup comment in mmu_interval_read_begin()
mmu_notifiers: C
: Alistair Popple
Reviewed-by: Jason Gunthorpe
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
index a5a63b1
The comment in mmu_interval_read_begin() refers to a function that
doesn't exist and uses the wrong call-back name. The op for mmu
interval notifiers is mmu_interval_notifier_ops->invalidate() so fix
the comment up to reflect that.
Signed-off-by: Alistair Popple
Reviewed-by: Jason G
the IOMMUs require this.
Signed-off-by: Alistair Popple
Suggested-by: Jason Gunthorpe
Tested-by: SeongJae Park
Acked-by: Catalin Marinas
Reviewed-by: Jason Gunthorpe
---
arch/arm64/include/asm/tlbflush.h | 5 +
arch/powerpc/include/asm/book3s/64/tlbflush.h | 1 +
arch/
() functions.
Signed-off-by: Alistair Popple
Reviewed-by: Jason Gunthorpe
---
include/linux/mmu_notifier.h | 56 +
kernel/events/uprobes.c | 2 +-
mm/huge_memory.c | 25 ++---
mm/hugetlb.c | 1 +-
mm/memory.c
arch_invalidate_secondary_tlbs() and update documention.
Signed-off-by: Alistair Popple
Suggested-by: Jason Gunthorpe
Acked-by: Catalin Marinas
Reviewed-by: Jason Gunthorpe
---
arch/arm64/include/asm/tlbflush.h | 6 +-
arch/powerpc/mm/book3s64/radix_hugetlbpage.c| 2 +-
arch/powerpc/mm
"Huang, Ying" writes:
> Peter Xu writes:
>
>> On Thu, Aug 18, 2022 at 02:34:45PM +0800, Huang, Ying wrote:
>>> > In this specific case, the only way to do safe tlb batching in my mind is:
>>> >
>>> > pte_offset_map_lock();
>>> > arch_enter_lazy_mmu_mode();
>>> > // If any pending t
ock()
[ page is still accessible via stale TLB ]
flush_tlb_range()
In this case the page may still be accessed via the stale TLB entry
after madvise returns. Fix this by flushing the TLB while holding the
PTL.
Signed-off-by: Alistair Popple
Reported-by: Nadav Amit
Fixes: 8c3328f1f36a (
uently accessed.
Prevent this by copying the dirty bit to the page when removing the pte
to match what try_to_migrate_one() does.
Signed-off-by: Alistair Popple
Acked-by: Peter Xu
Reported-by: Huang Ying
Fixes: 8c3328f1f36a ("mm/migrate: migrate_vma() unmap page from vma while
collec
We were not correctly copying PTE dirty bits to pages during
migrate_vma_setup() calls. This could potentially lead to data loss, so
add a test for this.
Signed-off-by: Alistair Popple
---
tools/testing/selftests/vm/hmm-tests.c | 124 ++-
1 file changed, 124 insertions
David Hildenbrand writes:
> On 24.08.22 05:03, Alistair Popple wrote:
>> When clearing a PTE the TLB should be flushed whilst still holding the
>> PTL to avoid a potential race with madvise/munmap/etc. For example
>> consider the following sequence:
>>
>> C
Peter Xu writes:
> On Wed, Aug 24, 2022 at 04:25:44PM -0400, Peter Xu wrote:
>> On Wed, Aug 24, 2022 at 11:56:25AM +1000, Alistair Popple wrote:
>> > >> Still I don't know whether there'll be any side effect of having stall
>> > >> tlbs
>>
Alistair Popple writes:
> Peter Xu writes:
>>> But it's kind of against a pure "optimization" in that if trylock failed,
>>> we'll clear the mpfn so the src[i] will be zero at last. Then will we
>>> directly give up on this page, or will w
Peter Xu writes:
> On Thu, Aug 25, 2022 at 11:24:03AM +1000, Alistair Popple wrote:
>> By the way it's still an optimisation because in most cases we can avoid
>> calling try_to_migrate() and walking the rmap altogether if we install
>> the migration entries here.
Peter Xu writes:
> On Wed, Aug 24, 2022 at 01:03:38PM +1000, Alistair Popple wrote:
>> migrate_vma_setup() has a fast path in migrate_vma_collect_pmd() that
>> installs migration entries directly if it can lock the migrating page.
>> When removing a dirty pte the dirty
"Huang, Ying" writes:
> Alistair Popple writes:
>
>> When clearing a PTE the TLB should be flushed whilst still holding the
>> PTL to avoid a potential race with madvise/munmap/etc. For example
>> consider the following sequence:
>>
Peter Xu writes:
> On Fri, Aug 26, 2022 at 08:21:44AM +1000, Alistair Popple wrote:
>>
>> Peter Xu writes:
>>
>> > On Wed, Aug 24, 2022 at 01:03:38PM +1000, Alistair Popple wrote:
>> >> migrate_vma_setup() has a fast path in migrate_vma_collect_p
ock()
[ page is still accessible via stale TLB ]
flush_tlb_range()
In this case the page may still be accessed via the stale TLB entry
after madvise returns. Fix this by flushing the TLB while holding the
PTL.
Signed-off-by: Alistair Popple
Reported-by: Nadav Amit
Reviewed-by: "Hua
Currently we only call flush_cache_page() for the anon_exclusive case,
however in both cases we clear the pte so should flush the cache.
Signed-off-by: Alistair Popple
Fixes: 8c3328f1f36a ("mm/migrate: migrate_vma() unmap page from vma while
collecting pages")
Cc: sta...@vger.
uently accessed.
Prevent this by copying the dirty bit to the page when removing the pte
to match what try_to_migrate_one() does.
Signed-off-by: Alistair Popple
Acked-by: Peter Xu
Reviewed-by: "Huang, Ying"
Reported-by: "Huang, Ying"
Fixes: 8c3328f1f36a ("mm/migrate:
We were not correctly copying PTE dirty bits to pages during
migrate_vma_setup() calls. This could potentially lead to data loss, so
add a test for this.
Signed-off-by: Alistair Popple
---
tools/testing/selftests/vm/hmm-tests.c | 124 ++-
1 file changed, 124 insertions
John Hubbard writes:
> On 9/1/22 17:35, Alistair Popple wrote:
[...]
>> +/*
>> + * Try and migrate a dirty page that has previously been swapped to disk.
>> This
>> + * checks that we don't loose dirty bits.
>
> s/loose/lose/
Thanks.
>
John Hubbard writes:
> On 9/7/22 04:13, Alistair Popple wrote:
>>>> + /*
>>>> + * Attempt to migrate memory to device, which should fail because
>>>> + * hopefully some pages are backed by swap storage.
>>>> + */
>>>>
at it.
Signed-off-by: Alistair Popple
Fixes: 5cc88e844e87 ("selftests/hmm-tests: add test for dirty bits")
---
tools/testing/selftests/vm/hmm-tests.c | 50 +++---
1 file changed, 46 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/vm/hmm-tests.c
David Hildenbrand writes:
> On 13.09.22 07:22, Alistair Popple wrote:
>> As noted by John Hubbard the original test relied on side effects of the
>> implementation of migrate_vma_setup() to detect if pages had been
>> swapped to disk or not. This is subject to change in fu
at it.
Signed-off-by: Alistair Popple
Fixes: 5cc88e844e87 ("selftests/hmm-tests: add test for dirty bits")
Reviewed-by: Mika Penttilä
---
Changes for v2:
- Added Mika's Reviewed-by (Thanks!)
- Moved pagemap checks into vm_util.c as suggested by David H.
---
tools/testing/s
. Unfortunately I lack the
hardware to test on either of these so would appreciate it if someone with
access could test those.
Alistair Popple (7):
mm/memory.c: Fix race when faulting a device private page
mm: Free device private pages have zero refcount
mm/migrate_device.c: Refactor
o see
if it's expected or not.
Signed-off-by: Alistair Popple
---
arch/powerpc/kvm/book3s_hv_uvmem.c | 15 ++-
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 17 +++--
drivers/gpu/drm/amd/amdkfd/kfd_migrate.h | 2 +-
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 11 +--
ns such as
get_page_unless_zero().
Signed-off-by: Alistair Popple
---
arch/powerpc/kvm/book3s_hv_uvmem.c | 1 +
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 1 +
drivers/gpu/drm/nouveau/nouveau_dmem.c | 1 +
lib/test_hmm.c | 1 +
mm/memremap.c| 5
this
isn't true for device private memory, and a future change requires
similar functionality for device private memory. So refactor the code
into something more sensible for migrating device memory without a vma.
Signed-off-by: Alistair Popple
---
mm/migrate_device.c
n
free up device memory.
To allow that this patch introduces the migrate_device family of
functions which are functionally similar to migrate_vma but which skips
the initial lookup based on mapping.
Signed-off-by: Alistair Popple
---
include/linux/migrate.h | 7 +++-
mm/migrate_device.c
.
Refactor out the core functionality so that it is not specific to fault
handling.
Signed-off-by: Alistair Popple
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 59 +--
1 file changed, 29 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c
b
callbacks have all been freed.
Fix this by migrating any mappings back to normal CPU memory prior to
freeing the GPU memory chunks and associated device private pages.
Signed-off-by: Alistair Popple
---
I assume the AMD driver might have a similar issue. However I can't see
where device privat
Signed-off-by: Alistair Popple
---
lib/test_hmm.c | 119 +-
lib/test_hmm_uapi.h| 1 +-
tools/testing/selftests/vm/hmm-tests.c | 49 +++-
3 files changed, 148 insertions(+), 21 deletions(-)
diff --git a/lib/test_hmm.c
John Hubbard writes:
> On 9/26/22 14:35, Lyude Paul wrote:
>>> + for (i = 0; i < npages; i++) {
>>> + if (src_pfns[i] & MIGRATE_PFN_MIGRATE) {
>>> + struct page *dpage;
>>> +
>>> + /*
>>> +* _GFP_NOFAIL because the GPU is going
Felix Kuehling writes:
> On 2022-09-26 17:35, Lyude Paul wrote:
>> On Mon, 2022-09-26 at 16:03 +1000, Alistair Popple wrote:
>>> When the module is unloaded or a GPU is unbound from the module it is
>>> possible for device private pages to be left mapped in curr
Jason Gunthorpe writes:
> 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 u
Lyude Paul writes:
> On Mon, 2022-09-26 at 16:03 +1000, Alistair Popple wrote:
>> nouveau_dmem_fault_copy_one() is used during handling of CPU faults via
>> the migrate_to_ram() callback and is used to copy data from GPU to CPU
>> memory. It is currently specific to faul
Michael Ellerman writes:
> Alistair Popple writes:
>> When the CPU tries to access a device private page the migrate_to_ram()
>> callback associated with the pgmap for the page is called. However no
>> reference is taken on the faulting page. Therefore a concurrent
>&
Dan Williams writes:
> Alistair Popple wrote:
>>
>> Jason Gunthorpe writes:
>>
>> > On Mon, Sep 26, 2022 at 04:03:06PM +1000, Alistair Popple wrote:
>> >> Since 27674ef6c73f ("mm: remove the extra ZONE_DEVICE struct page
>> >>
counting to different counters as required.
A future change will extend this to also account against a cgroup for
pinned pages.
Signed-off-by: Alistair Popple
Cc: linux-ker...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-f...@vger.kernel.org
Cc: linux-r...@vger.kernel.org
Cc:
Convert from accounting pages against locked_vm to accounting them to
pinned_vm. This allows struct vm_account to be used to track the
mm_struct used to charge the pages. A future change also uses this to
track a cgroup for controlling pinned pages.
Signed-off-by: Alistair Popple
Cc: Michael
book3s_64_vio currently accounts for pinned pages with
account_locked_vm() which charges the pages to mm->locked_vm. To make
this consistent with other drivers switch to using
vm_account_pinned().
Signed-off-by: Alistair Popple
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Christophe Leroy
Jason Gunthorpe writes:
> On Tue, Jan 24, 2023 at 04:42:30PM +1100, Alistair Popple wrote:
>> +/**
>> + * enum vm_account_flags - Determine how pinned/locked memory is accounted.
>> + * @VM_ACCOUNT_TASK: Account pinned memory to mm->pinned_vm.
>> + * @VM_ACCOUNT_B
accounting to different counters as required.
A future change will extend this to also account against a cgroup for
pinned pages.
Signed-off-by: Alistair Popple
Cc: linux-ker...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-f...@vger.kernel.org
Cc: linux-r...@vger.kernel.org
Cc:
Convert from accounting pages against locked_vm to accounting them to
pinned_vm. This allows struct vm_account to be used to track the
mm_struct used to charge the pages. A future change also uses this to
track a cgroup for controlling pinned pages.
Signed-off-by: Alistair Popple
Cc: Michael
201 - 300 of 740 matches
Mail list logo
