[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH][4.17] EFI: don't convert memory marked for runtime use to ordinary RAM


  • To: Julien Grall <julien@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 5 Oct 2022 13:55:13 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=r7HUhkRC5uQAglFLYV1QaXlcHr1rewmUst5byxrL4J0=; b=TA8ZF7sU1bxy+XRjXUVnx1AgoMmy75ql8/AA+Iuh9I4shM6Wj9nl0Dje9lyicVUjQnGJljvzHlFQ+YZ3qigHK3lXDZmCgh1JPljtYpPa3ulnW3p8ac4KXQ4KsWcCymNfWvY9rnQMIJzY2aSKOjyIdy604nawP+O3apX+nj12ZdSX9byME0Oyasqnzc0wkAO6IdsAFeFSQy8P+vo5tyvwko94H87sd6VxF3MLVARqaGtyoVESkQarMj/L4z0J+ZxlmNGivhIJSb74eO6SjM+iZQYFfmIW90m9P9wjlgQMCOMC5g7qp0NU/GPuc8f04xNTElv3R/P7p8qG5uibAdO62Q==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=k2l4XnuQA0SPnwAcydE0j1vZE8P/1uZOJYE5U2HWbS6/QMhp3u6NsHPi5XUZq7WsTSCXZv8r5QZ31h61woJ9wpKE39CbnGEBPbN1iroGbG9zGxPlOGbVSsL6PTmBoLtTc5ttYKthosDXKWkMpEaonvvDkGo9//33JbkQdxlwUsZpBbgzMqey+Y6uxMuyihwH/u/YNwC8K5kNJzbJfNkgcWipk63YROI+DSP9wsCskbDpetVfbqQg4run2ZSA+3VYRO1wnWrfgI0lN8Guz+JvOd/7mp5mhZL8kAC3EtaAuefiOODX5FqIbNZYHUT3yFviKEatDX3BtBwP9TmV8d1JNw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Volodymyr Babchuk <volodymyr_babchuk@xxxxxxxx>, Henry Wang <Henry.Wang@xxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • Delivery-date: Wed, 05 Oct 2022 11:55:35 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 05.10.2022 12:44, Julien Grall wrote:
> On 04/10/2022 16:58, Jan Beulich wrote:
>> On 30.09.2022 14:51, Bertrand Marquis wrote:
>>>> On 30 Sep 2022, at 09:50, Jan Beulich <jbeulich@xxxxxxxx> 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 <jbeulich@xxxxxxxx>
>>>
>>> Reviewed-by: Bertrand Marquis <bertrand.marquis@xxxxxxx> #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.
> 
> I don't quite understand what you are questioning here. Looking at the 
> code, EfiACPIReclaimMemory will not be converted to RAM but added in a 
> separate array.
> 
> Furthermore, all the EfiACPIReclaimMemory regions will be passed to dom0 
> (see acpi_create_efi_mmap_table()).
> 
> So to me the code looks correct.

Oh, I've indeed not paid enough attention to the first argument passed
to meminfo_add_bank(). I'm sorry for the extra noise. However, the
question I wanted to have addressed before sending out v3 was that
regarding the present using of memory when EFI_MEMORY_WB is not set.
Is that correct for the EfiACPIReclaimMemory case, i.e. is the
consumer (Dom0) aware that there might be a restriction? And would
this memory then be guaranteed to never be freed into the general pool
of RAM pages?

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.