Re: [PATCHv3 4/4] x86/paravirt: Restrict PARAVIRT_XXL to 64-bit only

Re: [PATCHv3 4/4] x86/paravirt: Restrict PARAVIRT_XXL to 64-bit only

[Jürgen Groß]

[-- Attachment #1.1.1: Type: text/plain, Size: 395 bytes --]

On 16.05.25 14:33, Kirill A. Shutemov wrote:
> PARAVIRT_XXL is exclusively utilized by XEN_PV, which is only compatible
> with 64-bit machines.
> 
> Clearly designate PARAVIRT_XXL as 64-bit only and remove ifdefs to
> support CONFIG_PGTABLE_LEVELS < 5.
> 
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>

Reviewed-by: Juergen Gross <jgross@suse.com>


Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [PATCHv3 0/4] x86: Make 5-level paging support unconditional for x86-64

[Ingo Molnar]

* Kirill A. Shutemov <kirill.shutemov@linux.intel.com> wrote:

> Both Intel and AMD CPUs support 5-level paging, which is expected to
> become more widely adopted in the future.
> 
> Remove CONFIG_X86_5LEVEL.
> 
> In preparation to that remove CONFIG_DYNAMIC_MEMORY_LAYOUT and make
> SPARSEMEM_VMEMMAP the only memory model.
> 
> v3:
>  - Drop few "#if CONFIG_PGTABLE_LEVELS >= 5";
>  - Make PARAVIRT_XXL 64-bit explicitly and drop ifdefs
>    to support PGTABLE_LEVELS < 5;
>  - Add Reviewed-by tags from Ard;
> v2:
>  - Fix 32-bit build by wrapping p4d_set_huge() and p4d_clear_huge() in
>    #if CONFIG_PGTABLE_LEVELS > 4;
>  - Rebased onto current tip/master;

Wow, -v1 was sent almost a year ago. :-)

> Kirill A. Shutemov (4):
>   x86/64/mm: Always use dynamic memory layout
>   x86/64/mm: Make SPARSEMEM_VMEMMAP the only memory model
>   x86/64/mm: Make 5-level paging support unconditional
>   x86/paravirt: Restrict PARAVIRT_XXL to 64-bit only

>  24 files changed, 14 insertions(+), 142 deletions(-)

Okay, this series makes a lot of sense, because in practice all major 
distros have 5-level paging enabled:

  .config.opensuse.default:     CONFIG_X86_5LEVEL=y
  .config.ubuntu.localinstall:  CONFIG_X86_5LEVEL=y
  .config.fedora.generic:       CONFIG_X86_5LEVEL=y
  .config.rhel.generic:         CONFIG_X86_5LEVEL=y

So the !CONFIG_X86_5LEVEL case gets very little runtime testing by 
distributions and users.

So I've applied the first two patches to tip:x86/core:

  x86/mm/64: Always use dynamic memory layout
  x86/mm/64: Make SPARSEMEM_VMEMMAP the only memory model

as they are fairly straightforward.

Patch #3:

  x86/64/mm: Make 5-level paging support unconditional

... might have to wait until after v6.16-rc1, as it's a higher risk 
patch.

  x86/paravirt: Restrict PARAVIRT_XXL to 64-bit only

... and this one depends on patch #3.

Does this approach sound good to everyone?

Thanks,

	Ingo

Re: [PATCHv3 0/4] x86: Make 5-level paging support unconditional for x86-64

[Kirill A. Shutemov]

On Fri, May 16, 2025 at 03:11:14PM +0200, Ingo Molnar wrote:
> Does this approach sound good to everyone?

Sounds good to me.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov

Re: [PATCHv3 2/4] x86/64/mm: Make SPARSEMEM_VMEMMAP the only memory model

[Dave Hansen]

On 5/16/25 05:33, Kirill A. Shutemov wrote:
> 5-level paging only supports SPARSEMEM_VMEMMAP. CONFIG_X86_5LEVEL is
> being phased out, making 5-level paging support mandatory.
> 
> Make CONFIG_SPARSEMEM_VMEMMAP mandatory for x86-64 and eliminate
> any associated conditional statements.
I think we have ourselves a catch-22 here.

SPARSEMEM_VMEMMAP was selected because the other sparsemem modes
couldn't handle a dynamic MAX_PHYS{MEM,ADDR}_BITS introduced by 5-level
paging. Now you're proposing making it static again, but keeping the
SPARSEMEM_VMEMMAP dependency.

If you remove the dynamic MAX_PHYS{MEM,ADDR}_BITS, you should also
remove the dependency on SPARSEMEM_VMEMMAP. No?

Re: [PATCHv3 2/4] x86/64/mm: Make SPARSEMEM_VMEMMAP the only memory model

[Ingo Molnar]

* Dave Hansen <dave.hansen@intel.com> wrote:

> On 5/16/25 05:33, Kirill A. Shutemov wrote:
> > 5-level paging only supports SPARSEMEM_VMEMMAP. CONFIG_X86_5LEVEL is
> > being phased out, making 5-level paging support mandatory.
> > 
> > Make CONFIG_SPARSEMEM_VMEMMAP mandatory for x86-64 and eliminate
> > any associated conditional statements.
> I think we have ourselves a catch-22 here.
> 
> SPARSEMEM_VMEMMAP was selected because the other sparsemem modes
> couldn't handle a dynamic MAX_PHYS{MEM,ADDR}_BITS introduced by 5-level
> paging. Now you're proposing making it static again, but keeping the
> SPARSEMEM_VMEMMAP dependency.
> 
> If you remove the dynamic MAX_PHYS{MEM,ADDR}_BITS, you should also
> remove the dependency on SPARSEMEM_VMEMMAP. No?

Isn't it the other way around? MAX_PHYS{MEM,ADDR}_BITS are now *always* 
dynamic, their value depending on whether LA57 is available and used.

Thanks,

	Ingo

Re: [PATCHv3 2/4] x86/64/mm: Make SPARSEMEM_VMEMMAP the only memory model

[Dave Hansen]

On 5/16/25 06:45, Ingo Molnar wrote:
> Isn't it the other way around? MAX_PHYS{MEM,ADDR}_BITS are now *always* 
> dynamic, their value depending on whether LA57 is available and used.

MAX_PHYS{MEM,ADDR}_BITS were always intended to be the compile-time
maximums on the architecture. They're static on every architecture
except x86 and some arm64 configs (who probably copied x86).

That's why having them be dynamic broke non-vmemmap sparsemem.

But we also seems to have defined MAXMEM to derive from MAX_PHYSMEM_BITS
and MAXMEM cascades into a bunch of other stuff, including KASAN. So we
can't just make them static again, I guess.

The only option would be to make them static when using non-vmemmap
sparsemem. But that's new-ish, and probably won't get any testing.

I guess there's not much we can do about it.

Re: [PATCHv3 2/4] x86/64/mm: Make SPARSEMEM_VMEMMAP the only memory model

[Dave Hansen]

[-- Attachment #1: Type: text/plain, Size: 231 bytes --]

On 5/16/25 07:59, Dave Hansen wrote:
> The only option would be to make them static when using non-vmemmap
> sparsemem. But that's new-ish, and probably won't get any testing.

Something like this. But I don't particularly like it.

[-- Attachment #2: static-sparsemem-0.patch --]
[-- Type: text/x-patch, Size: 663 bytes --]



---

 b/arch/x86/include/asm/sparsemem.h |    4 ++++
 1 file changed, 4 insertions(+)

diff -puN arch/x86/include/asm/sparsemem.h~static-sparsemem-0 arch/x86/include/asm/sparsemem.h
--- a/arch/x86/include/asm/sparsemem.h~static-sparsemem-0	2025-05-16 08:05:19.006150139 -0700
+++ b/arch/x86/include/asm/sparsemem.h	2025-05-16 08:07:14.517189024 -0700
@@ -26,7 +26,11 @@
 # endif
 #else /* CONFIG_X86_32 */
 # define SECTION_SIZE_BITS	27 /* matt - 128 is convenient right now */
+#ifdef CONFIG_SPARSEMEM_VMEMMAP
 # define MAX_PHYSMEM_BITS	(pgtable_l5_enabled() ? 52 : 46)
+# else
+# define MAX_PHYSMEM_BITS	46
+# endif
 #endif
 
 #endif /* CONFIG_SPARSEMEM */
_

Re: [PATCHv3 2/4] x86/64/mm: Make SPARSEMEM_VMEMMAP the only memory model

[Kirill A. Shutemov]

On Fri, May 16, 2025 at 06:42:03AM -0700, Dave Hansen wrote:
> On 5/16/25 05:33, Kirill A. Shutemov wrote:
> > 5-level paging only supports SPARSEMEM_VMEMMAP. CONFIG_X86_5LEVEL is
> > being phased out, making 5-level paging support mandatory.
> > 
> > Make CONFIG_SPARSEMEM_VMEMMAP mandatory for x86-64 and eliminate
> > any associated conditional statements.
> I think we have ourselves a catch-22 here.
> 
> SPARSEMEM_VMEMMAP was selected because the other sparsemem modes
> couldn't handle a dynamic MAX_PHYS{MEM,ADDR}_BITS introduced by 5-level
> paging. Now you're proposing making it static again, but keeping the
> SPARSEMEM_VMEMMAP dependency.
> 
> If you remove the dynamic MAX_PHYS{MEM,ADDR}_BITS, you should also
> remove the dependency on SPARSEMEM_VMEMMAP. No?

I guess. But how?

And is there any value to support !SPARSEMEM_VMEMMAP?

-- 
  Kiryl Shutsemau / Kirill A. Shutemov

Re: [PATCHv3 2/4] x86/64/mm: Make SPARSEMEM_VMEMMAP the only memory model

[Ingo Molnar]

* Kirill A. Shutemov <kirill.shutemov@linux.intel.com> wrote:

> On Fri, May 16, 2025 at 06:42:03AM -0700, Dave Hansen wrote:
> > On 5/16/25 05:33, Kirill A. Shutemov wrote:
> > > 5-level paging only supports SPARSEMEM_VMEMMAP. CONFIG_X86_5LEVEL is
> > > being phased out, making 5-level paging support mandatory.
> > > 
> > > Make CONFIG_SPARSEMEM_VMEMMAP mandatory for x86-64 and eliminate
> > > any associated conditional statements.
> > I think we have ourselves a catch-22 here.
> > 
> > SPARSEMEM_VMEMMAP was selected because the other sparsemem modes
> > couldn't handle a dynamic MAX_PHYS{MEM,ADDR}_BITS introduced by 5-level
> > paging. Now you're proposing making it static again, but keeping the
> > SPARSEMEM_VMEMMAP dependency.
> > 
> > If you remove the dynamic MAX_PHYS{MEM,ADDR}_BITS, you should also
> > remove the dependency on SPARSEMEM_VMEMMAP. No?
> 
> I guess. But how?
> 
> And is there any value to support !SPARSEMEM_VMEMMAP?

Not really IMHO:

  .config.opensuse.default:    CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
  .config.ubuntu.localinstall: CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
  .config.fedora.generic:      CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
  .config.rhel.generic:        CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y

Thanks,

	Ingo

Re: [PATCHv3 2/4] x86/64/mm: Make SPARSEMEM_VMEMMAP the only memory model

[Dave Hansen]

On 5/16/25 07:08, Ingo Molnar wrote:
>> And is there any value to support !SPARSEMEM_VMEMMAP?
> Not really IMHO:
> 
>   .config.opensuse.default:    CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
>   .config.ubuntu.localinstall: CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
>   .config.fedora.generic:      CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
>   .config.rhel.generic:        CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y

I look at the distro configs all the time as well.

But let's also not forget that none of these have lockdep turned on, and
we don't want to toss out lockdep support on x86, for example. ;)

Re: [PATCHv3 2/4] x86/64/mm: Make SPARSEMEM_VMEMMAP the only memory model

[Ingo Molnar]

* Dave Hansen <dave.hansen@intel.com> wrote:

> On 5/16/25 07:08, Ingo Molnar wrote:
> >> And is there any value to support !SPARSEMEM_VMEMMAP?
> > Not really IMHO:
> > 
> >   .config.opensuse.default:    CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
> >   .config.ubuntu.localinstall: CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
> >   .config.fedora.generic:      CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
> >   .config.rhel.generic:        CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
> 
> I look at the distro configs all the time as well.
> 
> But let's also not forget that none of these have lockdep turned on,

Not actually true, quite a few distro debug kernel packages have 
lockdep on, and it's often enabled in internal QA rigs as well.

Not so SPARSEMEM_VMEMMAP...

> [...] and we don't want to toss out lockdep support on x86, for 
> example. ;)

That's an apples to oranges comparison:

 - SPARSEMEM_VMEMMAP is always enabled, in standard and debug kernels 
   as well.

 - lockdep is disabled in standard kernels, enabled in debug kernels 
   and very much relied on.

Thanks,

	Ingo

Re: [PATCHv3 2/4] x86/64/mm: Make SPARSEMEM_VMEMMAP the only memory model

[Dave Hansen]

On 5/16/25 08:35, Ingo Molnar wrote:
>   .config.opensuse.default:    CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
>   .config.ubuntu.localinstall: CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
>   .config.fedora.generic:      CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
>   .config.rhel.generic:        CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y

That reminds me...

Does everybody keep their own local copies of these configs in their
environment? I do, and I refresh them periodically from the distros. I
assume everybody else is doing something similar.

Is there a better way?

Re: [PATCHv3 2/4] x86/64/mm: Make SPARSEMEM_VMEMMAP the only memory model

[H. Peter Anvin]

On May 16, 2025 8:46:07 AM PDT, Dave Hansen <dave.hansen@intel.com> wrote:
>On 5/16/25 08:35, Ingo Molnar wrote:
>>   .config.opensuse.default:    CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
>>   .config.ubuntu.localinstall: CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
>>   .config.fedora.generic:      CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
>>   .config.rhel.generic:        CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
>
>That reminds me...
>
>Does everybody keep their own local copies of these configs in their
>environment? I do, and I refresh them periodically from the distros. I
>assume everybody else is doing something similar.
>
>Is there a better way?

What I do is keep a set of minimal configs which are the deltas from the default. 

Re: [PATCHv3 2/4] x86/64/mm: Make SPARSEMEM_VMEMMAP the only memory model

[Dave Hansen]

On 5/16/25 07:01, Kirill A. Shutemov wrote:
>> If you remove the dynamic MAX_PHYS{MEM,ADDR}_BITS, you should also
>> remove the dependency on SPARSEMEM_VMEMMAP. No?
> I guess. But how?
> 
> And is there any value to support !SPARSEMEM_VMEMMAP?

Not really, other than making sure x86 supports a really wide variety of
arch-independent options. I've used it a time or two to go looking for
bugs but I'm not sure if those originated on x86 or other architectures.

Re: [PATCHv3 0/4] x86: Make 5-level paging support unconditional for x86-64

[Borislav Petkov]

On Fri, May 16, 2025 at 03:33:02PM +0300, Kirill A. Shutemov wrote:
> Both Intel and AMD CPUs support 5-level paging, which is expected to
> become more widely adopted in the future.
> 
> Remove CONFIG_X86_5LEVEL.
> 
> In preparation to that remove CONFIG_DYNAMIC_MEMORY_LAYOUT and make
> SPARSEMEM_VMEMMAP the only memory model.
> 
> v3:
>  - Drop few "#if CONFIG_PGTABLE_LEVELS >= 5";
>  - Make PARAVIRT_XXL 64-bit explicitly and drop ifdefs
>    to support PGTABLE_LEVELS < 5;
>  - Add Reviewed-by tags from Ard;
> v2:
>  - Fix 32-bit build by wrapping p4d_set_huge() and p4d_clear_huge() in
>    #if CONFIG_PGTABLE_LEVELS > 4;
>  - Rebased onto current tip/master;
> 
> Kirill A. Shutemov (4):
>   x86/64/mm: Always use dynamic memory layout
>   x86/64/mm: Make SPARSEMEM_VMEMMAP the only memory model
>   x86/64/mm: Make 5-level paging support unconditional
>   x86/paravirt: Restrict PARAVIRT_XXL to 64-bit only

The whole set passed randbuilds testing here too, and am running boot tests on
my pile of stinky hw.

If it passes, we could queue it all.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCHv2 0/3] x86: Make 5-level paging support unconditional for x86-64

[Khalid Ali]

>Both Intel and AMD CPUs support 5-level paging, which is expected to
>become more widely adopted in the future.
>
>Remove CONFIG_X86_5LEVEL.
>
>In preparation to that remove CONFIG_DYNAMIC_MEMORY_LAYOUT and make
>SPARSEMEM_VMEMMAP the only memory model.
>
>v3:
> - Drop few "#if CONFIG_PGTABLE_LEVELS >= 5";
> - Make PARAVIRT_XXL 64-bit explicitly and drop ifdefs
>   to support PGTABLE_LEVELS < 5;
> - Add Reviewed-by tags from Ard;
>v2:
> - Fix 32-bit build by wrapping p4d_set_huge() and p4d_clear_huge() in
>   #if CONFIG_PGTABLE_LEVELS > 4;
> - Rebased onto current tip/master;
>
>Kirill A. Shutemov (4):
>  x86/64/mm: Always use dynamic memory layout
>  x86/64/mm: Make SPARSEMEM_VMEMMAP the only memory model
>  x86/64/mm: Make 5-level paging support unconditional
>  x86/paravirt: Restrict PARAVIRT_XXL to 64-bit only
>
> Documentation/arch/x86/cpuinfo.rst            |  8 ++---
> .../arch/x86/x86_64/5level-paging.rst         |  9 -----
> arch/x86/Kconfig                              | 33 ++-----------------
> arch/x86/Kconfig.cpufeatures                  |  4 ---
> arch/x86/boot/compressed/pgtable_64.c         | 11 ++-----
> arch/x86/boot/header.S                        |  4 ---
> arch/x86/boot/startup/map_kernel.c            |  5 +--
> arch/x86/entry/vsyscall/vsyscall_64.c         |  2 --
> arch/x86/include/asm/page_64.h                |  2 --
> arch/x86/include/asm/page_64_types.h          | 11 -------
> arch/x86/include/asm/paravirt.h               |  4 ---
> arch/x86/include/asm/paravirt_types.h         |  2 --
> arch/x86/include/asm/pgtable_64.h             |  2 --
> arch/x86/include/asm/pgtable_64_types.h       | 24 --------------
> arch/x86/kernel/alternative.c                 |  2 +-
> arch/x86/kernel/head64.c                      |  4 ---
> arch/x86/kernel/head_64.S                     |  2 --
> arch/x86/kernel/paravirt.c                    |  2 --
> arch/x86/mm/init.c                            |  4 ---
> arch/x86/mm/init_64.c                         |  9 +----
> arch/x86/mm/pgtable.c                         |  2 +-
> arch/x86/xen/mmu_pv.c                         |  4 ---
> drivers/firmware/efi/libstub/x86-5lvl.c       |  2 +-
> scripts/gdb/linux/pgtable.py                  |  4 +--
> 24 files changed, 14 insertions(+), 142 deletions(-)

I think i am too late, however this is completely wrong. There are still processors that doesn't support
5-level paging which is mordern. We may call those processors old, however they are still common and used.

So this patch seem too early for that. Some intel core-i5 and core-i7 doesn't support 5-level paging at all.

This will break x86_64 cpus that doesn't support 5-level paging.