On 29 June 2016 at 18:50, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote:
> On 29 June 2016 at 18:45, Catalin Marinas <catalin.marinas@xxxxxxx> wrote:
>> On Wed, Jun 29, 2016 at 02:51:28PM +0200, Ard Biesheuvel wrote:
>>> + if (!PAGE_ALIGNED(md->phys_addr) ||
>>> + !PAGE_ALIGNED(md->num_pages << EFI_PAGE_SHIFT)) {
>>> + /*
>>> + * If the end address of this region is not aligned to page
>>> + * size, the mapping is rounded up, and may end up sharing a
>>> + * page frame with the next UEFI memory region. If we create
>>> + * a block entry now, we may need to split it again when mapping
>>> + * the next region, and support for that is going to be removed
>>> + * from the MMU routines. So avoid block mappings altogether in
>>> + * that case.
>>> + */
>>> + allow_block_mappings = false;
>>> + }
>>
>> How common is it for large areas to have unaligned start/end? I wonder
>> whether it's worth implementing my approach to look ahead and explicitly
>> check the overlap with the next section instead of disabling block
>> mappings altogether for this region.
>>
>
> Very uncommon. Typically, only MMIO regions that represent NOR flash
> are larger than a couple of pages. Taken from QEMU:
RT_Code : 640 Pages (2,621,440 Bytes)
RT_Data : 880 Pages (3,604,480 Bytes)
so all RT_Code regions *combined* are 2.5 MB in total, and all RT_Data
regions 3.5 MB. Ideally, they are grouped together, but in reality,
there are always a couple of regions of each type, so there is little
to gain here from using block mappings
--
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
