[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aBD_IUE6xmbphB5R@kernel.org>
Date: Tue, 29 Apr 2025 19:32:33 +0300
From: Mike Rapoport <rppt@...nel.org>
To: Dave Hansen <dave.hansen@...el.com>
Cc: Changyuan Lyu <changyuanl@...gle.com>, linux-kernel@...r.kernel.org,
akpm@...ux-foundation.org, anthony.yznaga@...cle.com, arnd@...db.de,
ashish.kalra@....com, benh@...nel.crashing.org, bp@...en8.de,
catalin.marinas@....com, corbet@....net,
dave.hansen@...ux.intel.com, devicetree@...r.kernel.org,
dwmw2@...radead.org, ebiederm@...ssion.com, graf@...zon.com,
hpa@...or.com, jgowans@...zon.com, kexec@...ts.infradead.org,
krzk@...nel.org, linux-arm-kernel@...ts.infradead.org,
linux-doc@...r.kernel.org, linux-mm@...ck.org, luto@...nel.org,
mark.rutland@....com, mingo@...hat.com, pasha.tatashin@...een.com,
pbonzini@...hat.com, peterz@...radead.org, ptyadav@...zon.de,
robh@...nel.org, rostedt@...dmis.org, saravanak@...gle.com,
skinsburskii@...ux.microsoft.com, tglx@...utronix.de,
thomas.lendacky@....com, will@...nel.org, x86@...nel.org
Subject: Re: [PATCH v6 11/14] x86: add KHO support
On Tue, Apr 29, 2025 at 09:06:19AM -0700, Dave Hansen wrote:
> On 4/29/25 01:06, Mike Rapoport wrote:
> > On Mon, Apr 28, 2025 at 03:05:55PM -0700, Dave Hansen wrote:
> >> On 4/10/25 22:37, Changyuan Lyu wrote:
> >>> From: Alexander Graf <graf@...zon.com>
> >>>
> >>> @@ -1300,6 +1300,24 @@ void __init e820__memblock_setup(void)
> >>> memblock_add(entry->addr, entry->size);
> >>> }
> >>>
> >>> + /*
> >>> + * At this point with KHO we only allocate from scratch memory.
> >>> + * At the same time, we configure memblock to only allow
> >>> + * allocations from memory below ISA_END_ADDRESS which is not
> >>> + * a natural scratch region, because Linux ignores memory below
> >>> + * ISA_END_ADDRESS at runtime. Beside very few (if any) early
> >>> + * allocations, we must allocate real-mode trapoline below
> >>
> >> trampoline ^
> >>
> >>> + * ISA_END_ADDRESS.
> >>> + *
> >>> + * To make sure that we can actually perform allocations during
> >>> + * this phase, let's mark memory below ISA_END_ADDRESS as scratch
> >>> + * so we can allocate from there in a scratch-only world.
> >>> + *
> >>> + * After real mode trampoline is allocated, we clear scratch
> >>> + * marking from the memory below ISA_END_ADDRESS
> >>> + */
> >>> + memblock_mark_kho_scratch(0, ISA_END_ADDRESS);
> >>
> >> This isn't making a whole ton of sense to me.
> >>
> >> Is this *only* to facilitate possible users that need <ISA_END_ADDRESS
> >> allocations? If so, please say that.
> >>
> >> I _think_ this is trying to say that KHO kernels are special and are
> >> trying to only allocate from scratch areas. But <ISA_END_ADDRESS
> >> allocations are both necessary and not marked by KHO _as_ a scratch area
> >> which causes a problem.
> >
> > Yes :)
>
> So, on both of these, could the submitters please add or revise the
> comments to make it more clear?
Is this one clearer?
/*
* At this point memblock is only allowed to allocate from memory
* below 1M (aka ISA_END_ADDRESS) up until direct map is completely set
* up in init_mem_mapping().
*
* KHO kernels are special and use only scratch memory for memblock
* allocations, but memory below 1M is ignored by kernel after early
* boot and cannot be naturally marked as scratch.
*
* To allow allocation of the real-mode trampoline and a few (if any)
* other very early allocations from below 1M forcibly mark the memory
* below 1M as scratch.
*
* After real mode trampoline is allocated, we clear that scratch
* marking.
*/
memblock_mark_kho_scratch(0, SZ_1M);
--
Sincerely yours,
Mike.
Powered by blists - more mailing lists