On Thu, 2013-11-14 at 22:59 +0800, Yi Li wrote:
Hi Andrea/Al,
I set the ARM64 flag for DMI support on v8, because io_remap()can not work in dmi_scan.c , but early_memremap() can work.
I suppose we consider ACPI/EFI memory as IO range on v7, but wecovert them into MEMORY type on v8. I do not know whether you met the same problem with me on acpi_early_init(), you can try MARK's patch: https://github.com/mosalter/linux/commit/c195e4a19b4b6c92885714941cf89a21904...
To clarify, the underlying issue is that armv7 and armv8 may not have more than one virtual mapping to a given physical page if the caching attributes differ in those mappings. x86 and ia64 don't have this restriction. At boot time, the kernel creates a cacheable mapping of all RAM pages for kernel use. The armv7 patches work around this problem by not including the areas used by uefi, dmi, acpi, etc in this kernel mapping of RAM.
So, if the dmi (or acpi) tables are in RAM which the kernel has already mapped, then neither early_ioremap() nor ioremap() are safe to use. One could get away with early_ioremap() if the area is unmapped prior to paging_init() doing the kernel RAM mapping.
The dmi caode has only been used by ia64 and x86 to date. The code has an early dmi table walk where dmi_ioremap() is used and a normal (after paging_init() is called) table walk where ioremap() is used. The ioremap on ia64 works before and after paging_init() so dmi_ioremap() is just ioremap() there. On x86, dmi_ioremap() is defined as early_ioremap().
Taking all that into account, my feeling is that using ioremap() in dmi_walk() is not correct. The mapping function is necessarily arch specific. I think the best thing to do here is to have a dmi_ioremap() for dmi_walk() and dmi_early_ioremap() for dmi_walk_early(). For armv8 this would be:
#define dmi_ioremap ioremap_cache #define dmi_early_ioremap early_memremap
And, of course:
#define dmi_iounmap iounmap #define dmi_early_iounmap early_iounmap
--Mark