On Sat, Oct 12, 2013 at 12:30:55PM +0200, Borislav Petkov wrote: > 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. > > > > 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. > > Basically, to sum up what Matt so eloquently explained, we will be > passing all the runtime regions *but* *not* the boot regions (because > the kexec kernel doesn't need them anyway) through setup_data to the > kexec kernel. > > I.e., boot services regions is a dont-care for kexec. > > And it is very important to restate that we want to reserve ourselves > the most flexible way of passing regions to the kexec kernel in case we > want to change the mapping algorithm in the future. Therefore, kexec > should simply not know anything about the VA layout of the EFI regions > but will get them spelled out through the boot header's setup_data. Boris, I think we have got the agreement about passing setup_data? I think it should be on top of your patch series, I can work on that along with other kexec related patches. Or if you would like to do it please let me know. > > This is the picture so far, AFAICT. Matt, please make a lot of noise if > I've misrepresented anything. > > Thanks. > > -- > Regards/Gruss, > Boris. > > Sent from a fat crate under my desk. Formatting is fine. > -- -- 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
