On 09/24/13 at 05:12pm, H. Peter Anvin wrote:
> 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.
Hmm, since len is saved in efi_mapping so the previous 0 size range would
not a problem.
If we choose this approach, can we save not only the efi_mapping, but also
the fields which will be converted to virt addr, like fw_vendor, runtime,
tables? During my test on a HP workstation, the config table item (SMBIOS) also is
converted to virt addr though spec only mention fw_vendor/runtime/tables.
--
Thanks
Dave
--
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
