On Wed, Jun 11 2025, Pasha Tatashin wrote: > On Wed, Jun 11, 2025 at 9:06 AM Pratyush Yadav <praty...@kernel.org> 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
