Re: [PATCH -v2] EFI: Runtime services virtual mapping

From: H. Peter Anvin
Date: Tue Sep 24 2013 - 20:13:07 EST

On 09/24/2013 07:56 AM, Borislav Petkov wrote:
> On Tue, September 24, 2013 2:45 pm, Dave Young wrote:
>> Think again about this, how about 1:1 map them from a base address
>> like -64G phy_addr -> (-64G + phy_addr), in this way we can avoid
>> depending on the previous region size.
> Right, how we layout the regions is arbitrary as long as we start at
> the same VA and use the same regions, in the same order and of the same
> size...
>> For the zero region problem, we can resolve it as a standalone
>> problem.
> ... however, we still need to understand why it fails mapping the boot
> services region as some implementations apparently do call boot services
> even after ExitBootServices(). IOW, we need that region mapped in the
> kexec'ed kernel too.

I am starting to think that we really should explicitly pass along the
EFI mappings to the secondary kernel. This will also help if we have to
change the algorithm in a future kernel.

The most logical way to do this is to define a new setup_data type and
pass the entire set of physical-to-virtual mappings that way.

For example:

struct efi_mapping {
u64 va; /* Virtual start address */
u64 pa; /* Physical start address */
u64 len; /* Length in bytes */
u64 type; /* Mapping type */
u64 reserved[3]; /* Reserved, must be zero */

Adding some reserved fields seems like a prudent precaution; the map
shouldn't be all that large anyway.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at