On 11/22/19 at 10:07pm, Michael Weiser wrote:
> Hi Eric,
>
> On Fri, Nov 22, 2019 at 02:00:22PM -0600, Eric W. Biederman wrote:
>
> > > esrt: Unsupported ESRT version 2904149718861218184.
> > >
> > > (The image is rather large at 18MiB as it has a built-in initrd.)
> > When did x86_64 get support for ARCH_KEEP_MEMBLOCK? I can't find it
> > anywhere.
>
> No, is hasn't. I temporarily hacked that in to see if it'd change
> anything and it did. Sorry to not be more clear about that.
>
> > Fundamentally when deciding where to place a new kernel kexec (either
> > user space or the in kernel kexec_file implementation) needs to be able
> > to ask the question which memory ares are reserved.
> > What the buddy
> > allocator does is unimportant as kexec copies memory from all over
> > the place and places it in the destined memory addresses at the
> > time of the kexec operation.
>
> > So my question is why doesn't the ESRT reservation wind up in
> > /proc/iomem?
>
> My guess is that the focus was that some EFI structures need to be kept
> around accross the life cycle of *one* running kernel and
> memblock_reserve() was enough for that. Marking them so they survive
> kexecing another kernel might just never have cropped up thus far. Ard
> or Matt would know.
Can you check your un-reserved memory, if your memory falls into EFI
BOOT* then in X86 you can use something like below if it is not covered:
void __init efi_esrt_init(void)
{
...
pr_info("Reserving ESRT space from %pa to %pa.\n", &esrt_data, &end);
if (md.type == EFI_BOOT_SERVICES_DATA)
efi_mem_reserve(esrt_data, esrt_data_size);
...
}
Unfortunately I noticed there are different requirements/ways for
different types of "reserved" memory. But that is another topic..
Thanks
Dave
_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec
