On Tue, Sep 29, 2026 at 01:12:45PM -0400, Zack Rusin wrote:
> On Tue, Sep 29, 2026 at 3:54 AM Peter Zijlstra <[email protected]> wrote:
> > On Tue, Sep 29, 2026 at 12:02:51AM -0400, Zack Rusin wrote:
> > > @@ -1022,11 +1024,13 @@
> > > * Note: We use a separate section so that only this section gets
> > > * decrypted to avoid exposing more than we wish.
> > > */
> > > -#ifdef CONFIG_AMD_MEM_ENCRYPT
> > > +#if defined(CONFIG_X86_MEM_ENCRYPT) && defined(CONFIG_SMP)
> > > #define PERCPU_DECRYPTED_SECTION \
> > > . = ALIGN(PAGE_SIZE); \
> > > + __start_percpu_decrypted = .; \
> > > *(.data..percpu..decrypted) \
> > > - . = ALIGN(PAGE_SIZE);
> > > + . = ALIGN(PAGE_SIZE); \
> > > + __end_percpu_decrypted = .;
> > > #else
> > > #define PERCPU_DECRYPTED_SECTION
> > > #endif
> >
> > So you're page aligning something that will get different protection and
> > will thus shatter large pages?
> >
> > That is somewhat uncool. We like large pages, large pages are good.
>
> I'm a huge large pages fan too. I have a poster in my office and
> everything... And I never do things that are uncool. I have a wwcdd
> (what would cool dude do) bracelet and I look at it every time I make
> a decision, which given that I'm old gets on my wife's nerves a lot.
> That is to say I'm handsome and innocent.
:-)
> The alignment isn't new. It has been there since ac26963a1175
> ("percpu: Introduce DEFINE_PER_CPU_DECRYPTED") under AMD_MEM_ENCRYPT,
> which common distro kernels enable. This patch extends it to TDX-only
> builds and adds the boundary symbols. On bare metal and in ordinary
> guests nothing changes protection, so no large pages are split.
Right, I saw it is pre-existing, but you made me notice ;-)
Anyway, the thing that wasn't immediately obvious was that we only
really change the protection for (sekjoer) guests. This means I mostly
don't care.
> In confidential guests, yes, converting each CPU's page splits the
> direct map around it. The alignment doesn't cause that: a large
Nit you could 2M align, so alignment is somewhat related.
> mapping can't be part private and part shared, so a converted page
> can't stay inside one. The alignment only keeps unrelated per-CPU data
> out of the shared page. Because that page sits in every CPU's per-CPU
> unit, each 2M mapping that holds one of them becomes 4K mappings,
> including the ordinary per-CPU data around it. In the layouts we've
> tested that's most of the first per-CPU chunk.
So perhaps a little more invasive would be poking at the per-cpu
allocator and having a whole 'decrypted' pcpu_chunk which is 2M aligned
or something.
Anyway, as long as this is sekjoer guests only, I really could not be
bothered much. Proceed, but perhaps put on a comment in the
vmlinux.lds.h to clarify this, for those of us who do not live in
coconut land?
