All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alistair Popple <apopple@nvidia.com>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: akpm@linux-foundation.org, ajd@linux.ibm.com,
	catalin.marinas@arm.com, fbarrat@linux.ibm.com,
	iommu@lists.linux.dev, jgg@ziepe.ca, jhubbard@nvidia.com,
	kevin.tian@intel.com, kvm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linuxppc-dev@lists.ozlabs.org, nicolinc@nvidia.com,
	npiggin@gmail.com, robin.murphy@arm.com, seanjc@google.com,
	will@kernel.org, x86@kernel.org, zhi.wang.linux@gmail.com
Subject: Re: [PATCH v2 3/5] mmu_notifiers: Call invalidate_range() when invalidating TLBs
Date: Tue, 25 Jul 2023 15:51:45 +1000	[thread overview]
Message-ID: <871qgwzgfa.fsf@nvdebian.thelocal> (raw)
In-Reply-To: <87y1j4y7w8.fsf@mail.lhotse>


Michael Ellerman <mpe@ellerman.id.au> writes:

> Alistair Popple <apopple@nvidia.com> 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
>> code paths to the main CPU TLB invalidations. This can lead to a
>> secondary TLB not getting invalidated when required and makes it hard
>> to reason about when exactly the secondary TLB is invalidated.
>>
>> To fix this move the notifier call to the architecture specific TLB
>> maintenance functions for architectures that have secondary MMUs
>> requiring explicit software invalidations.
>>
>> This fixes a SMMU bug on ARM64. On ARM64 PTE permission upgrades
>> require a TLB invalidation. This invalidation is done by the
>> arahitecutre specific ptep_set_access_flags() which calls
>   ^
>   architecture

Oh. I'd forgotten to apt install codespell ;-)
  
>> flush_tlb_page() if required. However this doesn't call the notifier
>> resulting in infinite faults being generated by devices using the SMMU
>> if it has previously cached a read-only PTE in it's TLB.
>>
>> Moving the invalidations into the TLB invalidation functions ensures
>> all invalidations happen at the same time as the CPU invalidation. The
>> architecture specific flush_tlb_all() routines do not call the
>> notifier as none of the IOMMUs require this.
>>
>> Signed-off-by: Alistair Popple <apopple@nvidia.com>
>> Suggested-by: Jason Gunthorpe <jgg@ziepe.ca>
>> 
> ...
>
>> diff --git a/arch/powerpc/mm/book3s64/radix_tlb.c b/arch/powerpc/mm/book3s64/radix_tlb.c
>> index 0bd4866..9724b26 100644
>> --- a/arch/powerpc/mm/book3s64/radix_tlb.c
>> +++ b/arch/powerpc/mm/book3s64/radix_tlb.c
>> @@ -752,6 +752,8 @@ void radix__local_flush_tlb_page(struct vm_area_struct *vma, unsigned long vmadd
>>  		return radix__local_flush_hugetlb_page(vma, vmaddr);
>>  #endif
>>  	radix__local_flush_tlb_page_psize(vma->vm_mm, vmaddr, mmu_virtual_psize);
>> +	mmu_notifier_invalidate_range(vma->vm_mm, vmaddr,
>> +						vmaddr + mmu_virtual_psize);
>>  }
>>  EXPORT_SYMBOL(radix__local_flush_tlb_page);
>
> I think we can skip calling the notifier there? It's explicitly a local flush.

I suspect you're correct. It's been a while since I last worked on PPC
TLB invalidation code though and it's changed a fair bit since then so
was being conservative and appreciate any comments there. Was worried I
may have missed some clever optimisation that detects a local flush is
all that's needed, but I see OCXL calls mm_context_add_copro() though so
that should be ok. Will respin and drop it.

> cheers


WARNING: multiple messages have this Message-ID (diff)
From: Alistair Popple <apopple@nvidia.com>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: kevin.tian@intel.com, x86@kernel.org, ajd@linux.ibm.com,
	kvm@vger.kernel.org, linux-mm@kvack.org, catalin.marinas@arm.com,
	seanjc@google.com, will@kernel.org, linux-kernel@vger.kernel.org,
	npiggin@gmail.com, zhi.wang.linux@gmail.com, jgg@ziepe.ca,
	iommu@lists.linux.dev, nicolinc@nvidia.com, jhubbard@nvidia.com,
	fbarrat@linux.ibm.com, akpm@linux-foundation.org,
	linuxppc-dev@lists.ozlabs.org,
	linux-arm-kernel@lists.infradead.org, robin.murphy@arm.com
Subject: Re: [PATCH v2 3/5] mmu_notifiers: Call invalidate_range() when invalidating TLBs
Date: Tue, 25 Jul 2023 15:51:45 +1000	[thread overview]
Message-ID: <871qgwzgfa.fsf@nvdebian.thelocal> (raw)
In-Reply-To: <87y1j4y7w8.fsf@mail.lhotse>


Michael Ellerman <mpe@ellerman.id.au> writes:

> Alistair Popple <apopple@nvidia.com> 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
>> code paths to the main CPU TLB invalidations. This can lead to a
>> secondary TLB not getting invalidated when required and makes it hard
>> to reason about when exactly the secondary TLB is invalidated.
>>
>> To fix this move the notifier call to the architecture specific TLB
>> maintenance functions for architectures that have secondary MMUs
>> requiring explicit software invalidations.
>>
>> This fixes a SMMU bug on ARM64. On ARM64 PTE permission upgrades
>> require a TLB invalidation. This invalidation is done by the
>> arahitecutre specific ptep_set_access_flags() which calls
>   ^
>   architecture

Oh. I'd forgotten to apt install codespell ;-)
  
>> flush_tlb_page() if required. However this doesn't call the notifier
>> resulting in infinite faults being generated by devices using the SMMU
>> if it has previously cached a read-only PTE in it's TLB.
>>
>> Moving the invalidations into the TLB invalidation functions ensures
>> all invalidations happen at the same time as the CPU invalidation. The
>> architecture specific flush_tlb_all() routines do not call the
>> notifier as none of the IOMMUs require this.
>>
>> Signed-off-by: Alistair Popple <apopple@nvidia.com>
>> Suggested-by: Jason Gunthorpe <jgg@ziepe.ca>
>> 
> ...
>
>> diff --git a/arch/powerpc/mm/book3s64/radix_tlb.c b/arch/powerpc/mm/book3s64/radix_tlb.c
>> index 0bd4866..9724b26 100644
>> --- a/arch/powerpc/mm/book3s64/radix_tlb.c
>> +++ b/arch/powerpc/mm/book3s64/radix_tlb.c
>> @@ -752,6 +752,8 @@ void radix__local_flush_tlb_page(struct vm_area_struct *vma, unsigned long vmadd
>>  		return radix__local_flush_hugetlb_page(vma, vmaddr);
>>  #endif
>>  	radix__local_flush_tlb_page_psize(vma->vm_mm, vmaddr, mmu_virtual_psize);
>> +	mmu_notifier_invalidate_range(vma->vm_mm, vmaddr,
>> +						vmaddr + mmu_virtual_psize);
>>  }
>>  EXPORT_SYMBOL(radix__local_flush_tlb_page);
>
> I think we can skip calling the notifier there? It's explicitly a local flush.

I suspect you're correct. It's been a while since I last worked on PPC
TLB invalidation code though and it's changed a fair bit since then so
was being conservative and appreciate any comments there. Was worried I
may have missed some clever optimisation that detects a local flush is
all that's needed, but I see OCXL calls mm_context_add_copro() though so
that should be ok. Will respin and drop it.

> cheers


  reply	other threads:[~2023-07-25  5:52 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-19 12:18 [PATCH v2 0/5] Invalidate secondary IOMMU TLB on permission upgrade Alistair Popple
2023-07-19 12:18 ` Alistair Popple
2023-07-19 12:18 ` Alistair Popple
2023-07-19 12:18 ` [PATCH v2 1/5] arm64/smmu: Use TLBI ASID when invalidating entire range Alistair Popple
2023-07-19 12:18   ` Alistair Popple
2023-07-19 12:18   ` Alistair Popple
2023-07-19 12:18 ` [PATCH v2 2/5] mmu_notifiers: Fixup comment in mmu_interval_read_begin() Alistair Popple
2023-07-19 12:18   ` Alistair Popple
2023-07-19 12:18   ` Alistair Popple
2023-07-19 12:18 ` [PATCH v2 3/5] mmu_notifiers: Call invalidate_range() when invalidating TLBs Alistair Popple
2023-07-19 12:18   ` Alistair Popple
2023-07-19 12:18   ` Alistair Popple
2023-07-19 22:51   ` SeongJae Park
2023-07-19 22:51     ` SeongJae Park
2023-07-19 22:51     ` SeongJae Park
2023-07-20  0:52     ` Alistair Popple
2023-07-20  0:52       ` Alistair Popple
2023-07-20  0:52       ` Alistair Popple
2023-07-20  1:31       ` SeongJae Park
2023-07-20  1:31         ` SeongJae Park
2023-07-20  1:31         ` SeongJae Park
2023-07-24 18:18       ` Luis Chamberlain
2023-07-24 18:18         ` Luis Chamberlain
2023-07-25  0:20         ` Alistair Popple
2023-07-25  0:20           ` Alistair Popple
2023-07-25  3:41   ` Michael Ellerman
2023-07-25  3:41     ` Michael Ellerman
2023-07-25  5:51     ` Alistair Popple [this message]
2023-07-25  5:51       ` Alistair Popple
2023-07-19 12:18 ` [PATCH v2 4/5] mmu_notifiers: Don't invalidate secondary TLBs as part of mmu_notifier_invalidate_range_end() Alistair Popple
2023-07-19 12:18   ` Alistair Popple
2023-07-19 12:18   ` Alistair Popple
2023-07-19 12:18 ` [PATCH v2 5/5] mmu_notifiers: Rename invalidate_range notifier Alistair Popple
2023-07-19 12:18   ` Alistair Popple
2023-07-19 12:18   ` Alistair Popple

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871qgwzgfa.fsf@nvdebian.thelocal \
    --to=apopple@nvidia.com \
    --cc=ajd@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=catalin.marinas@arm.com \
    --cc=fbarrat@linux.ibm.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@ziepe.ca \
    --cc=jhubbard@nvidia.com \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=nicolinc@nvidia.com \
    --cc=npiggin@gmail.com \
    --cc=robin.murphy@arm.com \
    --cc=seanjc@google.com \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    --cc=zhi.wang.linux@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.