All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeffrey Hugo <jhugo@codeaurora.org>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>, linux-efi@vger.kernel.org
Cc: mark.rutland@arm.com, Heinrich Schuchardt <xypron.glpk@gmx.de>,
	will.deacon@arm.com, Alexander Graf <agraf@suse.de>,
	Leif Lindholm <leif.lindholm@linaro.org>,
	AKASHI Takahiro <takahiro.akashi@linaro.org>,
	james.morse@arm.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] efi: arm/arm64: allow SetVirtualAddressMap() to be omitted
Date: Mon, 28 Jan 2019 11:04:41 -0700	[thread overview]
Message-ID: <abc36cf9-4fa1-da12-bb94-34d850ae34ec@codeaurora.org> (raw)
In-Reply-To: <20190126102207.29488-1-ard.biesheuvel@linaro.org>

On 1/26/2019 3:22 AM, Ard Biesheuvel wrote:
> The UEFI spec revision 2.7 errata A section 8.4 has the following to
> say about the virtual memory runtime services:
> 
>    "This section contains function definitions for the virtual memory
>    support that may be optionally used by an operating system at runtime.
>    If an operating system chooses to make EFI runtime service calls in a
>    virtual addressing mode instead of the flat physical mode, then the
>    operating system must use the services in this section to switch the
>    EFI runtime services from flat physical addressing to virtual
>    addressing."
> 
> So it is pretty clear that calling SetVirtualAddressMap() is entirely
> optional, and so there is no point in doing so unless it achieves
> anything useful for us.
> 
> This is not the case for 64-bit ARM. The native mapping used by the OS
> is arbitrarily converted into another permutation of userland addresses
> (i.e., bits [63:48] cleared), and the runtime code could easily deal
> with the original layout in exactly the same way as it deals with the
> converted layout. However, due to constraints related to page size
> differences if the OS is not running with 4k pages, and related to
> systems that may expose the individual sections of PE/COFF runtime
> modules as different memory regions, creating the virtual layout is a
> bit fiddly, and requires us to sort the memory map and reason about
> adjacent regions with identical memory types etc etc.
> 
> So the obvious fix is to stop calling SetVirtualAddressMap() altogether
> on arm64 systems. However, to avoid surprises, which are notoriously
> hard to diagnose when it comes to OS<->firmware interactions, let's
> start by making it an opt-out feature, and implement support for the
> 'efi=novamap' kernel command line parameter on ARM and arm64 systems.
> 
> (Note that 32-bit ARM generally does require SetVirtualAddressMap() to be
> used, given that the physical memory map and the kernel virtual address
> map are not guaranteed to be non-overlapping like on arm64. However,
> having support for efi=novamap,noruntime on 32-bit ARM, combined with
> the recently proposed support for earlycon=efi, is likely to be useful
> to diagnose boot issues on such systems if they have no accessible serial
> port)
> 
> Cc: Alexander Graf <agraf@suse.de>
> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
> Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
> Cc: Leif Lindholm <leif.lindholm@linaro.org>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---

I threw this at msm8998 (arm64), and it seem to work fine as far as I 
can tell.

For what it's worth:
Tested-by: Jeffrey Hugo <jhugo@codeaurora.org>

-- 
Jeffrey Hugo
Qualcomm Datacenter Technologies as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

WARNING: multiple messages have this Message-ID (diff)
From: Jeffrey Hugo <jhugo@codeaurora.org>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>, linux-efi@vger.kernel.org
Cc: mark.rutland@arm.com, Heinrich Schuchardt <xypron.glpk@gmx.de>,
	will.deacon@arm.com, Alexander Graf <agraf@suse.de>,
	Leif Lindholm <leif.lindholm@linaro.org>,
	AKASHI Takahiro <takahiro.akashi@linaro.org>,
	james.morse@arm.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] efi: arm/arm64: allow SetVirtualAddressMap() to be omitted
Date: Mon, 28 Jan 2019 11:04:41 -0700	[thread overview]
Message-ID: <abc36cf9-4fa1-da12-bb94-34d850ae34ec@codeaurora.org> (raw)
In-Reply-To: <20190126102207.29488-1-ard.biesheuvel@linaro.org>

On 1/26/2019 3:22 AM, Ard Biesheuvel wrote:
> The UEFI spec revision 2.7 errata A section 8.4 has the following to
> say about the virtual memory runtime services:
> 
>    "This section contains function definitions for the virtual memory
>    support that may be optionally used by an operating system at runtime.
>    If an operating system chooses to make EFI runtime service calls in a
>    virtual addressing mode instead of the flat physical mode, then the
>    operating system must use the services in this section to switch the
>    EFI runtime services from flat physical addressing to virtual
>    addressing."
> 
> So it is pretty clear that calling SetVirtualAddressMap() is entirely
> optional, and so there is no point in doing so unless it achieves
> anything useful for us.
> 
> This is not the case for 64-bit ARM. The native mapping used by the OS
> is arbitrarily converted into another permutation of userland addresses
> (i.e., bits [63:48] cleared), and the runtime code could easily deal
> with the original layout in exactly the same way as it deals with the
> converted layout. However, due to constraints related to page size
> differences if the OS is not running with 4k pages, and related to
> systems that may expose the individual sections of PE/COFF runtime
> modules as different memory regions, creating the virtual layout is a
> bit fiddly, and requires us to sort the memory map and reason about
> adjacent regions with identical memory types etc etc.
> 
> So the obvious fix is to stop calling SetVirtualAddressMap() altogether
> on arm64 systems. However, to avoid surprises, which are notoriously
> hard to diagnose when it comes to OS<->firmware interactions, let's
> start by making it an opt-out feature, and implement support for the
> 'efi=novamap' kernel command line parameter on ARM and arm64 systems.
> 
> (Note that 32-bit ARM generally does require SetVirtualAddressMap() to be
> used, given that the physical memory map and the kernel virtual address
> map are not guaranteed to be non-overlapping like on arm64. However,
> having support for efi=novamap,noruntime on 32-bit ARM, combined with
> the recently proposed support for earlycon=efi, is likely to be useful
> to diagnose boot issues on such systems if they have no accessible serial
> port)
> 
> Cc: Alexander Graf <agraf@suse.de>
> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
> Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
> Cc: Leif Lindholm <leif.lindholm@linaro.org>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---

I threw this at msm8998 (arm64), and it seem to work fine as far as I 
can tell.

For what it's worth:
Tested-by: Jeffrey Hugo <jhugo@codeaurora.org>

-- 
Jeffrey Hugo
Qualcomm Datacenter Technologies as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2019-01-28 18:04 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-26 10:22 [PATCH] efi: arm/arm64: allow SetVirtualAddressMap() to be omitted Ard Biesheuvel
2019-01-26 10:22 ` Ard Biesheuvel
2019-01-26 12:27 ` Heinrich Schuchardt
2019-01-26 12:27   ` Heinrich Schuchardt
2019-01-26 12:28   ` Ard Biesheuvel
2019-01-26 12:28     ` Ard Biesheuvel
2019-01-26 12:34     ` Alexander Graf
2019-01-26 12:34       ` Alexander Graf
2019-01-26 14:33       ` Heinrich Schuchardt
2019-01-26 14:33         ` Heinrich Schuchardt
2019-01-26 15:03         ` Ard Biesheuvel
2019-01-26 15:03           ` Ard Biesheuvel
2019-01-26 16:49           ` Ard Biesheuvel
2019-01-26 16:49             ` Ard Biesheuvel
2019-01-28 18:04 ` Jeffrey Hugo [this message]
2019-01-28 18:04   ` Jeffrey Hugo
2019-01-28 18:24   ` Ard Biesheuvel
2019-01-28 18:24     ` Ard Biesheuvel
2019-01-30  0:06 ` Bjorn Andersson
2019-01-30  0:06   ` Bjorn Andersson
2019-01-30  9:40   ` Ard Biesheuvel
2019-01-30  9:40     ` Ard Biesheuvel
2019-01-30 18:19 ` Will Deacon
2019-01-30 18:19   ` Will Deacon
2019-01-30 18:29   ` Ard Biesheuvel
2019-01-30 18:29     ` Ard Biesheuvel
2019-02-01  8:06 ` Lee Jones

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=abc36cf9-4fa1-da12-bb94-34d850ae34ec@codeaurora.org \
    --to=jhugo@codeaurora.org \
    --cc=agraf@suse.de \
    --cc=ard.biesheuvel@linaro.org \
    --cc=james.morse@arm.com \
    --cc=leif.lindholm@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=takahiro.akashi@linaro.org \
    --cc=will.deacon@arm.com \
    --cc=xypron.glpk@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.