On Wed, 29 Jun 2022 at 08:59, Kirill A. Shutemov <kirill.shutemov@xxxxxxxxxxxxxxx> wrote: > > On Tue, Jun 28, 2022 at 05:10:56PM -0700, Dave Hansen wrote: > > On 6/28/22 16:51, Kirill A. Shutemov wrote: > > > On Fri, Jun 24, 2022 at 05:00:05AM +0300, Kirill A. Shutemov wrote: > > >>> If there is some deep and fundamental why this can not be supported > > >>> then it probably makes sense to put some code in the arch_kexec_load > > >>> hook that verifies that deep and fundamental reason is present. > > ... > > > + /* > > > + * TODO: Information on memory acceptance status has to be communicated > > > + * between kernel. > > > + */ > > > > So, the deep and fundamental reason is... drum roll... you haven't > > gotten around to implementing bitmap passing yet?!?!? I have the > > feeling that wasn't what Eric was looking for. > > The deep fundamental reason is that everything cannot be implemented and > upstreamed at once. If the only thing is to pass bitmap to kexec kernel, since you have reserved the bitmap memory I guess it is straightforward to set the kexec bootparams.unaccepted_memory as the old value. Not sure if there are problems when the decompress code accepts memory again though. for kernel kexec_file_load, refer to function setup_boot_parameters() in arch/x86/kernel/kexec-bzimage64.c for kexec_file_load, for kexec-tools kexec_load code refer to setup_linux_system_parameters() kexec/arch/i386/x86-linux-setup.c Thanks Dave
