Re: [PATCH -v2] EFI: Runtime services virtual mapping

[Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

On 09/24/13 at 04:56pm, Borislav Petkov wrote:
> On Tue, September 24, 2013 2:45 pm, Dave Young wrote:
> > Think again about this, how about 1:1 map them from a base address
> > like -64G phy_addr -> (-64G + phy_addr), in this way we can avoid
> > depending on the previous region size.
> 
> Right, how we layout the regions is arbitrary as long as we start at
> the same VA and use the same regions, in the same order and of the same
> size...
> 
> > For the zero region problem, we can resolve it as a standalone
> > problem.
> 
> ... however, we still need to understand why it fails mapping the boot
> services region as some implementations apparently do call boot services
> even after ExitBootServices(). IOW, we need that region mapped in the
> kexec'ed kernel too.

In 1st kernel, the memmap is provided by firmware and unchanged before
we do the mapping, later efi_reserve_boot_services() try to reserve the
mem range, but failed due to conflict with other region (why?), then the
memmap item size is set to 0 (why?).

In 2nd kernel, we use same memmap from firmware, but the boot service
ranges size have been set to 0, thus efi mapping code will mapping runtime
regions to different va from 1st kernel.

--
Thanks
Dave