On Wed, Oct 02, 2013 at 11:46:44AM -0700, H. Peter Anvin wrote: > It's pretty straightforward - just drop the starting address to proper > alignment after you subtract the size. Ok, just an observation - it is not necessarily a bad thing but I thought we should talk about it: So, when we do the VA space saving mapping, we're basically mapping huge physical ranges onto a much smaller VA range and adding other mappings in there pots-factum could turn out to be not straight-forward and problematic. To illustrate what I'm trying to say, here's an example from two regions in OVMF: [ 0.011005] __map_region: VA: 0xfffffffeff800000..0xffffffff00000000 -> PA: 0x800000.. 0x1000000 [ 0.017005] __map_region: VA: 0xfffffffeff600000..0xfffffffeff620000 -> PA: 0x7c000000.. 0x7c020000 Now, the physical address range spanned by those regions is: 0x7c020000 - 0x800000 = 0x7b820000 =~ 2G while the virtual is 0xffffffff00000000 - 0xfffffffeff600000 = 0xa00000 =~ 10M Now, we obviously cannot map the whole PA space in there, the question is: do we care? I mean, we can map it to other VA range but this will totally destroy the simple math of computing EFI VA addresses with an offset, similar to PAGE_OFFSET. OTOH, if we keep Matt's suggestion of mapping the whole EFI address space window, we don't have that issue. And we've reserved 64G for EFI and if it needs more, we probably can give it since we're using a different pagetable anyway. Opinions? Thanks. -- 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
