[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 1/4] xen/acpi: Rework acpi_os_map_memory() and acpi_os_unmap_memory()
 
- To: Stefano Stabellini <sstabellini@xxxxxxxxxx>
 
- From: Julien Grall <julien@xxxxxxx>
 
- Date: Thu, 1 Oct 2020 16:09:04 +0100
 
- Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx, alex.bennee@xxxxxxxxxx, masami.hiramatsu@xxxxxxxxxx, ehem+xen@xxxxxxx, bertrand.marquis@xxxxxxx, andre.przywara@xxxxxxx, Julien Grall <jgrall@xxxxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
 
- Delivery-date: Thu, 01 Oct 2020 15:09:30 +0000
 
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
 
 
 
Hi Stefano,
On 01/10/2020 01:06, Stefano Stabellini wrote:
 
On Sat, 26 Sep 2020, Julien Grall wrote:
 
From: Julien Grall <jgrall@xxxxxxxxxx>
The functions acpi_os_{un,}map_memory() are meant to be arch-agnostic
while the __acpi_os_{un,}map_memory() are meant to be arch-specific.
Currently, the former are still containing x86 specific code.
To avoid this rather strange split, the generic helpers are reworked so
they are arch-agnostic. This requires the introduction of a new helper
__acpi_os_unmap_memory() that will undo any mapping done by
__acpi_os_map_memory().
Currently, the arch-helper for unmap is basically a no-op so it only
returns whether the mapping was arch specific. But this will change
in the future.
Note that the x86 version of acpi_os_map_memory() was already able to
able the 1MB region. Hence why there is no addition of new code.
Signed-off-by: Julien Grall <jgrall@xxxxxxxxxx>
---
  xen/arch/arm/acpi/lib.c | 10 ++++++++++
  xen/arch/x86/acpi/lib.c | 18 ++++++++++++++++++
  xen/drivers/acpi/osl.c  | 34 ++++++++++++++++++----------------
  xen/include/xen/acpi.h  |  1 +
  4 files changed, 47 insertions(+), 16 deletions(-)
diff --git a/xen/arch/arm/acpi/lib.c b/xen/arch/arm/acpi/lib.c
index 4fc6e17322c1..2192a5519171 100644
--- a/xen/arch/arm/acpi/lib.c
+++ b/xen/arch/arm/acpi/lib.c
@@ -30,6 +30,10 @@ char *__acpi_map_table(paddr_t phys, unsigned long size)
      unsigned long base, offset, mapped_size;
      int idx;
  
+    /* No arch specific implementation after early boot */
+    if ( system_state >= SYS_STATE_boot )
+        return NULL;
+
      offset = phys & (PAGE_SIZE - 1);
      mapped_size = PAGE_SIZE - offset;
      set_fixmap(FIXMAP_ACPI_BEGIN, maddr_to_mfn(phys), PAGE_HYPERVISOR);
@@ -49,6 +53,12 @@ char *__acpi_map_table(paddr_t phys, unsigned long size)
      return ((char *) base + offset);
  }
  
+bool __acpi_unmap_table(void *ptr, unsigned long size)
+{
+    return ( vaddr >= FIXMAP_ADDR(FIXMAP_ACPI_BEGIN) &&
+             vaddr < (FIXMAP_ADDR(FIXMAP_ACPI_END) + PAGE_SIZE) );
+}
 
vaddr or ptr?  :-)
lib.c: In function '__acpi_unmap_table':
lib.c:58:14: error: 'vaddr' undeclared (first use in this function)
      return ( vaddr >= FIXMAP_ADDR(FIXMAP_ACPI_BEGIN) &&
               ^
lib.c:58:14: note: each undeclared identifier is reported only once for each 
function it appears in
lib.c:60:1: error: control reaches end of non-void function 
[-Werror=return-type]
  }
  ^
cc1: all warnings being treated as errors
 
 The whole series builds because 'vaddr' is added in the next patch. But 
I forgot to build patch by patch :(.
I will fix it in the next version.
Cheers,
--
Julien Grall
 
 
    
     |