On Fri, 26 Feb, at 02:41:14PM, Matt Fleming wrote: > On Thu, 18 Feb, at 02:16:24PM, Peter Jones wrote: > > > > So the question I have is: would you rather chop up regions and reserve > > the space, or allocate a new copy and update the configuration table > > (after ExitBootServices()) to point to it? The latter makes it pretty > > easy to do from an API that all these drivers can use, and it makes the > > kexec case completely transparent. > > > > Up to you. > > I think it makes the most sense to chop up the regions we care about > (i.e. the ones we have drivers for) because not only does that save us > the effort of copying out the data on every kexec reboot, it also > prevents us from leaking each copy since we don't free them at the > moment. > > Then we just need to maintain a separate list of regions to free in > efi_free_boot_services() or have some other way to distinguish between > them. > > Oh, and save_runtime_map() would need updating to save Boot Services > regions too. I have a very rough draft of patches that implement this strategy on the 'experiemntal/efi-memmap' branch in the EFI tree if anyone is curious and wants to take a look. The series will be sent out soon. I wouldn't necessarily try running them or anything as there's a few things that I know are broken; ia64 build, EFI mixed mode boot, probably arm64 regressions. The upshot of the patch series is that there's a whole lot of code we can share for manipulating memory maps between all EFI architectures and by fixing this "reserve boot services regions" in a generic way it should mean kexec under EFI on arm64 should be fairly trivial to implement, along with ESRT, etc. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
