[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4FE23592.60201@linux.intel.com>
Date: Wed, 20 Jun 2012 13:41:54 -0700
From: "H. Peter Anvin" <hpa@...ux.intel.com>
To: Matthew Garrett <mjg59@...f.ucam.org>
CC: Robin Holt <holt@....com>, linux-kernel@...r.kernel.org,
"Sakkinen, Jarkko" <jarkko.sakkinen@...el.com>
Subject: Re: [PATCH] phys_efi_set_virtual_address_map needs va, no pa.
On 06/20/2012 05:07 AM, Matthew Garrett wrote:
>
> No, that's completely wrong. UEFI can't be called in virtual mode until
> *after* SetVirtualAddressMap(). The UEFI spec indicates that all
> physical memory must have an identity mapping at this stage (section
> 2.3.4), so if we don't then that's a bug that needs to be fixed.
>
I think it is a bug, and with the trampoline work in 3.4 we should
finally have a proper platform to fix it.
In particular, we should keep a full 1:1 page map around, and it should
be the one that is in the trampoline (real_mode_header->trampoline_pgd)
as we need the page directory to be 32-bit addressable.
The right thing to do is to sync the pgds in the 1:1 area, both for 64
bit and for legacy 32 bit (PAE 32 bit don't need it, since all the
kernel maps are shared.) This is currently done ad hoc (and
differently!) on both 32 and 64 bits and that really should be fixed.
Once that is properly fixed, we have a usable identity mapping.
On that subject, I have been thinking about the kexec use case. I'm
thinking that if we indeed cannot use either physical mode nor a
zero-offset virtual mode, that the most likely sane thing to do is to
use a fixed offset of 2^46 and still use a (pseudo-)1:1 map.
Do we have any data at all on machines that supposedly can't use
identity-mapped EFI?
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists