On 30.09.2022 14:51, Bertrand Marquis wrote:
>> On 30 Sep 2022, at 09:50, Jan Beulich <jbeul...@suse.com> wrote:
>>
>> efi_init_memory() in both relevant places is treating EFI_MEMORY_RUNTIME
>> higher priority than the type of the range. To avoid accessing memory at
>> runtime which was re-used for other purposes, make
>> efi_arch_process_memory_map() follow suit. While on x86 in theory the
>> same would apply to EfiACPIReclaimMemory, we don't actually "reclaim"
>> E820_ACPI memory there and hence that type's handling can be left alone.
>>
>> Fixes: bf6501a62e80 ("x86-64: EFI boot code")
>> Fixes: facac0af87ef ("x86-64: EFI runtime code")
>> Fixes: 6d70ea10d49f ("Add ARM EFI boot support")
>> Signed-off-by: Jan Beulich <jbeul...@suse.com>
>
> Reviewed-by: Bertrand Marquis <bertrand.marq...@arm.com> #arm
Thanks. However ...
>> ---
>> Partly RFC for Arm, for two reasons:
>>
>> On Arm I question the conversion of EfiACPIReclaimMemory, in two ways:
>> For one like on x86 such ranges would likely better be retained, as Dom0
>> may (will?) have a need to look at tables placed there. Plus converting
>> such ranges to RAM even if EFI_MEMORY_WB is not set looks suspicious to
>> me as well. I'd be inclined to make the latter adjustment right here
>> (while the other change probably would better be separate, if there
>> aren't actually reasons for the present behavior).
... any views on this WB aspect at least (also Stefano or Julien)? Would be
good to know before I send v2.
Jan
