All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
To: "Christophe Leroy (CS GROUP)" <chleroy@kernel.org>,
	linuxppc-dev@lists.ozlabs.org
Cc: linux-mm@kvack.org, kvm@vger.kernel.org,
	Alex Williamson <alex@shazbot.org>, Peter Xu <peterx@redhat.com>
Subject: Re: [RFC v1 2/2] powerpc/64s: Add support for huge pfnmaps
Date: Sun, 01 Mar 2026 02:44:32 +0530	[thread overview]
Message-ID: <87tsv0in9j.ritesh.list@gmail.com> (raw)
In-Reply-To: <87pl5qh3ye.ritesh.list@gmail.com>

Ritesh Harjani (IBM) <ritesh.list@gmail.com> writes:

> "Christophe Leroy (CS GROUP)" <chleroy@kernel.org> writes:
>
>> Le 27/02/2026 à 07:16, Ritesh Harjani (IBM) a écrit :
>>> This uses _RPAGE_SW2 bit for the PMD and PUDs similar to PTEs.
>>> This also adds support for {pte,pmd,pud}_pgprot helpers needed for
>>> follow_pfnmap APIs.
>>> 
>>> This allows us to extend the PFN mappings, e.g. PCI MMIO bars where
>>> it can grow as large as 8GB or even bigger, to map at PMD / PUD level.
>>> VFIO PCI core driver already supports fault handling at PMD / PUD level
>>> for more efficient BAR mappings.
>>> 
>>> Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
>>
>> Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
>>
>>
>
> Thanks for the review!
>
>>>   #define __HAVE_ARCH_PMDP_SET_ACCESS_FLAGS
>>>   extern int pmdp_set_access_flags(struct vm_area_struct *vma,
>>> diff --git a/arch/powerpc/include/asm/pgtable.h b/arch/powerpc/include/asm/pgtable.h
>>> index dcd3a88caaf6..2d27cb1c2334 100644
>>> --- a/arch/powerpc/include/asm/pgtable.h
>>> +++ b/arch/powerpc/include/asm/pgtable.h
>>> @@ -63,6 +63,18 @@ static inline pgprot_t pte_pgprot(pte_t pte)
>>>   	return __pgprot(pte_flags);
>>>   }
>>> 
>>> +#define pmd_pgprot pmd_pgprot
>>> +static inline pgprot_t pmd_pgprot(pmd_t pmd)
>>> +{
>>> +	return pte_pgprot(pmd_pte(pmd));
>>> +}
>>> +
>>> +#define pud_pgprot pud_pgprot
>>> +static inline pgprot_t pud_pgprot(pud_t pud)
>>> +{
>>> +	return pte_pgprot(pud_pte(pud));
>>> +}
>>> +
>
> In v2 - I will add above under #ifdef CONFIG_PPC_BOOK3S_64 
> to avoid build issues with 32-bit PPC.
>

On second thoughts, I am thinking maybe we should guard it with CONFIG_PPC64.  
Currently the build fails on 32-bit since no definitions of pmd_pte()
and pud_pte().  Though, we could open-code that, but I think as of
today, this only gets excercised from follow_pfnmap_start() which gates
it with VM_PFNMAP | VM_IO, which I think could only happen for THP which
is only true for book3s/64. 
But to keep the generic definitions of pXd_pgprot() and since pmd_pte()
and pud_pte() are anyways available on book3s/64 & nohash/64, so let's
just guard this with PPC64.

I will amend this change in RFC-v2 and will keep the RB from Christophe.


+#ifdef CONFIG_PPC64
+#define pmd_pgprot pmd_pgprot
+static inline pgprot_t pmd_pgprot(pmd_t pmd)
+{
+       return pte_pgprot(pmd_pte(pmd));
+}
+
+#define pud_pgprot pud_pgprot
+static inline pgprot_t pud_pgprot(pud_t pud)
+{
+       return pte_pgprot(pud_pte(pud));
+}
+#endif /* CONFIG_PPC64 */
+


-ritesh


  reply	other threads:[~2026-02-28 21:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-27  6:16 [RFC v1 1/2] drivers/vfio_pci_core: Change PXD_ORDER check from switch case to if/else block Ritesh Harjani (IBM)
2026-02-27  6:16 ` [RFC v1 2/2] powerpc/64s: Add support for huge pfnmaps Ritesh Harjani (IBM)
2026-02-27  6:47   ` Christophe Leroy (CS GROUP)
2026-02-27 10:32     ` Ritesh Harjani
2026-02-28 21:14       ` Ritesh Harjani [this message]
2026-02-27  9:35   ` kernel test robot
2026-02-27  6:42 ` [RFC v1 1/2] drivers/vfio_pci_core: Change PXD_ORDER check from switch case to if/else block Christophe Leroy (CS GROUP)
2026-02-27 10:30   ` Ritesh Harjani

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=87tsv0in9j.ritesh.list@gmail.com \
    --to=ritesh.list@gmail.com \
    --cc=alex@shazbot.org \
    --cc=chleroy@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=peterx@redhat.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.