[PATCH RFC 0/4] x86/fixmap: Unify FIXADDR_TOP

[PATCH RFC 0/4] x86/fixmap: Unify FIXADDR_TOP

[Hou Wenlong]

This patchset unifies FIXADDR_TOP as a variable for x86, allowing the
fixmap area to be movable and relocated with the kernel image in the
x86/PIE patchset [0]. This enables the kernel image to be relocated in
the top 512G of the address space.

[0] https://lore.kernel.org/lkml/cover.1682673542.git.houwenlong.hwl@antgroup.com

Hou Wenlong (4):
  x86/vsyscall: Don't use set_fixmap() to map vsyscall page
  x86/xen: Pin up to VSYSCALL_ADDR when vsyscall page is out of fixmap
    area
  x86/fixmap: Move vsyscall page out of fixmap area
  x86/fixmap: Unify FIXADDR_TOP

 arch/x86/entry/vsyscall/vsyscall_64.c |  7 +-----
 arch/x86/include/asm/fixmap.h         | 28 ++++-------------------
 arch/x86/include/asm/paravirt.h       |  7 ++++++
 arch/x86/include/asm/paravirt_types.h |  4 ++++
 arch/x86/include/asm/vsyscall.h       | 13 +++++++++++
 arch/x86/kernel/head64.c              |  1 -
 arch/x86/kernel/head_64.S             |  6 ++---
 arch/x86/kernel/paravirt.c            |  4 ++++
 arch/x86/mm/dump_pagetables.c         |  3 ++-
 arch/x86/mm/fault.c                   |  1 -
 arch/x86/mm/init_64.c                 |  2 +-
 arch/x86/mm/ioremap.c                 |  5 ++---
 arch/x86/mm/pgtable.c                 | 13 +++++++++++
 arch/x86/mm/pgtable_32.c              |  3 ---
 arch/x86/xen/mmu_pv.c                 | 32 +++++++++++++++++++--------
 15 files changed, 77 insertions(+), 52 deletions(-)


base-commit: f585d5177e1aad174fd6da0e3936b682ed58ced0
--
2.31.1

[PATCH RFC 1/4] x86/vsyscall: Don't use set_fixmap() to map vsyscall page

[Hou Wenlong]

In order to unify FIXADDR_TOP for x86 and allow the fixmap area to be
movable, the vsyscall page should be mapped individually. However, for
XENPV guests, the vsyscall page needs to be mapped into the user
pagetable as well. Therefore, a new PVMMU operation is introduced to
assist in mapping the vsyscall page.

Suggested-by: Lai Jiangshan <jiangshan.ljs@antgroup.com>
Signed-off-by: Hou Wenlong <houwenlong.hwl@antgroup.com>
---
 arch/x86/entry/vsyscall/vsyscall_64.c |  3 +--
 arch/x86/include/asm/paravirt.h       |  7 +++++++
 arch/x86/include/asm/paravirt_types.h |  4 ++++
 arch/x86/include/asm/vsyscall.h       | 13 +++++++++++++
 arch/x86/kernel/paravirt.c            |  4 ++++
 arch/x86/xen/mmu_pv.c                 | 20 ++++++++++++++------
 6 files changed, 43 insertions(+), 8 deletions(-)

diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c b/arch/x86/entry/vsyscall/vsyscall_64.c
index e0ca8120aea8..4373460ebbde 100644
--- a/arch/x86/entry/vsyscall/vsyscall_64.c
+++ b/arch/x86/entry/vsyscall/vsyscall_64.c
@@ -385,8 +385,7 @@ void __init map_vsyscall(void)
 	 * page.
 	 */
 	if (vsyscall_mode == EMULATE) {
-		__set_fixmap(VSYSCALL_PAGE, physaddr_vsyscall,
-			     PAGE_KERNEL_VVAR);
+		__set_vsyscall_page(physaddr_vsyscall, PAGE_KERNEL_VVAR);
 		set_vsyscall_pgtable_user_bits(swapper_pg_dir);
 	}
 
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index b49778664d2b..c9543d383df0 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -576,6 +576,13 @@ static inline void __set_fixmap(unsigned /* enum fixed_addresses */ idx,
 {
 	pv_ops.mmu.set_fixmap(idx, phys, flags);
 }
+
+#ifdef CONFIG_X86_VSYSCALL_EMULATION
+static inline void __set_vsyscall_page(phys_addr_t phys, pgprot_t flags)
+{
+	pv_ops.mmu.set_vsyscall_page(phys, flags);
+}
+#endif
 #endif
 
 #if defined(CONFIG_SMP) && defined(CONFIG_PARAVIRT_SPINLOCKS)
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index 4acbcddddc29..2dc9397e064d 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -224,6 +224,10 @@ struct pv_mmu_ops {
 	   an mfn.  We can tell which is which from the index. */
 	void (*set_fixmap)(unsigned /* enum fixed_addresses */ idx,
 			   phys_addr_t phys, pgprot_t flags);
+
+#ifdef CONFIG_X86_VSYSCALL_EMULATION
+	void (*set_vsyscall_page)(phys_addr_t phys, pgprot_t flags);
+#endif
 #endif
 } __no_randomize_layout;
 
diff --git a/arch/x86/include/asm/vsyscall.h b/arch/x86/include/asm/vsyscall.h
index ab60a71a8dcb..73691fc60924 100644
--- a/arch/x86/include/asm/vsyscall.h
+++ b/arch/x86/include/asm/vsyscall.h
@@ -2,6 +2,7 @@
 #ifndef _ASM_X86_VSYSCALL_H
 #define _ASM_X86_VSYSCALL_H
 
+#include <asm/pgtable.h>
 #include <linux/seqlock.h>
 #include <uapi/asm/vsyscall.h>
 
@@ -15,6 +16,18 @@ extern void set_vsyscall_pgtable_user_bits(pgd_t *root);
  */
 extern bool emulate_vsyscall(unsigned long error_code,
 			     struct pt_regs *regs, unsigned long address);
+static inline void native_set_vsyscall_page(phys_addr_t phys, pgprot_t flags)
+{
+	pgprot_val(flags) &= __default_kernel_pte_mask;
+	set_pte_vaddr(VSYSCALL_ADDR, pfn_pte(phys >> PAGE_SHIFT, flags));
+}
+
+#ifndef CONFIG_PARAVIRT_XXL
+#define __set_vsyscall_page	native_set_vsyscall_page
+#else
+#include <asm/paravirt.h>
+#endif
+
 #else
 static inline void map_vsyscall(void) {}
 static inline bool emulate_vsyscall(unsigned long error_code,
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index ac10b46c5832..13c81402f377 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -33,6 +33,7 @@
 #include <asm/tlb.h>
 #include <asm/io_bitmap.h>
 #include <asm/gsseg.h>
+#include <asm/vsyscall.h>
 
 /*
  * nop stub, which must not clobber anything *including the stack* to
@@ -357,6 +358,9 @@ struct paravirt_patch_template pv_ops = {
 	},
 
 	.mmu.set_fixmap		= native_set_fixmap,
+#ifdef CONFIG_X86_VSYSCALL_EMULATION
+	.mmu.set_vsyscall_page	= native_set_vsyscall_page,
+#endif
 #endif /* CONFIG_PARAVIRT_XXL */
 
 #if defined(CONFIG_PARAVIRT_SPINLOCKS)
diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index b3b8d289b9ab..c42c60faa3bb 100644
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -59,6 +59,7 @@
 
 #include <asm/tlbflush.h>
 #include <asm/fixmap.h>
+#include <asm/vsyscall.h>
 #include <asm/mmu_context.h>
 #include <asm/setup.h>
 #include <asm/paravirt.h>
@@ -2020,9 +2021,6 @@ static void xen_set_fixmap(unsigned idx, phys_addr_t phys, pgprot_t prot)
 
 	switch (idx) {
 	case FIX_BTMAP_END ... FIX_BTMAP_BEGIN:
-#ifdef CONFIG_X86_VSYSCALL_EMULATION
-	case VSYSCALL_PAGE:
-#endif
 		/* All local page mappings */
 		pte = pfn_pte(phys, prot);
 		break;
@@ -2058,14 +2056,21 @@ static void xen_set_fixmap(unsigned idx, phys_addr_t phys, pgprot_t prot)
 	vaddr = __fix_to_virt(idx);
 	if (HYPERVISOR_update_va_mapping(vaddr, pte, UVMF_INVLPG))
 		BUG();
+}
 
 #ifdef CONFIG_X86_VSYSCALL_EMULATION
+static void xen_set_vsyscall_page(phys_addr_t phys, pgprot_t prot)
+{
+	pte_t pte = pfn_pte(phys >> PAGE_SHIFT, prot);
+
+	if (HYPERVISOR_update_va_mapping(VSYSCALL_ADDR, pte, UVMF_INVLPG))
+		BUG();
+
 	/* Replicate changes to map the vsyscall page into the user
 	   pagetable vsyscall mapping. */
-	if (idx == VSYSCALL_PAGE)
-		set_pte_vaddr_pud(level3_user_vsyscall, vaddr, pte);
-#endif
+	set_pte_vaddr_pud(level3_user_vsyscall, VSYSCALL_ADDR, pte);
 }
+#endif
 
 static void __init xen_post_allocator_init(void)
 {
@@ -2156,6 +2161,9 @@ static const typeof(pv_ops) xen_mmu_ops __initconst = {
 		},
 
 		.set_fixmap = xen_set_fixmap,
+#ifdef CONFIG_X86_VSYSCALL_EMULATION
+		.set_vsyscall_page = xen_set_vsyscall_page,
+#endif
 	},
 };
 
-- 
2.31.1

[PATCH RFC 2/4] x86/xen: Pin up to VSYSCALL_ADDR when vsyscall page is out of fixmap area

[Hou Wenlong]

If the vsyscall page is moved out of the fixmap area, then FIXADDR_TOP
would be below the vsyscall page. Therefore, it should be pinned up to
VSYSCALL_ADDR if vsyscall is enabled.

Suggested-by: Lai Jiangshan <jiangshan.ljs@antgroup.com>
Signed-off-by: Hou Wenlong <houwenlong.hwl@antgroup.com>
---
 arch/x86/xen/mmu_pv.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index c42c60faa3bb..c1f298c31e64 100644
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -587,6 +587,12 @@ static void xen_p4d_walk(struct mm_struct *mm, p4d_t *p4d,
 	xen_pud_walk(mm, pud, func, last, limit);
 }
 
+#ifdef CONFIG_X86_VSYSCALL_EMULATION
+#define __KERNEL_MAP_TOP	(VSYSCALL_ADDR + PAGE_SIZE)
+#else
+#define __KERNEL_MAP_TOP	FIXADDR_TOP
+#endif
+
 /*
  * (Yet another) pagetable walker.  This one is intended for pinning a
  * pagetable.  This means that it walks a pagetable and calls the
@@ -594,7 +600,7 @@ static void xen_p4d_walk(struct mm_struct *mm, p4d_t *p4d,
  * at every level.  It walks the entire pagetable, but it only bothers
  * pinning pte pages which are below limit.  In the normal case this
  * will be STACK_TOP_MAX, but at boot we need to pin up to
- * FIXADDR_TOP.
+ * __KERNEL_MAP_TOP.
  *
  * We must skip the Xen hole in the middle of the address space, just after
  * the big x86-64 virtual hole.
@@ -609,7 +615,7 @@ static void __xen_pgd_walk(struct mm_struct *mm, pgd_t *pgd,
 
 	/* The limit is the last byte to be touched */
 	limit--;
-	BUG_ON(limit >= FIXADDR_TOP);
+	BUG_ON(limit >= __KERNEL_MAP_TOP);
 
 	/*
 	 * 64-bit has a great big hole in the middle of the address
@@ -797,7 +803,7 @@ static void __init xen_after_bootmem(void)
 #ifdef CONFIG_X86_VSYSCALL_EMULATION
 	SetPagePinned(virt_to_page(level3_user_vsyscall));
 #endif
-	xen_pgd_walk(&init_mm, xen_mark_pinned, FIXADDR_TOP);
+	xen_pgd_walk(&init_mm, xen_mark_pinned, __KERNEL_MAP_TOP);
 }
 
 static void xen_unpin_page(struct mm_struct *mm, struct page *page,
-- 
2.31.1

Re: [PATCH RFC 0/4] x86/fixmap: Unify FIXADDR_TOP

[Hou Wenlong]

On Mon, May 15, 2023 at 04:19:31PM +0800, Hou Wenlong wrote:
> This patchset unifies FIXADDR_TOP as a variable for x86, allowing the
> fixmap area to be movable and relocated with the kernel image in the
> x86/PIE patchset [0]. This enables the kernel image to be relocated in
> the top 512G of the address space.
> 
> [0] https://lore.kernel.org/lkml/cover.1682673542.git.houwenlong.hwl@antgroup.com
> 
> Hou Wenlong (4):
>   x86/vsyscall: Don't use set_fixmap() to map vsyscall page
>   x86/xen: Pin up to VSYSCALL_ADDR when vsyscall page is out of fixmap
>     area
>   x86/fixmap: Move vsyscall page out of fixmap area
>   x86/fixmap: Unify FIXADDR_TOP
> 
>  arch/x86/entry/vsyscall/vsyscall_64.c |  7 +-----
>  arch/x86/include/asm/fixmap.h         | 28 ++++-------------------
>  arch/x86/include/asm/paravirt.h       |  7 ++++++
>  arch/x86/include/asm/paravirt_types.h |  4 ++++
>  arch/x86/include/asm/vsyscall.h       | 13 +++++++++++
>  arch/x86/kernel/head64.c              |  1 -
>  arch/x86/kernel/head_64.S             |  6 ++---
>  arch/x86/kernel/paravirt.c            |  4 ++++
>  arch/x86/mm/dump_pagetables.c         |  3 ++-
>  arch/x86/mm/fault.c                   |  1 -
>  arch/x86/mm/init_64.c                 |  2 +-
>  arch/x86/mm/ioremap.c                 |  5 ++---
>  arch/x86/mm/pgtable.c                 | 13 +++++++++++
>  arch/x86/mm/pgtable_32.c              |  3 ---
>  arch/x86/xen/mmu_pv.c                 | 32 +++++++++++++++++++--------
>  15 files changed, 77 insertions(+), 52 deletions(-)
> 
> 
> base-commit: f585d5177e1aad174fd6da0e3936b682ed58ced0
> --
> 2.31.1
Hi,

Just wanted to send a kind ping on this patchset.

Thanks.

Re: [PATCH RFC 0/4] x86/fixmap: Unify FIXADDR_TOP

[Dave Hansen]

On 5/15/23 01:19, Hou Wenlong wrote:
> This patchset unifies FIXADDR_TOP as a variable for x86, allowing the
> fixmap area to be movable and relocated with the kernel image in the
> x86/PIE patchset [0]. This enables the kernel image to be relocated in
> the top 512G of the address space.

What problems does this patch set solve?  How might that solution be
visible to end users?  Why is this problem important to you?

Also, while you're waiting for someone to review _your_ code, have you
considered reviewing anyone else's code?  I don't think I've seen any
review activity from you lately.

Re: [PATCH RFC 0/4] x86/fixmap: Unify FIXADDR_TOP

[Thomas Gleixner]

On Mon, May 15 2023 at 16:19, Hou Wenlong wrote:

> This patchset unifies FIXADDR_TOP as a variable for x86, allowing the
> fixmap area to be movable and relocated with the kernel image in the
> x86/PIE patchset [0]. This enables the kernel image to be relocated in
> the top 512G of the address space.

What for? What's the use case.

Please provide a proper argument why this is generally useful and
important.

Thanks,

        tglx

Re: [PATCH RFC 0/4] x86/fixmap: Unify FIXADDR_TOP

[Hou Wenlong]

On Wed, Jun 07, 2023 at 08:49:15PM +0800, Dave Hansen wrote:
> On 5/15/23 01:19, Hou Wenlong wrote:
> > This patchset unifies FIXADDR_TOP as a variable for x86, allowing the
> > fixmap area to be movable and relocated with the kernel image in the
> > x86/PIE patchset [0]. This enables the kernel image to be relocated in
> > the top 512G of the address space.
> 
> What problems does this patch set solve?  How might that solution be
> visible to end users?  Why is this problem important to you?
> 
> Also, while you're waiting for someone to review _your_ code, have you
> considered reviewing anyone else's code?  I don't think I've seen any
> review activity from you lately.

Hello,

Sorry for bothering you. This patch is not important; it is just a part
of our PIE patchset. I should be more patient.

We want to build the kernel as PIE and allow the kernel image area,
including the fixmap area, to be placed at any virtual address. We have
also implemented a PV Linux guest based on PIE, which can be used in
software virtualization similar to Lguest. PIE makes the guest kernel
share the host kernel space similar to a normal userspace process.
Additionally, we are considering whether it is possible to use PIE and
PVOPS to implement a user-mode kernel.

Thank you for your advice. I will participate more actively in community
review activities. Sorry again for bothering you.

Thanks.

Re: [PATCH RFC 0/4] x86/fixmap: Unify FIXADDR_TOP

[Thomas Gleixner]

On Thu, Jun 08 2023 at 17:33, Hou Wenlong wrote:
> On Wed, Jun 07, 2023 at 08:49:15PM +0800, Dave Hansen wrote:
>> What problems does this patch set solve?  How might that solution be
>> visible to end users?  Why is this problem important to you?
>
> We want to build the kernel as PIE and allow the kernel image area,
> including the fixmap area, to be placed at any virtual address.

You are still failing to tell us why you want that and which problem
this solves. Just that fact that you want to something is not an
argument.

> We have also implemented a PV Linux guest based on PIE, which can be
> used in software virtualization similar to Lguest. PIE makes the guest
> kernel share the host kernel space similar to a normal userspace
> process.  Additionally, we are considering whether it is possible to
> use PIE and PVOPS to implement a user-mode kernel.

That solves what?

Thanks,

        tglx