"Luck, Tony" <tony.luck at intel.com> writes: >> does this affect ia64 in any way? > > I remember Eric complaining that set_virtual_address_map() was a one > way trap door with no way to get back to physical mode ... and thus > this was a big problem to support kexec on ia64. And yet we still call > it, and ia64 can do kexec. So some other work around must have been > found. Can't immediately remember what it was though. There is a hack in the code someplace on ia64 to pass the virtual address efi was mapped at to the next kernel, and have the kernel make certain to use efi there, without calling set_virtual_address_map(). For similar kernels that is fine at some point I expect kernel divergence will make that scheme unworkable. Essentially this is the same as using physical addresses but starting with the virtual addresses. For ia64 I seem to recall some weird floating point fixup routines that benefited from the speed set_virtual_address_map() provided. For x86_64 where the primary (sole?) reason for enabling EFI handling is to set efi variables from linux, I don't see a case where enabling virtual mode makes sense. If EFI stays around on x86, always running the calls in physical mode and in other ways slowly decreasing our dependence on perfect efi implementations seems necessary. As to Peter's question I did not see any of that code that affected anything that ia64 used. Eric
