Re: [PATCH 3/4] x86, efi: Add an efi= kernel command line parameter

2013-06-06 Thread Matt Fleming
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

Re: [PATCH 3/4] x86, efi: Add an efi= kernel command line parameter

2013-06-06 Thread Borislav Petkov
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

Re: [PATCH 3/4] x86, efi: Add an efi= kernel command line parameter

2013-06-06 Thread Matthew Garrett
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

Re: [PATCH 3/4] x86, efi: Add an efi= kernel command line parameter

2013-06-06 Thread Borislav Petkov
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

Re: [PATCH 3/4] x86, efi: Add an efi= kernel command line parameter

2013-06-06 Thread Borislav Petkov
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

Re: [PATCH 3/4] x86, efi: Add an efi= kernel command line parameter

2013-06-06 Thread Matthew Garrett
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

Re: [PATCH 3/4] x86, efi: Add an efi= kernel command line parameter

2013-06-06 Thread Borislav Petkov
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

Re: [PATCH 3/4] x86, efi: Add an efi= kernel command line parameter

2013-06-06 Thread Matthew Garrett
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:

Re: [PATCH 3/4] x86, efi: Add an efi= kernel command line parameter

2013-06-06 Thread Borislav Petkov
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

Re: [PATCH 3/4] x86, efi: Add an efi= kernel command line parameter

2013-06-06 Thread Borislav Petkov
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

Re: [PATCH 3/4] x86, efi: Add an efi= kernel command line parameter

2013-06-06 Thread Matthew Garrett
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