Re: [PATCH -v2] EFI: Runtime services virtual mapping
From: Borislav Petkov
Date: Wed Oct 02 2013 - 06:04:36 EST
On Mon, Sep 23, 2013 at 08:06:38PM -0700, H. Peter Anvin wrote:
> Okay... I see two problems.
>
> 1. It looks like we subtract the region size after, rather than before, assigning an address.
>
Ok, so I'm looking at this agan and, actually, we really do subtract the
region size *before* we assign the address:
---
efi_va -= size;
if (efi_va < EFI_VA_END) {
pr_warning(FW_WARN "VA address range overflow!\n");
return;
}
/*
* Make sure the 1:1 mappings are present as a catch-all for b0rked
* firmware which doesn't update all internal pointers after switching
* to virtual mode and would otherwise crap on us.
*/
__map_region(md, md->phys_addr);
/* Do the VA map */
__map_region(md, efi_va);
md->virt_addr = efi_va;
--
So let me give an example why I think it is correct to subtract *before*
assigning and so that we can talk about it and we completely agree on
the details. :-)
When we start allocating from -4G, i.e. 0xffffffff00000000, I think we
want to do it bottom-up so that 0xffffffff00000000 is the *last*, i.e.
lowest address. Because we link the kernel text at 0xffffffff81000000 by
default, which would mean, if -4G was the first address, we'll have only
2G:
0xffffffff81000000 - 0xffffffff00000000 = 0x0000000081000000 = 2.164.260.864 bytes
of space for UEFI mappings.
That's why, I need to *first* subtract and *then* use the resulting
address to map the region to. Like so (4 hypothetical regions):
1st region: 0xfffffffeffffe000 - 0xffffffff00000000
2nd region: 0xfffffffeffff8000 - 0xfffffffeffffe000
3rd region: 0xfffffffefffec000 - 0xfffffffeffff8000
4th region: 0xfffffffefffd8000 - 0xfffffffefffec000
and so on...
IOW, the VA layout looks like this:
0xfffffffefffd8000
...
region 4
...
0xfffffffefffec000 (non including)
...
region 3
...
0xfffffffeffff8000 (ditto)
...
region 2
...
0xfffffffeffffe000 (ditto)
...
region 1
...
0xffffffff00000000 (ditto)
Am I even making sense here?
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/