sysfs.c | 2 +-
> drivers/usb/core/sysfs.c| 2 +-
> include/linux/sysfs.h | 30 +++---
> 12 files changed, 27 insertions(+), 26 deletions(-)
For infiniband:
Acked-by: Jason Gunthorpe
On Tue, Mar 19, 2024 at 01:36:51PM -0500, Timothy Pearson wrote:
> > On Tue, Mar 12, 2024 at 01:14:20PM -0500, Shivaprasad G Bhat wrote:
> >> The commit 090bad39b237a ("powerpc/powernv: Add indirect levels to
> >> it_userspace") which implemented the tce indirect levels
> >> support for PowerNV end
On Wed, May 22, 2024 at 11:13:53AM +1000, Nicholas Piggin wrote:
> From the mm/ side of things, hugetlb page tables are always walked via
> the huge vma which knows the page size and could align address... I
> guess except for fast gup? Which should be read-only. So okay you do
> need to replicate
On Fri, May 17, 2024 at 08:59:54PM +0200, Christophe Leroy wrote:
> This is the continuation of the RFC v1 series "Reimplement huge pages
> without hugepd on powerpc 8xx". It now get rid of hugepd completely
> after handling also e500 and book3s/64
This is really amazing, thank you for doing it!
On Sat, May 04, 2024 at 12:33:53AM +0530, Shivaprasad G Bhat wrote:
> We have legacy workloads using VFIO in userspace/kvm guests running
> on downstream distro kernels. We want these workloads to be able to
> continue running on our arch.
It has been broken since 2018, I don't find this reasoning
On Tue, Apr 30, 2024 at 03:05:34PM -0500, Shivaprasad G Bhat wrote:
> RFC v1 was posted here [1]. As I was testing more and fixing the
> issues, I realized its clean to have the table_group_ops implemented
> the way it is done on PowerNV and stop 'borrowing' the DMA windows
> for pSeries.
>
> This
On Fri, Apr 05, 2024 at 05:42:44PM -0400, Peter Xu wrote:
> In short, hugetlb mappings shouldn't be special comparing to other huge pXd
> and large folio (cont-pXd) mappings for most of the walkers in my mind, if
> not all. I need to look at all the walkers and there can be some tricky
> ones, but
On Thu, Apr 04, 2024 at 05:48:03PM -0400, Peter Xu wrote:
> On Tue, Mar 26, 2024 at 11:02:52AM -0300, Jason Gunthorpe wrote:
> > The more I look at this the more I think we need to get to Matthew's
> > idea of having some kind of generic page table API that is not tight
On Wed, Apr 03, 2024 at 06:24:38PM +, Christophe Leroy wrote:
> > If it is a software walker there might be value in just aligning to
> > the contig pte scheme in all levels and forgetting about the variable
> > size page table levels. That quarter page stuff is a PITA to manage
> > the memory
On Wed, Apr 03, 2024 at 02:25:20PM -0400, Peter Xu wrote:
> > I'd say the BUILD_BUG has done it's job and found an issue, fix it by
> > not defining pud_leaf? I don't see any calls to pud_leaf in loongarch
> > at least
>
> Yes, that sounds better too to me, however it means we may also risk other
On Wed, Apr 03, 2024 at 01:17:06PM +, Christophe Leroy wrote:
> > That commit makes it sounds like the arch supports huge PUD's through
> > the hugepte mechanism - it says a LTP test failed so something
> > populated a huge PUD at least??
>
> Not sure, I more see it just like a copy/paste of
On Wed, Apr 03, 2024 at 12:26:43PM +, Christophe Leroy wrote:
>
>
> Le 03/04/2024 à 14:08, Jason Gunthorpe a écrit :
> > On Tue, Apr 02, 2024 at 07:35:45PM -0400, Peter Xu wrote:
> >> On Tue, Apr 02, 2024 at 07:53:20PM -0300, Jason Gunthorpe wrote:
> >>>
On Tue, Apr 02, 2024 at 07:35:45PM -0400, Peter Xu wrote:
> On Tue, Apr 02, 2024 at 07:53:20PM -0300, Jason Gunthorpe wrote:
> > On Tue, Apr 02, 2024 at 06:43:56PM -0400, Peter Xu wrote:
> >
> > > I actually tested this without hitting the issue (even though I didn't
On Tue, Apr 02, 2024 at 06:43:56PM -0400, Peter Xu wrote:
> I actually tested this without hitting the issue (even though I didn't
> mention it in the cover letter..). I re-kicked the build test, it turns
> out my "make alldefconfig" on loongarch will generate a config with both
> HUGETLB=n && TH
d-off-by: David Hildenbrand
> ---
> mm/filemap.c| 2 +-
> mm/khugepaged.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
| 10 +-
> mm/internal.h | 2 +-
> 14 files changed, 22 insertions(+), 22 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
On Wed, Mar 27, 2024 at 09:58:35AM +, Christophe Leroy wrote:
> > Just general remarks on the ones with huge pages:
> >
> > hash 64k and hugepage 16M/16G
> > radix 64k/radix hugepage 2M/1G
> > radix 4k/radix hugepage 2M/1G
> > nohash 32
> >- I think this is just a normal x86 like s
ted() is already properly named
>
> With "gup_fast()", we now even have a function that is referred to in
> comment in mm/mmu_gather.c.
>
> Signed-off-by: David Hildenbrand
> ---
> mm/gup.c | 164 ++++---
> 1 file changed, 84 insertions(+), 80 deletions(-)
I think it is a great idea, it always takes a moment to figure out if
a function is part of the fast callchain or not..
(even better would be to shift the fast stuff into its own file, but I
expect that is too much)
Reviewed-by: Jason Gunthorpe
Jason
On Mon, Mar 25, 2024 at 07:05:01PM +, Christophe Leroy wrote:
> Not looked into details yet, but I guess so.
>
> By the way there is a wiki dedicated to huge pages on powerpc, you can
> have a look at it here :
> https://github.com/linuxppc/wiki/wiki/Huge-pages , maybe you'll find
> good i
On Mon, Mar 25, 2024 at 02:58:48PM -0400, Peter Xu wrote:
> > This remark would be a little easier to understand if you refer to
> > hugetlb_walk() not huge_pte_offset() - the latter is only used to
> > implement hugetlb_walk() and isn't removed by this series, while a
> > single hugetlb_walk() wa
On Mon, Mar 25, 2024 at 03:55:53PM +0100, Christophe Leroy wrote:
> This series reimplements hugepages with hugepd on powerpc 8xx.
>
> Unlike most architectures, powerpc 8xx HW requires a two-level
> pagetable topology for all page sizes. So a leaf PMD-contig approach
> is not feasible as such.
>
On Mon, Mar 25, 2024 at 03:55:57PM +0100, Christophe Leroy wrote:
> arch/arm64/include/asm/hugetlb.h | 2 +-
> fs/hugetlbfs/inode.c | 2 +-
> fs/proc/task_mmu.c | 8 +++---
> fs/userfaultfd.c | 2 +-
> include/asm-generic/hugetlb.h| 2 +-
> inclu
On Mon, Mar 25, 2024 at 03:55:54PM +0100, Christophe Leroy wrote:
> Unlike many architectures, powerpc 8xx hardware tablewalk requires
> a two level process for all page sizes, allthough second level only
> has one entry when pagesize is 8M.
>
> To fit with Linux page table topology and without re
On Thu, Mar 21, 2024 at 06:07:50PM -0400, pet...@redhat.com wrote:
> From: Peter Xu
>
> v3:
> - Rebased to latest mm-unstalbe (a824831a082f, of March 21th)
> - Dropped patch to introduce pmd_thp_or_huge(), replace such uses (and also
> pXd_huge() users) with pXd_leaf() [Jason]
> - Add a comment
On Fri, Mar 22, 2024 at 11:55:11AM -0400, Peter Xu wrote:
> Jason,
>
> On Fri, Mar 22, 2024 at 10:30:12AM -0300, Jason Gunthorpe wrote:
> > On Thu, Mar 21, 2024 at 06:08:02PM -0400, pet...@redhat.com wrote:
> >
> > > A quick performance test on an aarch64 V
ath. There are enough important cases where it is just reading
already populted page tables, and these days, often with large folios.
Reviewed-by: Jason Gunthorpe
Jason
toph Hellwig
> Cc: Lorenzo Stoakes
> Cc: Michael Ellerman
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Peter Xu
> ---
> mm/gup.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
stoph Hellwig
> Reviewed-by: Muchun Song
> Signed-off-by: Peter Xu
> ---
> include/linux/mm.h | 3 +++
> mm/memory.c| 12
> 2 files changed, 15 insertions(+)
is_vm_hugetlb_page(vma) seems weirdly named. Regardless
Reviewed-by: Jason Gunthorpe
Jason
On Tue, Mar 19, 2024 at 11:07:08PM +, Christophe Leroy wrote:
>
>
> Le 18/03/2024 à 17:15, Jason Gunthorpe a écrit :
> > On Thu, Mar 14, 2024 at 01:11:59PM +, Christophe Leroy wrote:
> >>
> >>
> >> Le 14/03/2024 à 13:53, Peter Xu a écrit :
>
On Tue, Mar 12, 2024 at 01:14:20PM -0500, Shivaprasad G Bhat wrote:
> The commit 090bad39b237a ("powerpc/powernv: Add indirect levels to
> it_userspace") which implemented the tce indirect levels
> support for PowerNV ended up removing the single level support
> which existed by default(generic tce
On Thu, Mar 14, 2024 at 08:59:22AM -0400, Peter Xu wrote:
> > > --- a/mm/hmm.c
> > > +++ b/mm/hmm.c
> > > @@ -429,7 +429,7 @@ static int hmm_vma_walk_pud(pud_t *pudp, unsigned
> > > long start, unsigned long end,
> > > return hmm_vma_walk_hole(start, end, -1, walk);
> > >
On Thu, Mar 14, 2024 at 01:11:59PM +, Christophe Leroy wrote:
>
>
> Le 14/03/2024 à 13:53, Peter Xu a écrit :
> > On Thu, Mar 14, 2024 at 08:45:34AM +, Christophe Leroy wrote:
> >>
> >>
> >> Le 13/03/2024 à 22:47, pet...@redhat.com a écrit :
> >>> From: Peter Xu
> >>>
> >>> PowerPC book3
th that the API is
> crystal clear on what it implies.
>
> Signed-off-by: Peter Xu
> ---
> include/linux/pgtable.h | 24 +++-
> 1 file changed, 19 insertions(+), 5 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
Time to merge them into one.
>
> Signed-off-by: Peter Xu
> ---
> mm/gup.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
Much better!
Reviewed-by: Jason Gunthorpe
Jason
ries, and it
> turns out that I am not the only one thinking so, the question was raised
> when the current pmd_huge() for x86 was proposed by Ville Syrjälä:
>
> https://lore.kernel.org/all/y2wq7i4lxh8iu...@intel.com/
>
> I might also be missing something obvious, but why is i
On Wed, Mar 06, 2024 at 06:41:37PM +0800, pet...@redhat.com wrote:
> From: Peter Xu
>
> Currently there should have no p4d swap entries so it may not matter much,
> however this may help us to rule out swap entries in pXd_huge() API, which
> will include p4d_huge(). The p4d_present() checks make
uge() to only report non-swap mappings for all archs.
>
> Cc: Alistair Popple
> Signed-off-by: Peter Xu
> ---
> mm/hmm.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
Reviewed-by: Jason Gunthorpe
> @@ -424,7 +424,7 @@ static int hmm_vma_walk_pud(pud_t *pu
t; Cc: Dave Hansen
> Cc: x...@kernel.org
> Signed-off-by: Peter Xu
> ---
> arch/x86/include/asm/pgtable.h | 4 ++--
> arch/x86/mm/pti.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
include/asm/pgtable.h | 8
> include/linux/pgtable.h | 8
> 6 files changed, 14 insertions(+), 14 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
| 19 +++
> 7 files changed, 16 insertions(+), 29 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
ibernate.c | 2 +-
> arch/x86/xen/mmu_pv.c | 4 ++--
> 20 files changed, 29 insertions(+), 29 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
> arch/x86/mm/pti.c| 4 ++--
> arch/x86/power/hibernate.c | 2 +-
> arch/x86/xen/mmu_pv.c| 4 ++--
> drivers/misc/sgi-gru/grufault.c | 2 +-
> 25 files changed, 49 insertions(+), 49 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
t; Cc: Dave Hansen
> Cc: x...@kernel.org
> Signed-off-by: Peter Xu
> ---
> arch/x86/include/asm/pgtable.h | 1 -
> include/asm-generic/pgtable-nopmd.h | 1 -
> 2 files changed, 2 deletions(-)
Reviewed-by: Jason Gunthorpe
> @@ -31,7 +31,6 @@ static inline int pud_none(pud
h/x86/mm/init_64.c| 2 +-
> arch/x86/mm/pat/set_memory.c | 4 ++--
> arch/x86/mm/pti.c| 2 +-
> arch/x86/power/hibernate.c | 2 +-
> arch/x86/xen/mmu_pv.c| 2 +-
> 6 files changed, 8 insertions(+), 8 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
+-
> arch/powerpc/mm/book3s64/radix_pgtable.c | 14 ++--
> arch/powerpc/mm/pgtable.c| 6 ++---
> arch/powerpc/mm/pgtable_64.c | 6 ++---
> arch/powerpc/xmon/xmon.c | 6 ++---
> 7 files changed, 26 insertions(+), 52 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Peter Xu
> ---
> arch/powerpc/include/asm/book3s/64/pgtable.h | 16 ++--
> arch/powerpc/include/asm/pgtable.h | 2 +-
> 2 files changed, 3 insertions(+), 15 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
On Wed, Feb 21, 2024 at 05:37:37PM +0800, Peter Xu wrote:
> On Mon, Jan 15, 2024 at 01:55:51PM -0400, Jason Gunthorpe wrote:
> > On Wed, Jan 03, 2024 at 05:14:13PM +0800, pet...@redhat.com wrote:
> > > From: Peter Xu
> > >
> > > ARM defines pmd_thp_or_huge(),
https://lore.kernel.org/all/274e0d2b-b5cc-475e-94e6-8427e88e2...@linux.vnet.ibm.com
> Signed-off-by: Shivaprasad G Bhat
> ---
> Changelog:
> v1:
> https://lore.kernel.org/all/170784021983.6249.10039296655906636112.st...@linux.ibm.com/
> - Minor refactor to call the iommu_group_get() only if required.
&
On Wed, Feb 14, 2024 at 11:53:20PM +1100, Michael Ellerman wrote:
> Venkat Rao Bagalkote writes:
> > Thanks for the patch. Applied this patch and verified and issue is fixed.
> >
> > This issue way originally reported in the below mail.
> >
> > https://marc.info/?l=linux-kernel&m=170737160630106&w
; The patch adds the missing iommu_group_put() call.
>
> Fixes: a8ca9fc9134c ("powerpc/iommu: Do not do platform domain attach
> atctions after probe")
> Signed-off-by: Shivaprasad G Bhat
> ---
> arch/powerpc/kernel/iommu.c |4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Doh, that is a weird splat for this but thanks for finding it
Reviewed-by: Jason Gunthorpe
Jason
s.stglab.ibm.com/
> - Split the common attach_dev call to platform and blocked attach_dev
>calls as suggested.
>
> arch/powerpc/kernel/iommu.c | 37 ++++-
> 1 file changed, 28 insertions(+), 9 deletions(-)
Reviewed-by: Jason Gunthorpe
> @@ -131
On Fri, Jan 26, 2024 at 09:39:56AM -0600, Timothy Pearson wrote:
> > Just forget about the weird KVM and SPAPR stuff, leave it under the
> > kconfig of the old code and nobody will run it. Almost nobody already
> > runs it, apparently.
>
> We actually use QEMU/KVM/VFIO extensively at Raptor, so ne
On Fri, Jan 26, 2024 at 09:29:55AM -0600, Timothy Pearson wrote:
> > On Fri, Jan 26, 2024 at 08:43:12PM +0530, Shivaprasad G Bhat wrote:
> >> > Also, is there any chance someone can work on actually fixing this to
> >> > be a proper iommu driver? I think that will become important for power
> >> >
On Fri, Jan 26, 2024 at 08:43:12PM +0530, Shivaprasad G Bhat wrote:
> > Also, is there any chance someone can work on actually fixing this to
> > be a proper iommu driver? I think that will become important for power
> > to use the common dma_iommu code in the next year...
> We are looking into it.
On Thu, Jan 25, 2024 at 06:08:52AM -0600, Shivaprasad G Bhat wrote:
> On PPC64, the iommu_ops.def_domain_type() is not defined and
> CONFIG_IOMMU_DMA not enabled. With commit 0f6a90436a57 ("iommu: Do not
> use IOMMU_DOMAIN_DMA if CONFIG_IOMMU_DMA is not enabled"), the
> iommu_get_default_domain_typ
On Thu, Jan 25, 2024 at 06:08:39AM -0600, Shivaprasad G Bhat wrote:
> The commit 2ad56efa80db ("powerpc/iommu: Setup a default domain and
> remove set_platform_dma_ops") refactored the code removing the
> set_platform_dma_ops(). It missed out the table group
> release_ownership() call which would h
On Tue, Jan 16, 2024 at 06:32:32PM +, Christophe Leroy wrote:
> >> hugepd is a page directory dedicated to huge pages, where you have huge
> >> pages listed instead of regular pages. For instance, on powerpc 32 with
> >> each PGD entries covering 4Mbytes, a regular page table has 1024 PTEs. A
>
On Tue, Jan 16, 2024 at 06:30:39AM +, Christophe Leroy wrote:
>
>
> Le 15/01/2024 à 19:37, Jason Gunthorpe a écrit :
> > On Wed, Jan 03, 2024 at 05:14:16PM +0800, pet...@redhat.com wrote:
> >> From: Peter Xu
> >>
> >> Hugepd format for GUP is only
huge_memory.c | 86 +
> mm/internal.h| 5 +--
> 3 files changed, 105 insertions(+), 93 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
return no_page_table(vma, flags, address);
Isn't 'pud_none() || !pud_present()' redundent? A none pud is
non-present, by definition?
> - if (pud_devmap(pud)) {
> + if (pud_huge(pud)) {
> ptl = pud_lock(mm, pudp);
> - page = follow_devmap_pud(vma, address, pudp, flags,
> &ctx->pgmap);
> + page = follow_huge_pud(vma, address, pudp, flags, ctx);
> spin_unlock(ptl);
> if (page)
> return page;
Otherwise it looks OK to me
Reviewed-by: Jason Gunthorpe
Jason
(+), 8 deletions(-)
I think we have several more case like this, and I ceratinly agree
code should not access a READ_ONCE variable more than once :(
Reviewed-by: Jason Gunthorpe
Jason
if VM_SHARED. See hugetlb_follow_page_mask().
>
> Pass "address" into no_page_table() too, as hugetlb will need it.
>
> Reviewed-by: Christoph Hellwig
> Signed-off-by: Peter Xu
> ---
> mm/gup.c | 44 ++--
> 1 file changed, 2
so that it will do the nth_page()
> calculation.
>
> Signed-off-by: Peter Xu
> ---
> mm/gup.c | 25 ++---
> 1 file changed, 14 insertions(+), 11 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
On Wed, Jan 03, 2024 at 05:14:16PM +0800, pet...@redhat.com wrote:
> From: Peter Xu
>
> Hugepd format for GUP is only used in PowerPC with hugetlbfs. There are
> some kernel usage of hugepd (can refer to hugepd_populate_kernel() for
> PPC_8XX), however those pages are not candidates for GUP.
>
asons even if !THP.
> Reorganize these macros.
>
> Reviewed-by: Christoph Hellwig
> Signed-off-by: Peter Xu
> ---
> include/linux/huge_mm.h | 17 ++---
> 1 file changed, 6 insertions(+), 11 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
On Wed, Jan 03, 2024 at 05:14:13PM +0800, pet...@redhat.com wrote:
> From: Peter Xu
>
> ARM defines pmd_thp_or_huge(), detecting either a THP or a huge PMD. It
> can be a helpful helper if we want to merge more THP and hugetlb code
> paths. Make it a generic default implementation, only exist w
comment in the kconfig?
Reviewed-by: Jason Gunthorpe
Jason
On Fri, Dec 01, 2023 at 04:51:55PM -0800, Sean Christopherson wrote:
> There's one more wrinkle: this patch is buggy in that it doesn't ensure the
> liveliness
> of KVM-the-module, i.e. nothing prevents userspace from unloading kvm.ko
> while VFIO
> still holds a reference to a kvm structure, an
On Wed, Nov 29, 2023 at 06:02:08PM -0800, Sean Christopherson wrote:
> > > Ah, it's the same warning, I just missed the CONFIG_MODULES=n requirement.
> >
> > Oh, wait, doesn't that mean the approach won't work? IIRC doesn't
> > symbol_get turn into just &fn when non-modular turning this into a
>
On Wed, Nov 29, 2023 at 05:07:45PM -0800, Sean Christopherson wrote:
> On Wed, Nov 29, 2023, Michael Ellerman wrote:
> > Sean Christopherson writes:
> > > On Fri, Nov 10, 2023, Michael Ellerman wrote:
> > >> Jason Gunthorpe writes:
> > >> > There ar
On Tue, Nov 28, 2023 at 06:21:42PM -0800, Sean Christopherson wrote:
> diff --git a/include/linux/vfio.h b/include/linux/vfio.h
> index 454e9295970c..a65b2513f8cd 100644
> --- a/include/linux/vfio.h
> +++ b/include/linux/vfio.h
> @@ -289,16 +289,12 @@ void vfio_combine_iova_ranges(struct rb_root_ca
On Fri, Nov 10, 2023 at 08:27:19PM +0530, Aneesh Kumar K V wrote:
> On 11/10/23 8:23 PM, Jason Gunthorpe wrote:
> > On Fri, Nov 10, 2023 at 08:19:23PM +0530, Aneesh Kumar K.V wrote:
> >>
> >> Hello,
> >>
> >> Some architectures can now support EX
On Fri, Nov 10, 2023 at 08:19:23PM +0530, Aneesh Kumar K.V wrote:
>
> Hello,
>
> Some architectures can now support EXEC_ONLY mappings and I am wondering
> what get_user_pages() on those addresses should return.
-EPERM
> Earlier PROT_EXEC implied PROT_READ and pte_access_permitted()
> returned
On Fri, Oct 06, 2023 at 06:50:00PM +0530, Tasmiya Nalatwad wrote:
>Greetings,
>
>Thanks Jason.
>
>The fix provided by you works. It is not giving WARNING's but i am
>seeing below logs. Would you please confirm on the logs.
I don't know anything about your environment but those lo
On Fri, Oct 06, 2023 at 01:20:17PM +0530, Tasmiya Nalatwad wrote:
> Greetings,
>
> [linux-next] [6.6.0-rc3-next-20230929] WARNING: CPU: 5 PID: 185612 at
> drivers/iommu/iommu.c:3049 iommu_setup_default_domain+0x410/0x680
>
> --- Traces ---
>
> [ 6296.425934] WARNING: CPU: 5 PID: 185612 at driver
Fixes: 2ad56efa80db ("powerpc/iommu: Setup a default domain and remove
set_platform_dma_ops")
Reported-by: Tasmiya Nalatwad
Link:
https://lore.kernel.org/r/d06cee81-c47f-9d62-dfc6-4c77b6005...@linux.vnet.ibm.com
Tested-by: Tasmiya Nalatwad
Signed-off-by: Jason Gunthorpe
---
arch/powerpc/ker
On Wed, Oct 04, 2023 at 04:37:10PM +0530, Tasmiya Nalatwad wrote:
>Greetings,
>
>[linux-next] [6.6.0-rc3-next-20230929] [git bisect ->
>2ad56efa80dba89162106c06ebc00b611325e584]WARNING: CPU: 0 PID: 8 at
>arch/powerpc/kernel/[1]iommu.c:407 __iommu_free+0x1e4/0x1f0
>gitbisect i
On Tue, Oct 03, 2023 at 12:21:59AM +0300, Dmitry Baryshkov wrote:
> On Wed, 13 Sept 2023 at 16:45, Jason Gunthorpe wrote:
> >
> > At this point every iommu driver will cause a default_domain to be
> > selected, so we can finally remove this gap from the core code.
> &
The global static should pre-define the type and the NOP free function can
be now left as NULL.
Reviewed-by: Lu Baolu
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
th Janne
- Move some hunks between patches to accommodate Robin's change to the
attach_dev switch
v1: https://lore.kernel.org/r/0-v1-8060f06462cc+c0a39-dart_paging_...@nvidia.com
Jason Gunthorpe (9):
iommu: Move IOMMU_DOMAIN_BLOCKED global statics to ops->blocked_domain
iommu/
domains from working,
remove that test.
The check in apple_dart_of_xlate() is redundant since immediately after
the pgsize is checked. Remove it.
Remove the variable.
Suggested-by: Janne Grunau
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/apple-dart.c | 20 ++--
1 file changed
Move the global static blocked domain to the ops and convert the unmanaged
domain to domain_alloc_paging.
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/iommufd/selftest.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/iommufd/selftest.c b
In many cases the dev argument will now be !NULL so we should use it to
finalize the domain at allocation.
Make apple_dart_finalize_domain() accept the correct type.
Reviewed-by: Janne Grunau
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/apple-dart.c | 28 +++-
1
Move to the new static global for identity domains. Move the identity
specific code to apple_dart_attach_dev_identity().
Reviewed-by: Janne Grunau
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/apple-dart.c | 39 +++---
1 file changed, 28 insertions(+), 11
Following the pattern of identity domains, just assign the BLOCKED domain
global statics to a value in ops. Update the core code to use the global
static directly.
Update powerpc to use the new scheme and remove its empty domain_alloc
callback.
Reviewed-by: Lu Baolu
Signed-off-by: Jason
Move to the new static global for blocked domains. Move the blocked
specific code to apple_dart_attach_dev_blocked().
Reviewed-by: Janne Grunau
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/apple-dart.c | 53 +++---
1 file changed, 32 insertions(+), 21
Since the IDENTITY and BLOCKED behaviors were moved to global statics all
that remains is the paging domain. Rename to
apple_dart_attach_dev_paging() and remove the left over type check.
Reviewed-by: Janne Grunau
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/apple-dart.c | 13
Trivially migrate to the ops->blocked_domain for the existing global
static.
Reviewed-by: Lu Baolu
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/intel/iommu.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iomm
On Tue, Sep 26, 2023 at 09:05:08PM +0200, Janne Grunau wrote:
> > +static int apple_dart_attach_dev_blocked(struct iommu_domain *domain,
> > +struct device *dev)
> > +{
> > + struct apple_dart_master_cfg *cfg = dev_iommu_priv_get(dev);
> > + struct apple_dart
On Mon, Sep 25, 2023 at 10:29:52AM +0800, Baolu Lu wrote:
> On 9/23/23 1:07 AM, Jason Gunthorpe wrote:
> > Trivially migrate to the ops->blocked_domain for the existing global
> > static.
> >
> > Signed-off-by: Jason Gunthorpe
> > ---
> > drivers/iommu/
Move to the new static global for identity domains. Move the identity
specific code to apple_dart_attach_dev_identity().
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/apple-dart.c | 41 --
1 file changed, 30 insertions(+), 11 deletions(-)
diff --git a
Since the IDENTITY and BLOCKED behaviors were moved to global statics all
that remains is the paging domain. Rename to
apple_dart_attach_dev_paging() and remove the left over cruft.
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/apple-dart.c | 33 +++--
1 file
Move to the new static global for blocked domains. Move the blocked
specific code to apple_dart_attach_dev_blocked().
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/apple-dart.c | 36 ++--
1 file changed, 26 insertions(+), 10 deletions(-)
diff --git a/drivers
In many cases the dev argument will now be !NULL so we should use it to
finalize the domain at allocation.
Make apple_dart_finalize_domain() accept the correct type.
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/apple-dart.c | 26 ++
1 file changed, 18 insertions
Move the global static blocked domain to the ops and convert the unmanaged
domain to domain_alloc_paging.
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/iommufd/selftest.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/iommufd/selftest.c b
Following the pattern of identity domains, just assign the BLOCKED domain
global statics to a value in ops. Update the core code to use the global
static directly.
Update powerpc to use the new scheme and remove its empty domain_alloc
callback.
Signed-off-by: Jason Gunthorpe
---
arch/powerpc
The global static should pre-define the type and the NOP free function can
be now left as NULL.
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/iommu/intel/iommu.c
index
Trivially migrate to the ops->blocked_domain for the existing global
static.
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/intel/iommu.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 0d0cb253497
n.c:.domain_alloc = fsl_pamu_domain_alloc,
drivers/iommu/intel/iommu.c:.domain_alloc =
intel_iommu_domain_alloc,
drivers/iommu/virtio-iommu.c: .domain_alloc = viommu_domain_alloc,
The follows the "Make default_domain's mandatory" series
Jason Gunthorpe
/202309030741.82alacdg-...@intel.com/
Closes:
https://lore.kernel.org/oe-kbuild-all/202309110914.qlh0lu6l-...@intel.com/
Cc: Nick Desaulniers
Fixes: c1cce6d079b8 ("vfio: Compile vfio_group infrastructure optionally")
Signed-off-by: Jason Gunthorpe
---
arch/arm64/kvm/Kconfig | 2 +-
1 - 100 of 559 matches
Mail list logo
