We can do that... but it is different from what Windows does to my understanding and it also has the potential of severe pathologies... e.g. a window at the top of the address space being mapped. Borislav Petkov <bp@xxxxxxxxx> wrote: >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. -- Sent from my mobile phone. Please pardon brevity and lack of formatting. -- 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
