On 04.10.2022 17:46, Demi Marie Obenour wrote: > Linux has a function called efi_mem_reserve() that is used to reserve > EfiBootServicesData memory that contains e.g. EFI configuration tables. > This function does not work under Xen because Xen could have already > clobbered the memory. efi_mem_reserve() not working is the whole reason > for this thread, as it prevents EFI tables that are in > EfiBootServicesData from being used under Xen. > > A much nicer approach would be for Xen to reserve boot services memory > unconditionally, but provide a hypercall that dom0 could used to free > the parts of EfiBootServicesData memory that are no longer needed. This > would allow efi_mem_reserve() to work normally. efi_mem_reserve() actually working would be a layering violation; controlling the EFI memory map is entirely Xen's job. As to the hypercall you suggest - I wouldn't mind its addition, but only for the case when -mapbs is used. As I've indicated before, I'm of the opinion that default behavior should be matching the intentions of the spec, and the intention of EfiBootServices* is for the space to be reclaimed. Plus I'm sure you realize there's a caveat with Dom0 using that hypercall: It might use it for regions where data lives which it wouldn't care about itself, but which an eventual kexec-ed (or alike) entity would later want to consume. Code/data potentially usable by _anyone_ between two resets of the system cannot legitimately be freed (and hence imo is wrong to live in EfiBootServices* regions). In a way one could view the Dom0 kernel as an "or alike" entity ... Jan
