Re: [PATCH 3/4] x86, efi: Add an efi= kernel command line parameter
On Thu, 06 Jun, at 03:26:03PM, Borislav Petkov wrote:
On Thu, Jun 06, 2013 at 11:42:24AM +0100, Matt Fleming wrote:
On Sun, 02 Jun, at 02:56:09PM, Borislav Petkov wrote:
+
+static int __init parse_efi_cmdline(char *str)
+{
+ if (*str == '=')
+ str++;
+ if (!strncmp(str, 1:1_map, 7))
+ efi_config |= EFI_CFG_MAP11;
+
+ return 0;
+}
+early_param(efi, parse_efi_cmdline);
This is fine for testing, but I genuinely think that this should be on
by default once these patches are final.
This would break the Macs, remember?
We could make it be the default though and flip the logic so that users
can fall back to the current ioremap functionality, i.e. boot with
efi=no_1:1_map.
Yeah, or white/blacklist them. We've already had enough of Oh, your
machine used to work but now it's bust? Yeah, turn on this cmdline
parameter to get things working again.
But the point is that the funnies that have been seen on the Macs should
be treated as the unusual case. The number of machines I've seen that
require this 1:1 map is staggering, especially once you start poking at
some of the other runtime services, like UpdateCapsule().
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] x86, efi: Add an efi= kernel command line parameter
On Thu, Jun 06, 2013 at 06:50:52PM +0100, Matthew Garrett wrote: On Thu, Jun 06, 2013 at 03:26:03PM +0200, Borislav Petkov wrote: This would break the Macs, remember? I think the Macs will be fine as long as we're passing the high mappings into SetVirtualAddressMap(). Right, on those we'll fall back to the current mappings and simply not have the 1:1 thing. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] x86, efi: Add an efi= kernel command line parameter
On Thu, Jun 06, 2013 at 08:51:40PM +0200, Borislav Petkov wrote: On Thu, Jun 06, 2013 at 06:50:52PM +0100, Matthew Garrett wrote: On Thu, Jun 06, 2013 at 03:26:03PM +0200, Borislav Petkov wrote: This would break the Macs, remember? I think the Macs will be fine as long as we're passing the high mappings into SetVirtualAddressMap(). Right, on those we'll fall back to the current mappings and simply not have the 1:1 thing. No, I think that's the wrong thing to do. We should set up the current mappings and the 1:1 mappings, and pass the current mappings through SetVirtualAddressMap(). That matches the behaviour of Windows. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] x86, efi: Add an efi= kernel command line parameter
On Thu, Jun 06, 2013 at 08:35:48PM +0100, Matthew Garrett wrote: No, I think that's the wrong thing to do. We should set up the current mappings and the 1:1 mappings, and pass the current mappings through SetVirtualAddressMap(). That matches the behaviour of Windows. And when do we use the 1:1 mappings and when the current mappings when doing runtime calls? Also, would the 1:1 mappings even work if not passed through SetVirtualAddressMap? I'm sensing a yes but I don't know... -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] x86, efi: Add an efi= kernel command line parameter
On Thu, Jun 06, 2013 at 08:54:50PM +0100, Matthew Garrett wrote: We want both to be available when we're making the call, but I think we should probably enter via the high addresses. The only reason we're doing this at all is that some systems don't update all of their pointers from physical mode, and we'd prefer them to work rather than fault... Actually, we do the 1:1 thing so that EFI runtime works in a kexec kernel too. Which won't work if we use the high addresses. However, if we can use the 1:1 map *after* SetVirtualAddressMap() has been called with the high mappings, then my issue is solved - we drop to using 1:1 in the kexec kernel only. But I don't think that is the case... -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] x86, efi: Add an efi= kernel command line parameter
On Thu, Jun 06, 2013 at 10:07:05PM +0200, Borislav Petkov wrote: On Thu, Jun 06, 2013 at 08:54:50PM +0100, Matthew Garrett wrote: We want both to be available when we're making the call, but I think we should probably enter via the high addresses. The only reason we're doing this at all is that some systems don't update all of their pointers from physical mode, and we'd prefer them to work rather than fault... Actually, we do the 1:1 thing so that EFI runtime works in a kexec kernel too. Which won't work if we use the high addresses. kexec seems like a lower priority than compatibility. Perhaps keep the efi argument for people who want to use kexec? hpa suggested allocating a fixed high area for UEFI mappings, which would also solve this. However, if we can use the 1:1 map *after* SetVirtualAddressMap() has been called with the high mappings, then my issue is solved - we drop to using 1:1 in the kexec kernel only. But I don't think that is the case... Yeah, calling SetVirtualAddressMap() with high addresses is going to result in the firmware having a bunch of pointers to high addresses. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] x86, efi: Add an efi= kernel command line parameter
On Thu, Jun 06, 2013 at 09:18:28PM +0100, Matthew Garrett wrote: kexec seems like a lower priority than compatibility. Perhaps keep the efi argument for people who want to use kexec? This is what I currently have in the code: if you boot with efi=1:1_map, you get them. hpa suggested allocating a fixed high area for UEFI mappings, which would also solve this. I guess we can do that too. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] x86, efi: Add an efi= kernel command line parameter
On Thu, Jun 06, 2013 at 10:27:17PM +0200, Borislav Petkov wrote: On Thu, Jun 06, 2013 at 09:18:28PM +0100, Matthew Garrett wrote: kexec seems like a lower priority than compatibility. Perhaps keep the efi argument for people who want to use kexec? This is what I currently have in the code: if you boot with efi=1:1_map, you get them. Well, we want the 1:1 mappings to exist all the time. The only thing the option should change is whether they're passed to SetVirtualAddressMap() or not. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] x86, efi: Add an efi= kernel command line parameter
On Thu, Jun 06, 2013 at 09:30:57PM +0100, Matthew Garrett wrote: Well, we want the 1:1 mappings to exist all the time. The only thing the option should change is whether they're passed to SetVirtualAddressMap() or not. But can you call them even if they haven't been passed through SetVirtualAddressMap, *after* SetVirtualAddressMap has been called? -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] x86, efi: Add an efi= kernel command line parameter
On Thu, Jun 06, 2013 at 09:50:57PM +0100, Matthew Garrett wrote: What do you mean by call them? I don't think we ever want to call by physical address, other than maybe in the kexec case. The only reason we really care about the physical addresses being mapped 1:1 is that some pointers may not have been updated. I want to be able to call the runtime services in the kexec kernel. Which means, the kexec kernel would simply map the runtime code/data regions 1:1 and then use the physical addresses to call the runtime services. Question is: would that work even if SetVirtualAddressMap has already run in the original kernel and with virtual addresses? -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] x86, efi: Add an efi= kernel command line parameter
On Thu, Jun 06, 2013 at 11:02:18PM +0200, Borislav Petkov wrote: On Thu, Jun 06, 2013 at 09:50:57PM +0100, Matthew Garrett wrote: What do you mean by call them? I don't think we ever want to call by physical address, other than maybe in the kexec case. The only reason we really care about the physical addresses being mapped 1:1 is that some pointers may not have been updated. I want to be able to call the runtime services in the kexec kernel. Which means, the kexec kernel would simply map the runtime code/data regions 1:1 and then use the physical addresses to call the runtime services. Question is: would that work even if SetVirtualAddressMap has already run in the original kernel and with virtual addresses? No. You'll need to have an option for that case. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
