From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751712AbbI3EYx (ORCPT ); Wed, 30 Sep 2015 00:24:53 -0400 Received: from mail-ig0-f174.google.com ([209.85.213.174]:33144 "EHLO mail-ig0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751171AbbI3EYt (ORCPT ); Wed, 30 Sep 2015 00:24:49 -0400 MIME-Version: 1.0 In-Reply-To: References: <1443218539-7610-1-git-send-email-matt@codeblueprint.co.uk> <1443218539-7610-3-git-send-email-matt@codeblueprint.co.uk> <20150926060159.GB25877@gmail.com> <20150927070644.GC26125@gmail.com> <560B34EF.8040408@zytor.com> Date: Wed, 30 Sep 2015 06:24:48 +0200 Message-ID: Subject: Re: [PATCH 2/2] arm64/efi: Don't pad between EFI_MEMORY_RUNTIME regions From: Ard Biesheuvel To: Andy Lutomirski Cc: "H. Peter Anvin" , Ingo Molnar , Matt Fleming , Thomas Gleixner , "linux-kernel@vger.kernel.org" , "linux-efi@vger.kernel.org" , Leif Lindholm , Catalin Marinas , Will Deacon , "stable@vger.kernel.org" , Matt Fleming , Mark Rutland , Mark Salter , Linus Torvalds , Andrew Morton , Andy Lutomirski , Borislav Petkov , Denys Vlasenko , Brian Gerst Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 30 September 2015 at 03:16, Andy Lutomirski wrote: > On Tue, Sep 29, 2015 at 6:03 PM, H. Peter Anvin wrote: >> On 09/27/2015 12:06 AM, Ingo Molnar wrote: >>> >>> * Ard Biesheuvel wrote: >>> >>>>> If we allocate the EFI runtime as a single virtual memory block then issues >>>>> like rounding between sections does not even come up as a problem: we map the >>>>> original offsets and sizes byte by byte. >>>> >>>> Well, by that reasoning, we should not call SetVirtualAddressMap() in the first >>>> place, and just use the 1:1 mapping UEFI uses natively. This is more than >>>> feasible on arm64, and I actually fought hard against using >>>> SetVirtualAddressMap() at all, but I was overruled by others. I think this is >>>> also trivially possible on X64, since the 1:1 mapping is already active >>>> alongside the VA mapping. >>> >>> Could we please re-list all the arguments pro and contra of 1:1 physical mappings, >>> in a post that also explains the background so that more people can chime in, not >>> just people versed in EFI internals? It's very much possible that a bad decision >>> was made. >>> >> >> Pro: by far the sanest way to map the UEFI tables. >> Con: doesn't actually work (breaks on several known platforms.) > > Can we at least do 1:1 without an offset on arm64? Given that Linux > seems to be more of a reference on arm64 than Windows is, maybe that > would give everyone something vaguely sane to work with. > Yes, as I mentioned before in this thread, on arm64 this is very much feasible, and it was my strong preference all along. However, the arguments made by others that outweighed my preference were (a) x86 uses it (b) if we don't use it now, we will never be able to start using it later since it will undoubtedly be broken in /some/ implementation in the field. As I also mentioned, the only minor complication is that arm64's VA space may be configured to be smaller than the physical base of DRAM, but I already had to address that for the boot ID map and KVM as well. I will cook up a patch later today. -- Ard. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ard Biesheuvel Subject: Re: [PATCH 2/2] arm64/efi: Don't pad between EFI_MEMORY_RUNTIME regions Date: Wed, 30 Sep 2015 06:24:48 +0200 Message-ID: References: <1443218539-7610-1-git-send-email-matt@codeblueprint.co.uk> <1443218539-7610-3-git-send-email-matt@codeblueprint.co.uk> <20150926060159.GB25877@gmail.com> <20150927070644.GC26125@gmail.com> <560B34EF.8040408@zytor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: Sender: linux-efi-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Andy Lutomirski Cc: "H. Peter Anvin" , Ingo Molnar , Matt Fleming , Thomas Gleixner , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Leif Lindholm , Catalin Marinas , Will Deacon , "stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Matt Fleming , Mark Rutland , Mark Salter , Linus Torvalds , Andrew Morton , Andy Lutomirski , Borislav Petkov , Denys Vlasenko , Brian Gerst List-Id: linux-efi@vger.kernel.org On 30 September 2015 at 03:16, Andy Lutomirski wrote: > On Tue, Sep 29, 2015 at 6:03 PM, H. Peter Anvin wrote: >> On 09/27/2015 12:06 AM, Ingo Molnar wrote: >>> >>> * Ard Biesheuvel wrote: >>> >>>>> If we allocate the EFI runtime as a single virtual memory block then issues >>>>> like rounding between sections does not even come up as a problem: we map the >>>>> original offsets and sizes byte by byte. >>>> >>>> Well, by that reasoning, we should not call SetVirtualAddressMap() in the first >>>> place, and just use the 1:1 mapping UEFI uses natively. This is more than >>>> feasible on arm64, and I actually fought hard against using >>>> SetVirtualAddressMap() at all, but I was overruled by others. I think this is >>>> also trivially possible on X64, since the 1:1 mapping is already active >>>> alongside the VA mapping. >>> >>> Could we please re-list all the arguments pro and contra of 1:1 physical mappings, >>> in a post that also explains the background so that more people can chime in, not >>> just people versed in EFI internals? It's very much possible that a bad decision >>> was made. >>> >> >> Pro: by far the sanest way to map the UEFI tables. >> Con: doesn't actually work (breaks on several known platforms.) > > Can we at least do 1:1 without an offset on arm64? Given that Linux > seems to be more of a reference on arm64 than Windows is, maybe that > would give everyone something vaguely sane to work with. > Yes, as I mentioned before in this thread, on arm64 this is very much feasible, and it was my strong preference all along. However, the arguments made by others that outweighed my preference were (a) x86 uses it (b) if we don't use it now, we will never be able to start using it later since it will undoubtedly be broken in /some/ implementation in the field. As I also mentioned, the only minor complication is that arm64's VA space may be configured to be smaller than the physical base of DRAM, but I already had to address that for the boot ID map and KVM as well. I will cook up a patch later today. -- Ard.