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 -- 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
