[lkml]   [2013]   [Oct]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 12/12] EFI: Runtime services virtual mapping
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.
> --

 \ /
  Last update: 2013-10-13 05:41    [W:0.088 / U:2.432 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site