On Thu, Feb 20, 2025 at 05:43:48PM +0100, Alexander Gordeev wrote: > On Thu, Feb 20, 2025 at 09:49:52AM +0800, Dave Young wrote: > > On Wed, 19 Feb 2025 at 21:55, Alexander Graf <graf@xxxxxxxxxx> wrote: > > > >>> What architecture exactly does this KHO work fine? Device Tree > > > >>> should be ok on arm*, x86 and power*, but how about s390? > > > >> KHO does not use device tree as the boot protocol, it uses FDT as a data > > > >> structure and adds architecture specific bits to the boot structures to > > > >> point to that data, very similar to how IMA_KEXEC works. > > > >> > > > >> Currently KHO is implemented on arm64 and x86, but there is no fundamental > > > >> reason why it wouldn't work on any architecture that supports kexec. > > > > Well, the problem is whether there is a way to add dtb in the early > > > > boot path, for X86 it is added via setup_data, if there is no such > > > > way I'm not sure if it is doable especially for passing some info for > > > > early boot use. Then the KHO will be only for limited use cases. > > > > > > > > > Every architecture has a platform specific way of passing data into the > > > kernel so it can find its command line and initrd. S390x for example has > > > struct parmarea. To enable s390x, you would remove some of its padding > > > and replace it with a KHO base addr + size, so that the new kernel can > > > find the KHO state tree. > > > > Ok, thanks for the info, I cced s390 people maybe they can provide inputs. > > If I understand correctly, the parmarea would be used for passing the > FDT address - which appears to be fine. However, s390 does not implement > early_memremap()/early_memunmap(), which KHO needs. KHO uses early_memremap()/early_memunmap() because it parses FDT before phys_to_virt() is available on arm64 and x86. AFAIU on s390 phys_to_virt() can be used at setup_arch() time, so it shouldn't be a problem to add appropriate wrappers. -- Sincerely yours, Mike.
