On Mon, Aug 15, 2016 at 01:47:31PM -0500, Alex Thorlton wrote:
> The only thing we're adding here is the physical mappings, to match
> what is availble in the primary kernel.
I can see what it does - I just am questioning the reasoning for as we
did all that effort so that kexec can have stable virtual mappings.
I guess we still need a way to pass the virtual mappings to kexec
as they're immutable as some "smartass" decided to allow to call
SetVirtualAddressMap only once.
> This is sort of a hand-wavey answer - I will investigate the his further...
Yeah, it'll be interesting to know whether that is an issue because if
we do the 1:1 mappings in the kexec kernel too and there's an address
conflict, then we better know upfront.
> It's not that we need it all of the sudden, necessarily, it's just that
> we've had to make other changes to make things work with the new,
> (almost) completely isolated, EFI page tables. We ended up choosing the
> lesser of two evils, and have decided to temporarily rely on the
> physical address of our runtime code, instead of continuing to rely on
> EFI_OLD_MEMMAP.
Well, if it starts to cause trouble, you probably will have to revert.
> If there are strong objections to this change, I won't pursue it
> further.
I don't really care all that much as long as it doesn't break the
existing situation. I've long given up on the hope that EFI and all its
incarnations will hold on to some spec... :-)
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
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
