Run EFI in physical mode
in [Kernel]
|
Prev: platform: Facilitate the creation of pseudo-platform buses
Next: rados block device and ceph refactor
From: H. Peter Anvin on 13 Aug 2010 18:30 On 08/13/2010 12:18 PM, Takao Indoh wrote: > > Basically EFI is in physical mode at first and it's switched to virtual > mode after calling SetVirtualAddressMap. By applying this patch, you can > run EFI always in physical mode. And you can also specify "virtefi" as > kernel boot parameter to run EFI in virtual mode as before. Note that > this patch supports only x86_64. > Any hope to get a followon patch for i386 as well? That would make it largely a no-brainer. Tony, does this affect ia64 in any way? -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Luck, Tony on 13 Aug 2010 18:40 > 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. -Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 13 Aug 2010 19:20 On 08/13/2010 04:11 PM, Eric W. Biederman wrote: > > As to Peter's question I did not see any of that code that affected > anything that ia64 used. > I guess my real question was "is this something IA64 could benefit from and/or could we make the IA64 code more similar to the x86 bits"? -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Eric W. Biederman on 13 Aug 2010 19:20 "Luck, Tony" <tony.luck(a)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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Tony Luck on 13 Aug 2010 19:40
On Fri, Aug 13, 2010 at 4:16 PM, H. Peter Anvin <hpa(a)zytor.com> wrote: > I guess my real question was "is this something IA64 could benefit from > and/or could we make the IA64 code more similar to the x86 bits"? If Eric's recollection about the "weird floating point fixup routines"[1] performance issues are correct - then ia64 won't want to do this. -Tony [1] more usually called FPSWA - floating point software assist - which handle a bunch or corner cases in denormalized floating point values that the h/w doesn't cover. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |