Re: [PATCH -v2 0/4] EFI 1:1 mapping
If you cap it you are basically imposing a constraint on the firmware and may not run properly (or at least have to turn off EFI runtime calls with all that implies.) It might be good to have a sanity check but it needs to be pretty generous. Borislav Petkov b...@alien8.de wrote: On Thu, Jun 20, 2013 at 03:35:24PM -0700, H. Peter Anvin wrote: On 06/20/2013 11:47 AM, Borislav Petkov wrote: I guess we can do a top-down allocation, starting from the highest virtual addresses: EFI_HIGHEST_ADDRESS | | size1 | -- region1 | | size2 | -- region2 ... and we make EFI_HIGHEST_ADDRESS be the same absolute number on every system. hpa, is this close to what you had in mind? It would be prudent to verify whether this will suit well with the kexec virtual space layout though... This would work really well, I think. The tricky part here is to pick a safe EFI_HIGHEST_ADDRESS as it is an ABI. My preference would be to make EFI_HIGHEST_ADDRESS = -4 GB, which is *not* what Windows uses, but will leave the high negative range clear, and allows a range where we can grow down without much risk of interfering with anything else. Hmm, cool. Let me see whether my primitive math still has it: -(4 30) = 0x. Staring at Documentation/x86/x86_64/mm.txt, that's right in the unused hole, sandwiched between: ea00 - eaff (=40 bits) virtual memory map (1TB) - (=XX bits, not a lot :-), maybe 4, i.e. 64G) EFI 8000 - a000 (=512 MB) kernel text mapping, from phys 0 Now, if we go and do that, what are we going to say for the lower bound, in case later someone wants to use some more of the rest of the unused hole? Should we limit it to say 0x - 0xfff0 = 64G max EFI mappable region. Or am I too generous? The remaining hole is around (0xfff0 - 0xeaff) 40 = 20TB. Thanks. -- Sent from my mobile phone. Please excuse brevity and lack of formatting. -- 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 -v2 0/4] EFI 1:1 mapping
On Fri, Jun 21, 2013 at 03:05:30AM -0700, H. Peter Anvin wrote: If you cap it you are basically imposing a constraint on the firmware and may not run properly (or at least have to turn off EFI runtime calls with all that implies.) I don't want to cap EFI just for the fun of it but rather set a limit so that the next one who wants a chunk of the virtual address space can have a reliable limit from where she/he can start. Otherwise we won't know where EFI reliably ends... It might be good to have a sanity check but it needs to be pretty generous. 64 Gb generous enough? -- 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 -v2 0/4] EFI 1:1 mapping
* Matthew Garrett mj...@srcf.ucam.org wrote: On Wed, Jun 19, 2013 at 03:04:34PM +0200, Ingo Molnar wrote: * Borislav Petkov b...@alien8.de wrote: And yet there are the Macs which reportedly cannot stomach this. Do we know why? I got lost in a maze of pointer arithmetic. There seems to be an assumption that nvram writes should be forbidden if in runtime mode but with pointers still below the phys/virt split, which obviously makes no sense but hey. But, as always, the only reliable thing to do here is to behave as much like Windows as possible. [...] Amen ... [...] Which means performing the 1:1 mapping but maintaining the high mapping, and passing the high values via SetVirtualAddressMap. Cool - and supposedly this will work in a Mac environment as well? Would be very nice to avoid fundamentally fragile system specific quirks for something as fundamental as the EFI runtime memory mapping model ... Thanks, Ingo -- 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 -v2 0/4] EFI 1:1 mapping
On Thu, Jun 20, 2013 at 11:13:21AM +0200, Ingo Molnar wrote: Cool - and supposedly this will work in a Mac environment as well? Would be very nice to avoid fundamentally fragile system specific quirks for something as fundamental as the EFI runtime memory mapping model ... Apple is the only case where I'd expect there to be an issue, since they only started supporting booting Windows via UEFI on very recent systems. However, unless they're actually sniffing the page tables on UEFI entry, I can't see any way that this could break things… -- 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 -v2 0/4] EFI 1:1 mapping
On Thu, Jun 20, 2013 at 11:22:37AM +0200, Ingo Molnar wrote: Cool - and supposedly this will work in a Mac environment as well? Would be very nice to avoid fundamentally fragile system specific quirks for something as fundamental as the EFI runtime memory mapping model ... Apple is the only case where I'd expect there to be an issue, since they only started supporting booting Windows via UEFI on very recent systems. However, unless they're actually sniffing the page tables on UEFI entry, I can't see any way that this could break things??? Agreed - I was susprised to see that the runtime was able to _break_ in any way due to 1:1: my assumption was that it can only get better. But I did not realize that the 1:1 boot flag also changed what was passed down, which probably explains the breakages. Right, in the next version, the boot flag will influence only what's being passed down. I'd even argue to not do this whole boot flag thing at all - just standardize on the Windows compatibility model as closely as possible. This will break the Macs so maybe we can do efi=no_11_map so the Macs can still boot but use the 1:1 map by default. -- 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 -v2 0/4] EFI 1:1 mapping
On Thu, 20 Jun 2013, Matthew Garrett wrote: This will break the Macs so maybe we can do efi=no_11_map so the Macs can still boot but use the 1:1 map by default. I'm going to guess that there are more people running unmodified Linux kernels on Macs than there are people using kexec, I'd be careful in order not to underestimate how much kexec is being used. [At least some] distros are using it during installation process. -- Jiri Kosina SUSE Labs -- 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 -v2 0/4] EFI 1:1 mapping
On Thu, Jun 20, 2013 at 07:53:39AM -0700, James Bottomley wrote: Can't we detect Macs from some of the UEFI strings at boot time and do the right thing with the boot switch (which can be overriden from the kernel command line if we get it wrong)? Yes, and then our behaviour differs from Windows and so we'll have inevitably broken some other system. -- 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 -v2 0/4] EFI 1:1 mapping
On Thu, 20 Jun 2013, Matthew Garrett wrote: Can't we detect Macs from some of the UEFI strings at boot time and do the right thing with the boot switch (which can be overriden from the kernel command line if we get it wrong)? Yes, and then our behaviour differs from Windows How so? Windows don't work on those older Macs as well, do they? So if we properly detect those (and only those), we mimic Windows completely, right? -- Jiri Kosina SUSE Labs -- 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 -v2 0/4] EFI 1:1 mapping
On Thu, 2013-06-20 at 17:29 +0100, Matthew Garrett wrote: On Thu, Jun 20, 2013 at 07:53:39AM -0700, James Bottomley wrote: Can't we detect Macs from some of the UEFI strings at boot time and do the right thing with the boot switch (which can be overriden from the kernel command line if we get it wrong)? Yes, and then our behaviour differs from Windows and so we'll have inevitably broken some other system. Unless you can think of the way out of this, we seem to have the stark choice of behave like windows or allow kexec. For the server market, kexec wins, so either we find a way not to have to make the choice or we do something automatic to make it fairly painless. James -- 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 -v2 0/4] EFI 1:1 mapping
On Thu, Jun 20, 2013 at 06:44:46PM +0200, Jiri Kosina wrote: So if we properly detect those (and only those), we mimic Windows completely, right? No. Windows passes addresses above the phys/virt split to SetVirtualAddressMap(). -- 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 -v2 0/4] EFI 1:1 mapping
On Thu, Jun 20, 2013 at 09:46:15AM -0700, James Bottomley wrote: Unless you can think of the way out of this, we seem to have the stark choice of behave like windows or allow kexec. For the server market, kexec wins, so either we find a way not to have to make the choice or we do something automatic to make it fairly painless. hpa suggested ensuring that UEFI regions are mapped at fixed high offsets. Someone who cares about kexec should probably make that happen. -- 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 -v2 0/4] EFI 1:1 mapping
On Thu, Jun 20, 2013 at 05:54:26PM +0100, Matthew Garrett wrote: On Thu, Jun 20, 2013 at 09:46:15AM -0700, James Bottomley wrote: Unless you can think of the way out of this, we seem to have the stark choice of behave like windows or allow kexec. For the server market, kexec wins, so either we find a way not to have to make the choice or we do something automatic to make it fairly painless. hpa suggested ensuring that UEFI regions are mapped at fixed high offsets. Someone who cares about kexec should probably make that happen. If we can detect the Macs, we can make this decision automatic. And since no Mac boots windoze, a single DMI check of the sort if (Mac) should suffice. -- 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 -v2 0/4] EFI 1:1 mapping
On Thu, Jun 20, 2013 at 07:01:24PM +0200, Borislav Petkov wrote: If we can detect the Macs, we can make this decision automatic. And since no Mac boots windoze, a single DMI check of the sort if (Mac) should suffice. Yes, we can special-case Macs. But since our behaviour is then obviously different to Windows, we'll inevitably break some other system. -- 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 -v2 0/4] EFI 1:1 mapping
On Thu, Jun 20, 2013 at 06:12:10PM +0100, Matthew Garrett wrote: On Thu, Jun 20, 2013 at 07:01:24PM +0200, Borislav Petkov wrote: If we can detect the Macs, we can make this decision automatic. And since no Mac boots windoze, a single DMI check of the sort if (Mac) should suffice. Yes, we can special-case Macs. But since our behaviour is then obviously different to Windows, we'll inevitably break some other system. Why different? We'll have the high mappings and shove the 1:1 mappings down SetVirtualAddressMap by default. -- 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 -v2 0/4] EFI 1:1 mapping
On Thu, Jun 20, 2013 at 07:10:15PM +0100, Matthew Garrett wrote: Because Windows passes high addresses to SetVirtualAddressMap(), and because if you can imagine firmware developers getting it wrong then firmware developers will have got it wrong. Can we reversely assume that if we'd used fixed high offsets, as hpa suggests, then it'll be fine? IOW, are any high addresses, even fixed ones, fine? -- 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 -v2 0/4] EFI 1:1 mapping
On Thu, Jun 20, 2013 at 07:17:31PM +0100, Matthew Garrett wrote: On Thu, Jun 20, 2013 at 08:14:45PM +0200, Borislav Petkov wrote: On Thu, Jun 20, 2013 at 07:10:15PM +0100, Matthew Garrett wrote: Because Windows passes high addresses to SetVirtualAddressMap(), and because if you can imagine firmware developers getting it wrong then firmware developers will have got it wrong. Can we reversely assume that if we'd used fixed high offsets, as hpa suggests, then it'll be fine? IOW, are any high addresses, even fixed ones, fine? Windows actually seems to start at the top of address space and go down - this is what I get booting Windows 8 under kvm. It looks like very high addresses are fine, and we're currently using low high addresses, so I suspect we're fine pretty much anywhere in that range. ** SetVirtualAddressMap Type: 5 Physical Start: 3E878000 Virtual Start: FFBEB000 Number Of Pages: 15 Attributes: 800F Type: 6 Physical Start: 3E88D000 Virtual Start: FFBD6000 Number Of Pages: 15 Attributes: 800F Type: 5 Physical Start: 3FB22000 Virtual Start: FFBA6000 Number Of Pages: 30 Attributes: 800F Type: 6 Physical Start: 3FB52000 Virtual Start: FFB82000 Number Of Pages: 24 Attributes: 800F Type: 6 Physical Start: 3FFE Virtual Start: FFB62000 Number Of Pages: 20 I guess we can do a top-down allocation, starting from the highest virtual addresses: EFI_HIGHEST_ADDRESS | | size1 | -- region1 | | size2 | -- region2 ... and we make EFI_HIGHEST_ADDRESS be the same absolute number on every system. hpa, is this close to what you had in mind? It would be prudent to verify whether this will suit well with the kexec virtual space layout though... Thanks. -- 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 -v2 0/4] EFI 1:1 mapping
* Borislav Petkov b...@alien8.de wrote: From: Borislav Petkov b...@suse.de Hi all, this is just a snapshot of the current state of affairs. The patchset starts to boot successfully on real hardware now but we're far away from the coverage we'd like to have before we even consider upstreaming it. Looks pretty clean. And yes, considering the sick f*ck EFI is, we're keeping the 1:1 mapping optional and off by default (you need to boot with efi=1:1_map to enable it). I hope making it a weird boot option is not the end plan, there's little point in _not_ enabling 1:1 mappings by default eventually: the 1:1 mapping is supposed to emulate a Windows compatible EFI environment better and is expected to work around certain EFI runtime crashes. Thanks, Ingo -- 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 -v2 0/4] EFI 1:1 mapping
On Wed, Jun 19, 2013 at 02:52:43PM +0200, Ingo Molnar wrote: I hope making it a weird boot option is not the end plan, there's little point in _not_ enabling 1:1 mappings by default eventually: the 1:1 mapping is supposed to emulate a Windows compatible EFI environment better and is expected to work around certain EFI runtime crashes. And yet there are the Macs which reportedly cannot stomach this. And then there's the issue where some boxes cannot boot through the EFI stub with those patches even without efi=1:1_map on the command line. The issue has something to do with the cmpb $0, efi_use_11_map in the efi_callX stubs. And then again, other boxes have no problem with it and boot perfectly fine. So I don't know - it all looks like a weird boot, opt-in option for now. -- 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 -v2 0/4] EFI 1:1 mapping
* Borislav Petkov b...@alien8.de wrote: On Wed, Jun 19, 2013 at 02:52:43PM +0200, Ingo Molnar wrote: I hope making it a weird boot option is not the end plan, there's little point in _not_ enabling 1:1 mappings by default eventually: the 1:1 mapping is supposed to emulate a Windows compatible EFI environment better and is expected to work around certain EFI runtime crashes. And yet there are the Macs which reportedly cannot stomach this. Do we know why? And then there's the issue where some boxes cannot boot through the EFI stub with those patches even without efi=1:1_map on the command line. The issue has something to do with the cmpb $0, efi_use_11_map in the efi_callX stubs. A bug I suspect? And then again, other boxes have no problem with it and boot perfectly fine. So I don't know - it all looks like a weird boot, opt-in option for now. But once it works reliably we can enable it, right? Thanks, Ingo -- 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 -v2 0/4] EFI 1:1 mapping
On Wed, Jun 19, 2013 at 03:04:34PM +0200, Ingo Molnar wrote: Do we know why? Well, according to mjg59 some Macs break if we don't give them a map which uses high addresses. I can imagine flipping the meaning of this option to be on by default and efi=no_11_map to disable the 1:1 map for those Macs. A bug I suspect? Probably. The problem is, it is very hard to debug the boot stub that early. And of course, I can't reproduce it in qemu :(. If only I had a hardware debugger... But once it works reliably we can enable it, right? It's all the same to me - I hate EFI with passion so whatever people agree upon, I'll do it. -- 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 -v2 0/4] EFI 1:1 mapping
On Wed, Jun 19, 2013 at 03:02:25PM +0200, Borislav Petkov wrote: On Wed, Jun 19, 2013 at 02:52:43PM +0200, Ingo Molnar wrote: I hope making it a weird boot option is not the end plan, there's little point in _not_ enabling 1:1 mappings by default eventually: the 1:1 mapping is supposed to emulate a Windows compatible EFI environment better and is expected to work around certain EFI runtime crashes. And yet there are the Macs which reportedly cannot stomach this. I suspect they'll be fine with having a 1:1 map, as long as we pass the high mappings via SetVirtualAddressMap(). -- 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 -v2 0/4] EFI 1:1 mapping
On Wed, Jun 19, 2013 at 03:04:34PM +0200, Ingo Molnar wrote: * Borislav Petkov b...@alien8.de wrote: And yet there are the Macs which reportedly cannot stomach this. Do we know why? I got lost in a maze of pointer arithmetic. There seems to be an assumption that nvram writes should be forbidden if in runtime mode but with pointers still below the phys/virt split, which obviously makes no sense but hey. But, as always, the only reliable thing to do here is to behave as much like Windows as possible. Which means performing the 1:1 mapping but maintaining the high mapping, and passing the high values via SetVirtualAddressMap. -- 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 -v2 0/4] EFI 1:1 mapping
On Wed, Jun 19, 2013 at 05:08:04PM +0100, Matthew Garrett wrote: But, as always, the only reliable thing to do here is to behave as much like Windows as possible. Which means performing the 1:1 mapping but maintaining the high mapping, and passing the high values via SetVirtualAddressMap. We can't pass the high values via SetVirtualAddressMap and have EFI runtime in the kexec-ed kernel, as you and I established last week. And since not all would want EFI runtime in the kexec-ed kernel, I'm leaning more towards a boot-time option which enables the 1:1 mapping. Btw, why would you even want the 1:1 mappings if we pass the high values via SetVirtualAddressMap? -- 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 -v2 0/4] EFI 1:1 mapping
On Wed, Jun 19, 2013 at 06:18:27PM +0200, Borislav Petkov wrote: On Wed, Jun 19, 2013 at 05:08:04PM +0100, Matthew Garrett wrote: But, as always, the only reliable thing to do here is to behave as much like Windows as possible. Which means performing the 1:1 mapping but maintaining the high mapping, and passing the high values via SetVirtualAddressMap. We can't pass the high values via SetVirtualAddressMap and have EFI runtime in the kexec-ed kernel, as you and I established last week. And since not all would want EFI runtime in the kexec-ed kernel, I'm leaning more towards a boot-time option which enables the 1:1 mapping. Yes, kexec needs a different solution. Btw, why would you even want the 1:1 mappings if we pass the high values via SetVirtualAddressMap? Because firmware images don't always update all of the pointers, and so will crash if the 1:1 mappings aren't present. -- 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 -v2 0/4] EFI 1:1 mapping
On Wed, 2013-06-19 at 18:38 +0200, Borislav Petkov wrote: On Wed, Jun 19, 2013 at 05:21:15PM +0100, Matthew Garrett wrote: Yes, kexec needs a different solution. No need. If we say, efi=use_11_map, the 1:1 map will be shoved down SetVirtualAddressMap. Otherwise the high mappings. Because firmware images don't always update all of the pointers, and so will crash if the 1:1 mappings aren't present. Ok, so it sounds like we want to *always* create both mappings but, depending on what we want, to shove down SetVirtualAddressMap a different set. And the 1:1 map will be the optional one which we give SetVirtualAddressMap only when user wants it, i.e. when booting with efi=1:1_map. Makes sense? I think it will work. The only thing I'd worry about is aliasing. This scheme clearly won't work for any virtually indexed processor (so it's basically x86 only) but even on Physically Indexed, you do have to make sure the cache attributes of any given page are the same for all virtual address aliases. As long as the 1:1 mapping is writeback, I think this is satisfied. James -- 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 -v2 0/4] EFI 1:1 mapping
On Wed, Jun 19, 2013 at 05:48:22PM +0100, Matthew Garrett wrote: Ok, so it sounds like we want to *always* create both mappings but, depending on what we want, to shove down SetVirtualAddressMap a different set. And the 1:1 map will be the optional one which we give SetVirtualAddressMap only when user wants it, i.e. when booting with efi=1:1_map. Yup, I think that sounds ideal. Crap, I got completely sidetracked. The 1:1 mappings go in a different pagetable (real_mode_header-trampoline_pgd) than the kernel one (i.e. init_mm.pgd). However, the -trampoline_pgd has all mappings anyway, which means that if we want to do EFI runtime calls with the high mappings but *also* have the 1:1 mappings established, we should *always* switch to that pagetable when doing those calls. hpa, MattF, agreed? -- 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 -v2 0/4] EFI 1:1 mapping
On 06/19/2013 08:02 AM, Borislav Petkov wrote: And yet there are the Macs which reportedly cannot stomach this. No, the reports are that if you use the 1:1 map as the primary address on Macs the drivers fail... not that you can't have a 1:1 map. -hpa -- 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 -v2 0/4] EFI 1:1 mapping
On Wed, Jun 19, 2013 at 12:25:42PM -0500, H. Peter Anvin wrote: On 06/19/2013 08:02 AM, Borislav Petkov wrote: And yet there are the Macs which reportedly cannot stomach this. No, the reports are that if you use the 1:1 map as the primary address on Macs the drivers fail... not that you can't have a 1:1 map. That's what I meant: ... cannot stomach when the 1:1 map is shoved down SetVirtualAddressMap. The thing is, if we want to have both the 1:1 map and the high map during an EFI runtime call, we would need to *always* switch the pagetable for an EFI runtime call and establish both mappings in -trampoline_pgd beforehand. -- 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 -v2 0/4] EFI 1:1 mapping
On 06/19/2013 12:37 PM, Borislav Petkov wrote: On Wed, Jun 19, 2013 at 12:25:42PM -0500, H. Peter Anvin wrote: On 06/19/2013 08:02 AM, Borislav Petkov wrote: And yet there are the Macs which reportedly cannot stomach this. No, the reports are that if you use the 1:1 map as the primary address on Macs the drivers fail... not that you can't have a 1:1 map. That's what I meant: ... cannot stomach when the 1:1 map is shoved down SetVirtualAddressMap. The thing is, if we want to have both the 1:1 map and the high map during an EFI runtime call, we would need to *always* switch the pagetable for an EFI runtime call and establish both mappings in -trampoline_pgd beforehand. I thought that was the plan? -hpa -- 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 -v2 0/4] EFI 1:1 mapping
On Wed, Jun 19, 2013 at 12:38:24PM -0500, H. Peter Anvin wrote: I thought that was the plan? Well, currently if I'm booted with efi=1:1_map I'm creating only the 1:1 mapping in -trampoline_pgd and switching the pagetable only then. Otherwise, I'm using the high, ioremapped mappings - i.e., what we have now. I guess I can sync the kernel address space into -trampoline_pgd after having created the 1:1 mappings and always switch the pagetable later, after we've done SetVirtualAddressMap. Which should take care of the EFI boot stub issue too, as I can define another set of efi_callX which switch the pagetable unconditionally. Let me see how that pans out... -- 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
[PATCH -v2 0/4] EFI 1:1 mapping
From: Borislav Petkov b...@suse.de Hi all, this is just a snapshot of the current state of affairs. The patchset starts to boot successfully on real hardware now but we're far away from the coverage we'd like to have before we even consider upstreaming it. And yes, considering the sick f*ck EFI is, we're keeping the 1:1 mapping optional and off by default (you need to boot with efi=1:1_map to enable it). Matt has picked up 1/4 already so I'll drop it when it lands into -tip and so on... Thanks for any suggestions, as always. Borislav Petkov (4): efi: Convert runtime services function ptrs x86, cpa: Map in an arbitrary pgd x86, efi: Add an efi= kernel command line parameter x86, efi: Map runtime services 1:1 arch/x86/boot/compressed/eboot.c | 2 +- arch/x86/include/asm/efi.h | 81 ++- arch/x86/include/asm/pgtable_types.h | 3 +- arch/x86/mm/pageattr.c | 82 arch/x86/platform/efi/efi.c | 184 +-- arch/x86/platform/efi/efi_stub_64.S | 56 +++ include/linux/efi.h | 28 +++--- 7 files changed, 348 insertions(+), 88 deletions(-) -- 1.8.3 -- 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
