Thread (30 messages) read the whole thread 30 messages, 6 authors, 2016-06-20
STALE3692d

[PATCH v2 1/2] efi: esrt: use memremap not ioremap to access ESRT table in memory

From: Matt Fleming <hidden>
Date: 2016-03-01 23:30:40
Also in: linux-efi

On Fri, 26 Feb, at 02:41:14PM, Matt Fleming wrote:
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help