On 03/01/16 at 11:30pm, Matt Fleming wrote:

On Fri, 26 Feb, at 02:41:14PM, Matt Fleming wrote:

quoted

On Thu, 18 Feb, at 02:16:24PM, Peter Jones wrote:

quoted

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