On Sat, Oct 12, 2013 at 11:13:08AM +0100, Matt Fleming wrote: > On Sat, 12 Oct, at 03:54:44PM, Dave Young wrote: > > Boris: > > > > For the boot service region overlapping problem I have another idea, > > how about modify your mapping code to always mapping the RUNTIME region > > (non boot service region) firstly from the efi_va, then mapping other > > regions in order, in this way kexec 2nd kernel will be happy because > > it does not call SetVirtualAddressMap and it does not need the boot > > service area at all. > > Coalescing the runtime regions together implies that the second kernel > would care about the fragmentation caused by unmapping the boot service > regions - it shouldn't. We've sliced up a considerable chunk of kernel > virtual address space (64G) and fragmentation shouldn't be an issue > right now. > > Even if we run out of address space in the future due to fragmentation, > and end up needing to coalesce runtime regions, this would be > transparent to the kexec kernel because it's passed the memmap entries > through setup_data. Ok, so passing setup_data looks better like hpa said previously. > > Though we are defining an ABI around the EFI address range > (0xffffffef00000000 - 0xffffffff00000000), such that it needs to be the > same between kernels, we must not make the layout of regions within that > range part of the ABI. We need the freedom to change the layout in the > future. Agree. > > -- > Matt Fleming, Intel Open Source Technology Center -- 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
