On 03/01/2013 02:53 PM, Borislav Petkov wrote:
>>
>> Adding a few more people.
>>
>> This has been a big topic, and yes, we have a problem.
>>
>> We seem to have a few options:
>>
>> 1. We could always map 1:1, with the EFI mappings being in the "user"
>> part of the virtual address space. This MAY be what Windows does
>> already. Some Apple platforms are known to fail in this configuration,
>> but perhaps we can blacklist those platforms or do something special.
>>
>> 2. We could always map them into a fixed address that can be relied upon
>> to be consistent. The most logical such area is the second quadrant of
>> the address space (again, in the "user" portion.) It would be
>> beneficial if we could define it so that whenever Linux needs to go to
>> more than 48 virtual address bits at some point in the future this can
>> be compatible between 48-bit and N-bit kernels, but if that is the only
>> thing that breaks, then oh well.
>>
>> 3. We could just always map at the kernel virtual address. The 64-bit
>> address space is large enough that we could make every ioremap() land at
>> its identity-mapped address instead of in a unique part of the virtual
>> address space.
>>
>> 4. We could export a table of mappings to the kexec'd kernel. In that
>> case, we have to re-establish those mappings very early in the kernel
>> boot so that nothing else steps on them.
>>
>> What is quite interesting in your case is that you have a mishmash of
>> the identity-mapped and the non-identity-mapped mappings.
>
> Yeah, the mishmash comes from regions of type EFI_MEMORY_MAPPED_IO which
> are really ioremapped instead of returning the kernel virtual address.
>
> Btw, I always tend to like the simplest approaches so option 3.
> is kinda winking at me right now. I don't know whether for those
> EFI_MEMORY_MAPPED_IO type regions though, we can simply return the
> identity-mapped address.
>
> If we can, the advantage would be great because then the kexec kernel
> would simply parse the efi memmap and use __va() on the physical
> addresses there and no need for special option passing to it.
>
We can, and in fact we could do this for *all* ioremap()s in the 64-bit
kernel. This doesn't help the 32-bit kernel in any way, however.
One thing I *really* don't like about it is that it exposes the kernel
virtual address map as an ABI.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
