Re: [PATCH v4 06/14] kexec: Add KHO parsing support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Feb 06, 2025 at 03:27:46PM +0200, Mike Rapoport wrote:

> +/**
> + * kho_claim_mem - Notify the kernel that a handed over memory range is now
> + * in use
> + * @mem: memory range that was preserved during kexec handover
> + *
> + * A kernel subsystem preserved that range during handover and it is going
> + * to reuse this range after kexec. The pages in the range are treated as
> + * allocated, but not %PG_reserved.
> + *
> + * Return: virtual address of the preserved memory range
> + */
> +void *kho_claim_mem(const struct kho_mem *mem)
> +{
> +	unsigned long start_pfn, end_pfn, pfn;
> +	void *va = __va(mem->addr);
> +
> +	start_pfn = PFN_DOWN(mem->addr);
> +	end_pfn = PFN_UP(mem->addr + mem->size);
> +
> +	for (pfn = start_pfn; pfn < end_pfn; pfn++) {
> +		int err = kho_claim_pfn(pfn);
> +
> +		if (err)
> +			return NULL;
> +	}
> +
> +	return va;
> +}
> +EXPORT_SYMBOL_GPL(kho_claim_mem);

I think this is not the sort of interface toward drivers we should be
going for, I think we should be round tripping folios at their
allocated order and when restored the folio should freed with
folio_put(), just like in the normal way. Here you are breaking down
high order folios and undoing the GFP_COMP, it is not desirable for
drivers..

Eventually with some kind of support for conserving the memdesc
struct/page metadata if a driver is using it.

Following that basic primitive you'd want to have the same idea to
preserve kmalloc() memory.

And like I said elsewhere, the drivers should be working on naked
phys_addr_t's stored in their own structs in their own way, not
special kho_mem things.. It won't scale like this if the driver needs
to pass thousands of pages.

Also, how is the driver supposed to figure out what the structure is
inside the kho_mem anyhow? I would expect the FDT key/value store to
have a key/phys_addr_t structure outlining the various driver data
structures.

IMHO this links to my frist comment on how the FDT represents the
preserved memory, it seems thsat FDT format cannot effectively
preserve folios..

Jason




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux