Re: [PATCH] kho: initialize tail pages for higher order folios properly

[Pratyush Yadav]

On Wed, Jun 11 2025, Pasha Tatashin wrote:

> On Wed, Jun 11, 2025 at 9:06 AM Pratyush Yadav <pratyush@xxxxxxxxxx> wrote:
>>
>> On Tue, Jun 10 2025, Pasha Tatashin wrote:
[...]
>> >> > > We could, but with that would mean we'll run this before SMP and it's not
>> >> > > desirable. Also, init_deferred_page() for a random page requires
>> >> >
>> >> > We already run KHO init before smp_init:
>> >> > start_kernel() -> mm_core_init() -> kho_memory_init() ->
>> >> > kho_restore_folio() -> struct pages must be already initialized here!
>> >> >
>> >> > While deferred struct pages are initialized:
>> >> > start_kernel() -> rest_init() -> kernel_init() ->
>> >> > kernel_init_freeable() -> page_alloc_init_late() ->
>> >> > deferred_init_memmap()
>> >> >
>> >> > If the number of preserved pages that is needed during early boot is
>> >> > relatively small, that it should not be an issue to pre-initialize
>> >> > struct pages for them before deferred struct pages are initialized. We
>> >> > already pre-initialize some  "struct pages" that are needed during
>> >> > early boot before the reset are initialized, see deferred_grow_zone()
>> >>
>> >> deferred_grow_zone() takes a chunk in the beginning of uninitialized range,
>> >> with kho we are talking about some random pages. If we preinit them early,
>> >> deferred_init_memmap() will overwrite them.
>> >
>> > Yes, this is why I am saying that we would need to skip the KHO
>> > initialized "struct pages" somehow during deferred initialization. If
>> > we create an ordered by PFN list of early-initialized KHO struct
>> > pages, skipping during deferred initialization could be done
>> > efficiently.
>>
>> Or keep things simple and don't use any KHO struct pages during early
>> init. You can access the page itself, just don't use its struct page.
>>
>> Currently the only user of kho_restore_folio() during init is
>> kho_memory_init(). The FDT is accessed by doing
>> phys_to_virt(kho_in.fdt_phys) anyway, so there is really no need for
>> restoring the folio so early. It can be done later, for example when LUO
>> does the finish event, to clean up and free the folio.
>
> Good suggestion, however, KHO does not have any sophisticated users
> that we are going to be adding as part of the live update work in the
> future: IR, KVM, early VCPU threads, and so on. So, while today, this
> might work, in the future, I am not sure if we should expect struct
> pages are not accessed until after deferred initialization or simply
> fix it once and for all.

Right. We might end up needing it down the line. But from a quick look,
it doesn't seem to be trivial to solve, so IMO we should solve it when
those use cases actually show up, and keep things simple for now.

-- 
Regards,
Pratyush Yadav