On 03/01/16 at 11:30pm, Matt Fleming wrote: > 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. Matt, thanks. One question is for the acpi patches you sent before, do you think they are still necessary as a fix for the bgrt problem and coexist with the "reserve useful boot services" proposal? Thanks Dave -- 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
