Messages in this thread | | | Subject | Re: [PATCH] Fix e820 end address with EFI | From | Huang Ying <> | Date | Tue, 03 Mar 2009 09:07:39 +0800 |
| |
On Tue, 2009-03-03 at 05:38 +0800, Yinghai Lu wrote: > Huang Ying wrote: > > On Mon, 2009-03-02 at 10:51 +0800, Yinghai Lu wrote: > >> On Sun, Mar 1, 2009 at 6:37 PM, Huang Ying <ying.huang@intel.com> wrote: > >>>> so 64bit could use ioremap_cache() too? > >>>> we may keep 32bit and 64bit a bit consistent. > >>> If we use ioremap_cache(), kexec runtime service will not work in kexec > >>> situation, which needs EFI runtime memory area to be mapped at exact > >>> same location across kexec. I think we should support kexec if possible. > >> > >> sure. > >> > >> please don't touch max_low_pfn_mapped, because some range may not > >> directly mapped under those efi run-time code > > > > Find an issue to use init_memory_mapping() here. > > > > If the memory range to be mapped is less than 2M, the last mapped > > address may be next 2M aligned position, this may lead mapping > > overlapping between memory range. Such as: > > > > 0x3f388000 - 0x3f488000: real mapped 0x3f388000 - 0x3f600000 > > 0x3f590000 - 0x3f5bb000: real mapped 0x3f590000 - 0x3f600000 > > > > The problem is that the memory range 0x3f400000 - 0x3f590000 is left not > > mapped! > > what is max_low_pfn_mapped before that?
I don't know exactly what you mean. Can you elaborate a little?
0 ~ max_low_pfn_mapped ~ max_pfn_mapped can be mapped with init_memory_mapping() properly.
The issue of above example is that 0x3f400000 ~ 0x3f488000 is a sub-range of 0x3f388000 ~ 0x3f488000, which should be mapped but is left not mapped.
Best Regards, Huang Ying
[unhandled content-type:application/pgp-signature] | |