Re: [PATCH v4 00/14] kexec: introduce Kexec HandOver (KHO)

Re: [PATCH v4 00/14] kexec: introduce Kexec HandOver (KHO)

[Dave Young]

On Wed, 19 Feb 2025 at 21:55, Alexander Graf <graf@amazon.com> wrote:
>
>
> On 19.02.25 13:49, Dave Young wrote:
> > On Wed, 19 Feb 2025 at 15:32, Mike Rapoport <rppt@kernel.org> wrote:
> >> On Mon, Feb 17, 2025 at 11:19:45AM +0800, RuiRui Yang wrote:
> >>> On Thu, 6 Feb 2025 at 21:34, Mike Rapoport <rppt@kernel.org> wrote:
> >>>> == Limitations ==
> >>>>
> >>>> Currently KHO is only implemented for file based kexec. The kernel
> >>>> interfaces in the patch set are already in place to support user space
> >>>> kexec as well, but it is still not implemented it yet inside kexec tools.
> >>>>
> >>> 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.

Other than the arch concern,   I'm not so excited about the KHO
because for kexec reboot there is a fundamental problem which makes us
(Red Hat kexec/kdump team) can not full support it in RHEL
distribution, that is the stability due to drivers usually do not
implement the  device shutdown method or not well tested.   From time
to time we see weird bugs,  could be malfunctioned devices or memory
corruption caused by ongoing DMA etc.   Also no way for the time being
to make some graphic/drm drivers work ok after a kexec reboot, it
might happen to work by luck but also not stable.

So I personally think that improving the above concern is more
important than introducing more features to utilize kexec reboot.

>
>
> Alex
>
>

Re: [PATCH v4 00/14] kexec: introduce Kexec HandOver (KHO)

[Alexander Gordeev]

On Thu, Feb 20, 2025 at 09:49:52AM +0800, Dave Young wrote:
> On Wed, 19 Feb 2025 at 21:55, Alexander Graf <graf@amazon.com> 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.

Thanks, Dave!

Re: [PATCH v4 00/14] kexec: introduce Kexec HandOver (KHO)

[Mike Rapoport]

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@amazon.com> 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.