On Thu, Mar 07, 2013 at 11:25:14PM -0800, Yinghai Lu wrote: > >> > Why is this table made a stack variable? What's the benefit of doing > >> > that? > >> > >> so I do need to switch global variables to phys and access it. > > > > I can't really understand what your response means. Can you please > > elaborate? > > sorry, I missed NOT. > > so I do NOT need to switch global variables from kernel virtual addr > to phys address and access it > in 32bit flat mode. Ah, okay, so the function is called with a completely different address mode and so you actually want to build the table on stack so that you don't have to flip the address mode for the global address. > >> yes, one for 32bit from head_32.S, phys. > >> one for 64bit from head64.c. with _va. > > > > head64.c can't call with phys? Why not? > > HPA's #PF set up page table only handle kernel low mapping address. > > and after reset_early_page_tables, only kernel high mapping address is > there. and other low mapping will be supported via #PF handler. Okay, it now makes sense. Ah.... You'll definitely need a lot of documentation explanining what's going on. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
