Currently, memory regions are only recorded in the memblock memory table
if they have the EFI_MEMORY_WB memory type attribute set. In case the
region is of a reserved type, it is also marked as MEMBLOCK_NOMAP, which
will leave it out of the linear mapping.
However, memory regions may legally have the EFI_MEMORY_WT or EFI_MEMORY_WC
attributes set, and the EFI_MEMORY_WB cleared, in which case the region in
question is obviously backed by normal memory, but is not recorded in the
memblock memory table at all. Since it would be useful to be able to
identify any UEFI reported memory region using memblock_is_memory(), it
makes sense to add all memory to the memblock memory table, and simply mark
it as MEMBLOCK_NOMAP if it lacks the EFI_MEMORY_WB attribute.
While implementing this, let's refactor the code slightly to make it easier
to understand: replace is_normal_ram() with is_memory(), and make it return
true for each region that has any of the WB|WT|WC bits set. (This follows
the AArch64 bindings in the UEFI spec, which state that those are the
attributes that map to normal memory)
Also, replace is_reserve_region() with is_usable_memory(), and only invoke
it if the region in question was identified as memory by is_memory() in the
first place. The net result is the same (only reserved regions that are
backed by memory end up in the memblock memory table with the MEMBLOCK_NOMAP
flag set) but carried out in a more straightforward way.
Finally, we remove the trailing asterisk in the EFI debug output. Keeping it
clutters the code, and it serves no real purpose now that we no longer
temporarily reserve BootServices code and data regions like we did in the
early days of EFI support on arm64 Linux (which it inherited from the x86
implementation)
Signed-off-by: Ard Biesheuvel <redacted>
---
v2: refactor is_normal_ram and is_reserve_region
drop trailing asterisk in EFI debug output
drivers/firmware/efi/arm-init.c | 32 +++++++++++---------
1 file changed, 17 insertions(+), 15 deletions(-)
On Thu, Aug 25, 2016 at 06:17:09PM +0200, Ard Biesheuvel wrote:
Currently, memory regions are only recorded in the memblock memory table
if they have the EFI_MEMORY_WB memory type attribute set. In case the
region is of a reserved type, it is also marked as MEMBLOCK_NOMAP, which
will leave it out of the linear mapping.
However, memory regions may legally have the EFI_MEMORY_WT or EFI_MEMORY_WC
attributes set, and the EFI_MEMORY_WB cleared, in which case the region in
question is obviously backed by normal memory, but is not recorded in the
memblock memory table at all. Since it would be useful to be able to
identify any UEFI reported memory region using memblock_is_memory(), it
makes sense to add all memory to the memblock memory table, and simply mark
it as MEMBLOCK_NOMAP if it lacks the EFI_MEMORY_WB attribute.
While implementing this, let's refactor the code slightly to make it easier
to understand: replace is_normal_ram() with is_memory(), and make it return
true for each region that has any of the WB|WT|WC bits set. (This follows
the AArch64 bindings in the UEFI spec, which state that those are the
attributes that map to normal memory)
Also, replace is_reserve_region() with is_usable_memory(), and only invoke
it if the region in question was identified as memory by is_memory() in the
first place. The net result is the same (only reserved regions that are
backed by memory end up in the memblock memory table with the MEMBLOCK_NOMAP
flag set) but carried out in a more straightforward way.
Finally, we remove the trailing asterisk in the EFI debug output. Keeping it
clutters the code, and it serves no real purpose now that we no longer
temporarily reserve BootServices code and data regions like we did in the
early days of EFI support on arm64 Linux (which it inherited from the x86
implementation)
Signed-off-by: Ard Biesheuvel <redacted>
Reviewed-by: Leif Lindholm <redacted>
quoted hunk
---
v2: refactor is_normal_ram and is_reserve_region
drop trailing asterisk in EFI debug output
drivers/firmware/efi/arm-init.c | 32 +++++++++++---------
1 file changed, 17 insertions(+), 15 deletions(-)
Currently, memory regions are only recorded in the memblock memory table
if they have the EFI_MEMORY_WB memory type attribute set. In case the
region is of a reserved type, it is also marked as MEMBLOCK_NOMAP, which
will leave it out of the linear mapping.
However, memory regions may legally have the EFI_MEMORY_WT or EFI_MEMORY_WC
attributes set, and the EFI_MEMORY_WB cleared, in which case the region in
question is obviously backed by normal memory, but is not recorded in the
memblock memory table at all.
I've been hitting this when applying weird (but permissible) attributes to the
ACPI regions. Currently without WB we map these as device memory, then let
acpica make unaligned accesses to it.
This patch fixes all that, and from the conversation on irc, the 'UC only' case
for ACPI tables is x86-legacy, and should never happen.
On 26 August 2016 at 11:45, James Morse [off-list ref] wrote:
Hi Ard,
On 25/08/16 17:17, Ard Biesheuvel wrote:
quoted
Currently, memory regions are only recorded in the memblock memory table
if they have the EFI_MEMORY_WB memory type attribute set. In case the
region is of a reserved type, it is also marked as MEMBLOCK_NOMAP, which
will leave it out of the linear mapping.
However, memory regions may legally have the EFI_MEMORY_WT or EFI_MEMORY_WC
attributes set, and the EFI_MEMORY_WB cleared, in which case the region in
question is obviously backed by normal memory, but is not recorded in the
memblock memory table at all.
I've been hitting this when applying weird (but permissible) attributes to the
ACPI regions. Currently without WB we map these as device memory, then let
acpica make unaligned accesses to it.
This patch fixes all that, and from the conversation on irc, the 'UC only' case
for ACPI tables is x86-legacy, and should never happen.
Indeed, deliberately exposing a region containing ACPI tables as
something that *requires* strongly ordered access does not make sense.
The problem here is that the UEFI memory map describes both occupied
and available regions, and in the 'available' case, it is obvious that
these bits describe the nature of the physical backing of the region,
i.e., whether the bus fabric, memory, etc allow writeback/writethrough
caching, write buffering etc. This explains why most regions have all
the bits set.
In the occupied case, this can be misinterpreted as describing the
nature of the content, like an ACPI table containing fields that are
not naturally aligned. I.e, I don't think clearing the UC bit here
should be interpreted to mean that the payload *requires* WB/WT/WC. It
is up to the kernel to complain if it interprets a region, and notices
that the only supported mapping type conflicts with the nature of the
accesses we intend to perform.
On 26 August 2016 at 11:08, Ard Biesheuvel [off-list ref] wrote:
On 26 August 2016 at 11:45, James Morse [off-list ref] wrote:
quoted
Hi Ard,
On 25/08/16 17:17, Ard Biesheuvel wrote:
quoted
Currently, memory regions are only recorded in the memblock memory table
if they have the EFI_MEMORY_WB memory type attribute set. In case the
region is of a reserved type, it is also marked as MEMBLOCK_NOMAP, which
will leave it out of the linear mapping.
However, memory regions may legally have the EFI_MEMORY_WT or EFI_MEMORY_WC
attributes set, and the EFI_MEMORY_WB cleared, in which case the region in
question is obviously backed by normal memory, but is not recorded in the
memblock memory table at all.
I've been hitting this when applying weird (but permissible) attributes to the
ACPI regions. Currently without WB we map these as device memory, then let
acpica make unaligned accesses to it.
This patch fixes all that, and from the conversation on irc, the 'UC only' case
for ACPI tables is x86-legacy, and should never happen.
Indeed, deliberately exposing a region containing ACPI tables as
something that *requires* strongly ordered access does not make sense.
The problem here is that the UEFI memory map describes both occupied
and available regions, and in the 'available' case, it is obvious that
these bits describe the nature of the physical backing of the region,
i.e., whether the bus fabric, memory, etc allow writeback/writethrough
caching, write buffering etc. This explains why most regions have all
the bits set.
In the occupied case, this can be misinterpreted as describing the
nature of the content, like an ACPI table containing fields that are
not naturally aligned. I.e, I don't think clearing the UC bit here
should be interpreted to mean that the payload *requires* WB/WT/WC. It
is up to the kernel to complain if it interprets a region, and notices
that the only supported mapping type conflicts with the nature of the
accesses we intend to perform.