From: Al Stone <ahs3@redhat.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Dan Williams <dan.j.williams@intel.com>,
Erik Kaneda <erik.kaneda@intel.com>,
rafael.j.wysocki@intel.com, Len Brown <lenb@kernel.org>,
Borislav Petkov <bp@alien8.de>, Ira Weiny <ira.weiny@intel.com>,
James Morse <james.morse@arm.com>,
Myron Stowe <myron.stowe@redhat.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
linux-nvdimm@lists.01.org, Bob Moore <robert.moore@intel.com>
Subject: Re: [PATCH v4 2/2] ACPICA: Preserve memory opregion mappings
Date: Mon, 29 Jun 2020 14:57:08 -0600 [thread overview]
Message-ID: <20200629205708.GK1237914@redhat.com> (raw)
In-Reply-To: <1794490.F2OrUDcHQn@kreacher>
On 29 Jun 2020 18:33, Rafael J. Wysocki wrote:
> From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
>
> The ACPICA's strategy with respect to the handling of memory mappings
> associated with memory operation regions is to avoid mapping the
> entire region at once which may be problematic at least in principle
> (for example, it may lead to conflicts with overlapping mappings
> having different attributes created by drivers). It may also be
> wasteful, because memory opregions on some systems take up vast
> chunks of address space while the fields in those regions actually
> accessed by AML are sparsely distributed.
>
> For this reason, a one-page "window" is mapped for a given opregion
> on the first memory access through it and if that "window" does not
> cover an address range accessed through that opregion subsequently,
> it is unmapped and a new "window" is mapped to replace it. Next,
> if the new "window" is not sufficient to acess memory through the
> opregion in question in the future, it will be replaced with yet
> another "window" and so on. That may lead to a suboptimal sequence
> of memory mapping and unmapping operations, for example if two fields
> in one opregion separated from each other by a sufficiently wide
> chunk of unused address space are accessed in an alternating pattern.
>
> The situation may still be suboptimal if the deferred unmapping
> introduced previously is supported by the OS layer. For instance,
> the alternating memory access pattern mentioned above may produce
> a relatively long list of mappings to release with substantial
> duplication among the entries in it, which could be avoided if
> acpi_ex_system_memory_space_handler() did not release the mapping
> used by it previously as soon as the current access was not covered
> by it.
>
> In order to improve that, modify acpi_ex_system_memory_space_handler()
> to preserve all of the memory mappings created by it until the memory
> regions associated with them go away.
>
> Accordingly, update acpi_ev_system_memory_region_setup() to unmap all
> memory associated with memory opregions that go away.
>
> Reported-by: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
> drivers/acpi/acpica/evrgnini.c | 14 ++++----
> drivers/acpi/acpica/exregion.c | 65 ++++++++++++++++++++++++----------
> include/acpi/actypes.h | 12 +++++--
> 3 files changed, 64 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/acpi/acpica/evrgnini.c b/drivers/acpi/acpica/evrgnini.c
> index aefc0145e583..89be3ccdad53 100644
> --- a/drivers/acpi/acpica/evrgnini.c
> +++ b/drivers/acpi/acpica/evrgnini.c
> @@ -38,6 +38,7 @@ acpi_ev_system_memory_region_setup(acpi_handle handle,
> union acpi_operand_object *region_desc =
> (union acpi_operand_object *)handle;
> struct acpi_mem_space_context *local_region_context;
> + struct acpi_mem_mapping *mm;
>
> ACPI_FUNCTION_TRACE(ev_system_memory_region_setup);
>
> @@ -46,13 +47,14 @@ acpi_ev_system_memory_region_setup(acpi_handle handle,
> local_region_context =
> (struct acpi_mem_space_context *)*region_context;
>
> - /* Delete a cached mapping if present */
> + /* Delete memory mappings if present */
>
> - if (local_region_context->mapped_length) {
> - acpi_os_unmap_memory(local_region_context->
> - mapped_logical_address,
> - local_region_context->
> - mapped_length);
> + while (local_region_context->first_mm) {
> + mm = local_region_context->first_mm;
> + local_region_context->first_mm = mm->next_mm;
> + acpi_os_unmap_memory(mm->logical_address,
> + mm->length);
> + ACPI_FREE(mm);
> }
> ACPI_FREE(local_region_context);
> *region_context = NULL;
> diff --git a/drivers/acpi/acpica/exregion.c b/drivers/acpi/acpica/exregion.c
> index d15a66de26c0..fd68f2134804 100644
> --- a/drivers/acpi/acpica/exregion.c
> +++ b/drivers/acpi/acpica/exregion.c
> @@ -41,6 +41,7 @@ acpi_ex_system_memory_space_handler(u32 function,
> acpi_status status = AE_OK;
> void *logical_addr_ptr = NULL;
> struct acpi_mem_space_context *mem_info = region_context;
> + struct acpi_mem_mapping *mm = mem_info->cur_mm;
> u32 length;
> acpi_size map_length;
I think this needs to be:
acpi_size map_length = mem_info->length;
since it now gets used in the ACPI_ERROR() call below. I'm getting
a "maybe used unitialized" error on compilation.
> acpi_size page_boundary_map_length;
> @@ -96,20 +97,38 @@ acpi_ex_system_memory_space_handler(u32 function,
> * Is 1) Address below the current mapping? OR
> * 2) Address beyond the current mapping?
> */
> - if ((address < mem_info->mapped_physical_address) ||
> - (((u64) address + length) > ((u64)
> - mem_info->mapped_physical_address +
> - mem_info->mapped_length))) {
> + if (!mm || (address < mm->physical_address) ||
> + ((u64) address + length > (u64) mm->physical_address + mm->length)) {
> /*
> - * The request cannot be resolved by the current memory mapping;
> - * Delete the existing mapping and create a new one.
> + * The request cannot be resolved by the current memory mapping.
> + *
> + * Look for an existing saved mapping covering the address range
> + * at hand. If found, save it as the current one and carry out
> + * the access.
> */
> - if (mem_info->mapped_length) {
> + for (mm = mem_info->first_mm; mm; mm = mm->next_mm) {
> + if (mm == mem_info->cur_mm)
> + continue;
> +
> + if (address < mm->physical_address)
> + continue;
> +
> + if ((u64) address + length >
> + (u64) mm->physical_address + mm->length)
> + continue;
>
> - /* Valid mapping, delete it */
> + mem_info->cur_mm = mm;
> + goto access;
> + }
>
> - acpi_os_unmap_memory(mem_info->mapped_logical_address,
> - mem_info->mapped_length);
> + /* Create a new mappings list entry */
> + mm = ACPI_ALLOCATE_ZEROED(sizeof(*mm));
> + if (!mm) {
> + ACPI_ERROR((AE_INFO,
> + "Unable to save memory mapping at 0x%8.8X%8.8X, size %u",
> + ACPI_FORMAT_UINT64(address),
> + (u32)map_length));
> + return_ACPI_STATUS(AE_NO_MEMORY);
> }
>
> /*
> @@ -143,29 +162,39 @@ acpi_ex_system_memory_space_handler(u32 function,
>
> /* Create a new mapping starting at the address given */
>
> - mem_info->mapped_logical_address =
> - acpi_os_map_memory(address, map_length);
> - if (!mem_info->mapped_logical_address) {
> + logical_addr_ptr = acpi_os_map_memory(address, map_length);
> + if (!logical_addr_ptr) {
> ACPI_ERROR((AE_INFO,
> "Could not map memory at 0x%8.8X%8.8X, size %u",
> ACPI_FORMAT_UINT64(address),
> (u32)map_length));
> - mem_info->mapped_length = 0;
> + ACPI_FREE(mm);
> return_ACPI_STATUS(AE_NO_MEMORY);
> }
>
> /* Save the physical address and mapping size */
>
> - mem_info->mapped_physical_address = address;
> - mem_info->mapped_length = map_length;
> + mm->logical_address = logical_addr_ptr;
> + mm->physical_address = address;
> + mm->length = map_length;
> +
> + /*
> + * Add the new entry to the mappigs list and save it as the
> + * current mapping.
> + */
> + mm->next_mm = mem_info->first_mm;
> + mem_info->first_mm = mm;
> +
> + mem_info->cur_mm = mm;
> }
>
> +access:
> /*
> * Generate a logical pointer corresponding to the address we want to
> * access
> */
> - logical_addr_ptr = mem_info->mapped_logical_address +
> - ((u64) address - (u64) mem_info->mapped_physical_address);
> + logical_addr_ptr = mm->logical_address +
> + ((u64) address - (u64) mm->physical_address);
>
> ACPI_DEBUG_PRINT((ACPI_DB_INFO,
> "System-Memory (width %u) R/W %u Address=%8.8X%8.8X\n",
> diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h
> index aa236b9e6f24..d005e35ab399 100644
> --- a/include/acpi/actypes.h
> +++ b/include/acpi/actypes.h
> @@ -1201,12 +1201,18 @@ struct acpi_pci_id {
> u16 function;
> };
>
> +struct acpi_mem_mapping {
> + acpi_physical_address physical_address;
> + u8 *logical_address;
> + acpi_size length;
> + struct acpi_mem_mapping *next_mm;
> +};
> +
> struct acpi_mem_space_context {
> u32 length;
> acpi_physical_address address;
> - acpi_physical_address mapped_physical_address;
> - u8 *mapped_logical_address;
> - acpi_size mapped_length;
> + struct acpi_mem_mapping *cur_mm;
> + struct acpi_mem_mapping *first_mm;
> };
>
> /*
> --
> 2.26.2
>
>
>
>
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3@redhat.com
-----------------------------------
next prev parent reply other threads:[~2020-06-29 20:57 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-07 23:39 [PATCH v2] ACPI: Drop rcu usage for MMIO mappings Dan Williams
2020-05-13 8:52 ` [ACPI] 5a91d41f89: BUG:sleeping_function_called_from_invalid_context_at_kernel/locking/mutex.c kernel test robot
2020-06-05 13:32 ` [PATCH v2] ACPI: Drop rcu usage for MMIO mappings Rafael J. Wysocki
2020-06-05 16:18 ` Dan Williams
2020-06-05 16:21 ` Rafael J. Wysocki
2020-06-05 16:39 ` Dan Williams
2020-06-05 17:02 ` Rafael J. Wysocki
2020-06-05 14:06 ` [RFT][PATCH] ACPI: OSL: Use rwlock instead of RCU for memory management Rafael J. Wysocki
2020-06-05 17:08 ` Dan Williams
2020-06-06 6:56 ` Rafael J. Wysocki
2020-06-08 15:33 ` Rafael J. Wysocki
2020-06-08 16:29 ` Rafael J. Wysocki
2020-06-05 19:40 ` Andy Shevchenko
2020-06-06 6:48 ` Rafael J. Wysocki
2020-06-10 12:17 ` [RFT][PATCH 0/3] ACPI: ACPICA / OSL: Avoid unmapping ACPI memory inside of the AML interpreter Rafael J. Wysocki
2020-06-10 12:20 ` [RFT][PATCH 1/3] ACPICA: Defer unmapping of memory used in memory opregions Rafael J. Wysocki
2020-06-10 12:21 ` [RFT][PATCH 2/3] ACPICA: Remove unused memory mappings on interpreter exit Rafael J. Wysocki
2020-06-12 0:12 ` Kaneda, Erik
2020-06-12 12:05 ` Rafael J. Wysocki
2020-06-13 19:28 ` Rafael J. Wysocki
2020-06-15 19:06 ` Dan Williams
2020-06-10 12:22 ` [RFT][PATCH 3/3] ACPI: OSL: Define ACPI_OS_MAP_MEMORY_FAST_PATH() Rafael J. Wysocki
2020-06-13 19:19 ` [RFT][PATCH 0/3] ACPI: ACPICA / OSL: Avoid unmapping ACPI memory inside of the AML interpreter Rafael J. Wysocki
2020-06-22 13:50 ` [RFT][PATCH v2 0/4] " Rafael J. Wysocki
2020-06-22 13:52 ` [RFT][PATCH v2 1/4] ACPICA: Defer unmapping of opregion memory if supported by OS Rafael J. Wysocki
2020-06-22 13:53 ` [RFT][PATCH v2 2/4] ACPI: OSL: Add support for deferred unmapping of ACPI memory Rafael J. Wysocki
2020-06-22 14:56 ` Andy Shevchenko
2020-06-22 15:27 ` Rafael J. Wysocki
2020-06-22 15:46 ` Andy Shevchenko
2020-06-22 14:01 ` [RFT][PATCH v2 3/4] ACPICA: Preserve memory opregion mappings if supported by OS Rafael J. Wysocki
2020-06-26 22:53 ` Kaneda, Erik
2020-06-29 13:02 ` Rafael J. Wysocki
2020-06-22 14:02 ` [RFT][PATCH v2 4/4] ACPI: OSL: Implement acpi_os_map_memory_fast_path() Rafael J. Wysocki
2020-06-26 17:28 ` [RFT][PATCH v3 0/4] ACPI: ACPICA / OSL: Avoid unmapping ACPI memory inside of the AML interpreter Rafael J. Wysocki
2020-06-26 17:31 ` [RFT][PATCH v3 1/4] ACPICA: Take deferred unmapping of memory into account Rafael J. Wysocki
2020-06-26 17:31 ` [RFT][PATCH v3 2/4] ACPI: OSL: Implement deferred unmapping of ACPI memory Rafael J. Wysocki
2020-06-26 17:32 ` [RFT][PATCH v3 3/4] ACPICA: Preserve memory opregion mappings if supported by OS Rafael J. Wysocki
2020-06-26 17:33 ` [RFT][PATCH v3 4/4] ACPI: OSL: Implement acpi_os_map_memory_fast_path() Rafael J. Wysocki
2020-06-26 18:41 ` [RFT][PATCH v3 0/4] ACPI: ACPICA / OSL: Avoid unmapping ACPI memory inside of the AML interpreter Dan Williams
2020-06-28 17:09 ` Rafael J. Wysocki
2020-06-29 20:46 ` Dan Williams
2020-06-30 11:04 ` Rafael J. Wysocki
2020-06-29 16:31 ` [PATCH v4 0/2] " Rafael J. Wysocki
2020-06-29 16:33 ` [PATCH v4 1/2] ACPI: OSL: Implement deferred unmapping of ACPI memory Rafael J. Wysocki
2020-06-29 16:33 ` [PATCH v4 2/2] ACPICA: Preserve memory opregion mappings Rafael J. Wysocki
2020-06-29 20:57 ` Al Stone [this message]
2020-06-30 11:44 ` Rafael J. Wysocki
2020-06-30 15:31 ` Al Stone
2020-06-30 15:52 ` Rafael J. Wysocki
2020-06-30 19:57 ` Al Stone
2020-07-16 19:22 ` Verma, Vishal L
2020-07-19 19:14 ` Rafael J. Wysocki
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=20200629205708.GK1237914@redhat.com \
--to=ahs3@redhat.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bp@alien8.de \
--cc=dan.j.williams@intel.com \
--cc=erik.kaneda@intel.com \
--cc=ira.weiny@intel.com \
--cc=james.morse@arm.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=myron.stowe@redhat.com \
--cc=rafael.j.wysocki@intel.com \
--cc=rjw@rjwysocki.net \
--cc=robert.moore@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).