All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Jia He <justin.he@arm.com>
Cc: Will Deacon <will@kernel.org>, Len Brown <lenb@kernel.org>,
	Robert Moore <robert.moore@intel.com>,
	Erik Kaneda <erik.kaneda@intel.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	devel@acpica.org, Ard Biesheuvel <ardb@kernel.org>,
	Hanjun Guo <guohanjun@huawei.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
	harb@amperecomputing.com
Subject: Re: [PATCH] Revert "ACPI: Add memory semantics to acpi_os_map_memory()"
Date: Fri, 10 Sep 2021 14:54:46 +0100	[thread overview]
Message-ID: <20210910135446.GA15810@lpieralisi> (raw)
In-Reply-To: <20210910122820.26886-1-justin.he@arm.com>

[dropped CC stable, +CC Harb]

On Fri, Sep 10, 2021 at 08:28:20PM +0800, Jia He wrote:
> This reverts commit 437b38c51162f8b87beb28a833c4d5dc85fa864e.
> 
> After this commit, a boot panic is alway hit on an Ampere EMAG server
> with call trace as follows:
>  Internal error: synchronous external abort: 96000410 [#1] SMP
>  Modules linked in:
>  CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.0+ #462
>  Hardware name: MiTAC RAPTOR EV-883832-X3-0001/RAPTOR, BIOS 0.14 02/22/2019
>  pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [...snip...]
>  Call trace:
>   acpi_ex_system_memory_space_handler+0x26c/0x2c8
>   acpi_ev_address_space_dispatch+0x228/0x2c4
>   acpi_ex_access_region+0x114/0x268
>   acpi_ex_field_datum_io+0x128/0x1b8
>   acpi_ex_extract_from_field+0x14c/0x2ac
>   acpi_ex_read_data_from_field+0x190/0x1b8
>   acpi_ex_resolve_node_to_value+0x1ec/0x288
>   acpi_ex_resolve_to_value+0x250/0x274
>   acpi_ds_evaluate_name_path+0xac/0x124
>   acpi_ds_exec_end_op+0x90/0x410
>   acpi_ps_parse_loop+0x4ac/0x5d8
>   acpi_ps_parse_aml+0xe0/0x2c8
>   acpi_ps_execute_method+0x19c/0x1ac
>   acpi_ns_evaluate+0x1f8/0x26c
>   acpi_ns_init_one_device+0x104/0x140
>   acpi_ns_walk_namespace+0x158/0x1d0
>   acpi_ns_initialize_devices+0x194/0x218
>   acpi_initialize_objects+0x48/0x50
>   acpi_init+0xe0/0x498
> 
> From the debugging, we're mapping something which is *not* described by
> the EFI memory map, but *does* want PROT_NORMAL_NC.

"Does not" you mean. We are forcing memory semantics mappings to
PROT_NORMAL_NC, which eMAG does not like at all and I'd need to
understand why.

It looks like the issue happen in SystemMemory Opregion handler.

> 
> Hence just revert it before everything is clear.
> 
> Fixes: 437b38c51162 ("ACPI: Add memory semantics to acpi_os_map_memory()")
> Cc: stable@vger.kernel.org

No need, it is not even in an -rc yet (and stable should not be CCed in
the addressees CC list).

Thanks,
Lorenzo

> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Ard Biesheuvel <ardb@kernel.org>
> Cc: Hanjun Guo <guohanjun@huawei.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> 
> Signed-off-by: Jia He <justin.he@arm.com>
> ---
>  arch/arm64/include/asm/acpi.h |  3 ---
>  arch/arm64/kernel/acpi.c      | 19 +++----------------
>  drivers/acpi/osl.c            | 23 +++++++----------------
>  include/acpi/acpi_io.h        |  8 --------
>  4 files changed, 10 insertions(+), 43 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index 7535dc7cc5aa..bd68e1b7f29f 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -50,9 +50,6 @@ pgprot_t __acpi_get_mem_attribute(phys_addr_t addr);
>  void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size);
>  #define acpi_os_ioremap acpi_os_ioremap
>  
> -void __iomem *acpi_os_memmap(acpi_physical_address phys, acpi_size size);
> -#define acpi_os_memmap acpi_os_memmap
> -
>  typedef u64 phys_cpuid_t;
>  #define PHYS_CPUID_INVALID INVALID_HWID
>  
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index 1c9c2f7a1c04..f3851724fe35 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -273,8 +273,7 @@ pgprot_t __acpi_get_mem_attribute(phys_addr_t addr)
>  	return __pgprot(PROT_DEVICE_nGnRnE);
>  }
>  
> -static void __iomem *__acpi_os_ioremap(acpi_physical_address phys,
> -				       acpi_size size, bool memory)
> +void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size)
>  {
>  	efi_memory_desc_t *md, *region = NULL;
>  	pgprot_t prot;
> @@ -300,11 +299,9 @@ static void __iomem *__acpi_os_ioremap(acpi_physical_address phys,
>  	 * It is fine for AML to remap regions that are not represented in the
>  	 * EFI memory map at all, as it only describes normal memory, and MMIO
>  	 * regions that require a virtual mapping to make them accessible to
> -	 * the EFI runtime services. Determine the region default
> -	 * attributes by checking the requested memory semantics.
> +	 * the EFI runtime services.
>  	 */
> -	prot = memory ? __pgprot(PROT_NORMAL_NC) :
> -			__pgprot(PROT_DEVICE_nGnRnE);
> +	prot = __pgprot(PROT_DEVICE_nGnRnE);
>  	if (region) {
>  		switch (region->type) {
>  		case EFI_LOADER_CODE:
> @@ -364,16 +361,6 @@ static void __iomem *__acpi_os_ioremap(acpi_physical_address phys,
>  	return __ioremap(phys, size, prot);
>  }
>  
> -void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size)
> -{
> -	return __acpi_os_ioremap(phys, size, false);
> -}
> -
> -void __iomem *acpi_os_memmap(acpi_physical_address phys, acpi_size size)
> -{
> -	return __acpi_os_ioremap(phys, size, true);
> -}
> -
>  /*
>   * Claim Synchronous External Aborts as a firmware first notification.
>   *
> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
> index a43f1521efe6..45c5c0e45e33 100644
> --- a/drivers/acpi/osl.c
> +++ b/drivers/acpi/osl.c
> @@ -284,8 +284,7 @@ acpi_map_lookup_virt(void __iomem *virt, acpi_size size)
>  #define should_use_kmap(pfn)   page_is_ram(pfn)
>  #endif
>  
> -static void __iomem *acpi_map(acpi_physical_address pg_off, unsigned long pg_sz,
> -			      bool memory)
> +static void __iomem *acpi_map(acpi_physical_address pg_off, unsigned long pg_sz)
>  {
>  	unsigned long pfn;
>  
> @@ -295,8 +294,7 @@ static void __iomem *acpi_map(acpi_physical_address pg_off, unsigned long pg_sz,
>  			return NULL;
>  		return (void __iomem __force *)kmap(pfn_to_page(pfn));
>  	} else
> -		return memory ? acpi_os_memmap(pg_off, pg_sz) :
> -				acpi_os_ioremap(pg_off, pg_sz);
> +		return acpi_os_ioremap(pg_off, pg_sz);
>  }
>  
>  static void acpi_unmap(acpi_physical_address pg_off, void __iomem *vaddr)
> @@ -311,10 +309,9 @@ static void acpi_unmap(acpi_physical_address pg_off, void __iomem *vaddr)
>  }
>  
>  /**
> - * __acpi_os_map_iomem - Get a virtual address for a given physical address range.
> + * acpi_os_map_iomem - Get a virtual address for a given physical address range.
>   * @phys: Start of the physical address range to map.
>   * @size: Size of the physical address range to map.
> - * @memory: true if remapping memory, false if IO
>   *
>   * Look up the given physical address range in the list of existing ACPI memory
>   * mappings.  If found, get a reference to it and return a pointer to it (its
> @@ -324,8 +321,8 @@ static void acpi_unmap(acpi_physical_address pg_off, void __iomem *vaddr)
>   * During early init (when acpi_permanent_mmap has not been set yet) this
>   * routine simply calls __acpi_map_table() to get the job done.
>   */
> -static void __iomem __ref
> -*__acpi_os_map_iomem(acpi_physical_address phys, acpi_size size, bool memory)
> +void __iomem __ref
> +*acpi_os_map_iomem(acpi_physical_address phys, acpi_size size)
>  {
>  	struct acpi_ioremap *map;
>  	void __iomem *virt;
> @@ -356,7 +353,7 @@ static void __iomem __ref
>  
>  	pg_off = round_down(phys, PAGE_SIZE);
>  	pg_sz = round_up(phys + size, PAGE_SIZE) - pg_off;
> -	virt = acpi_map(phys, size, memory);
> +	virt = acpi_map(phys, size);
>  	if (!virt) {
>  		mutex_unlock(&acpi_ioremap_lock);
>  		kfree(map);
> @@ -375,17 +372,11 @@ static void __iomem __ref
>  	mutex_unlock(&acpi_ioremap_lock);
>  	return map->virt + (phys - map->phys);
>  }
> -
> -void __iomem *__ref
> -acpi_os_map_iomem(acpi_physical_address phys, acpi_size size)
> -{
> -	return __acpi_os_map_iomem(phys, size, false);
> -}
>  EXPORT_SYMBOL_GPL(acpi_os_map_iomem);
>  
>  void *__ref acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
>  {
> -	return (void *)__acpi_os_map_iomem(phys, size, true);
> +	return (void *)acpi_os_map_iomem(phys, size);
>  }
>  EXPORT_SYMBOL_GPL(acpi_os_map_memory);
>  
> diff --git a/include/acpi/acpi_io.h b/include/acpi/acpi_io.h
> index a0212e67d6f4..027faa8883aa 100644
> --- a/include/acpi/acpi_io.h
> +++ b/include/acpi/acpi_io.h
> @@ -14,14 +14,6 @@ static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
>  }
>  #endif
>  
> -#ifndef acpi_os_memmap
> -static inline void __iomem *acpi_os_memmap(acpi_physical_address phys,
> -					    acpi_size size)
> -{
> -	return ioremap_cache(phys, size);
> -}
> -#endif
> -
>  extern bool acpi_permanent_mmap;
>  
>  void __iomem __ref
> -- 
> 2.17.1
> 

WARNING: multiple messages have this Message-ID (diff)
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Jia He <justin.he@arm.com>
Cc: Will Deacon <will@kernel.org>, Len Brown <lenb@kernel.org>,
	Robert Moore <robert.moore@intel.com>,
	Erik Kaneda <erik.kaneda@intel.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	devel@acpica.org, Ard Biesheuvel <ardb@kernel.org>,
	Hanjun Guo <guohanjun@huawei.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
	harb@amperecomputing.com
Subject: Re: [PATCH] Revert "ACPI: Add memory semantics to acpi_os_map_memory()"
Date: Fri, 10 Sep 2021 14:54:46 +0100	[thread overview]
Message-ID: <20210910135446.GA15810@lpieralisi> (raw)
In-Reply-To: <20210910122820.26886-1-justin.he@arm.com>

[dropped CC stable, +CC Harb]

On Fri, Sep 10, 2021 at 08:28:20PM +0800, Jia He wrote:
> This reverts commit 437b38c51162f8b87beb28a833c4d5dc85fa864e.
> 
> After this commit, a boot panic is alway hit on an Ampere EMAG server
> with call trace as follows:
>  Internal error: synchronous external abort: 96000410 [#1] SMP
>  Modules linked in:
>  CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.0+ #462
>  Hardware name: MiTAC RAPTOR EV-883832-X3-0001/RAPTOR, BIOS 0.14 02/22/2019
>  pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [...snip...]
>  Call trace:
>   acpi_ex_system_memory_space_handler+0x26c/0x2c8
>   acpi_ev_address_space_dispatch+0x228/0x2c4
>   acpi_ex_access_region+0x114/0x268
>   acpi_ex_field_datum_io+0x128/0x1b8
>   acpi_ex_extract_from_field+0x14c/0x2ac
>   acpi_ex_read_data_from_field+0x190/0x1b8
>   acpi_ex_resolve_node_to_value+0x1ec/0x288
>   acpi_ex_resolve_to_value+0x250/0x274
>   acpi_ds_evaluate_name_path+0xac/0x124
>   acpi_ds_exec_end_op+0x90/0x410
>   acpi_ps_parse_loop+0x4ac/0x5d8
>   acpi_ps_parse_aml+0xe0/0x2c8
>   acpi_ps_execute_method+0x19c/0x1ac
>   acpi_ns_evaluate+0x1f8/0x26c
>   acpi_ns_init_one_device+0x104/0x140
>   acpi_ns_walk_namespace+0x158/0x1d0
>   acpi_ns_initialize_devices+0x194/0x218
>   acpi_initialize_objects+0x48/0x50
>   acpi_init+0xe0/0x498
> 
> From the debugging, we're mapping something which is *not* described by
> the EFI memory map, but *does* want PROT_NORMAL_NC.

"Does not" you mean. We are forcing memory semantics mappings to
PROT_NORMAL_NC, which eMAG does not like at all and I'd need to
understand why.

It looks like the issue happen in SystemMemory Opregion handler.

> 
> Hence just revert it before everything is clear.
> 
> Fixes: 437b38c51162 ("ACPI: Add memory semantics to acpi_os_map_memory()")
> Cc: stable@vger.kernel.org

No need, it is not even in an -rc yet (and stable should not be CCed in
the addressees CC list).

Thanks,
Lorenzo

> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Ard Biesheuvel <ardb@kernel.org>
> Cc: Hanjun Guo <guohanjun@huawei.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> 
> Signed-off-by: Jia He <justin.he@arm.com>
> ---
>  arch/arm64/include/asm/acpi.h |  3 ---
>  arch/arm64/kernel/acpi.c      | 19 +++----------------
>  drivers/acpi/osl.c            | 23 +++++++----------------
>  include/acpi/acpi_io.h        |  8 --------
>  4 files changed, 10 insertions(+), 43 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index 7535dc7cc5aa..bd68e1b7f29f 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -50,9 +50,6 @@ pgprot_t __acpi_get_mem_attribute(phys_addr_t addr);
>  void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size);
>  #define acpi_os_ioremap acpi_os_ioremap
>  
> -void __iomem *acpi_os_memmap(acpi_physical_address phys, acpi_size size);
> -#define acpi_os_memmap acpi_os_memmap
> -
>  typedef u64 phys_cpuid_t;
>  #define PHYS_CPUID_INVALID INVALID_HWID
>  
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index 1c9c2f7a1c04..f3851724fe35 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -273,8 +273,7 @@ pgprot_t __acpi_get_mem_attribute(phys_addr_t addr)
>  	return __pgprot(PROT_DEVICE_nGnRnE);
>  }
>  
> -static void __iomem *__acpi_os_ioremap(acpi_physical_address phys,
> -				       acpi_size size, bool memory)
> +void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size)
>  {
>  	efi_memory_desc_t *md, *region = NULL;
>  	pgprot_t prot;
> @@ -300,11 +299,9 @@ static void __iomem *__acpi_os_ioremap(acpi_physical_address phys,
>  	 * It is fine for AML to remap regions that are not represented in the
>  	 * EFI memory map at all, as it only describes normal memory, and MMIO
>  	 * regions that require a virtual mapping to make them accessible to
> -	 * the EFI runtime services. Determine the region default
> -	 * attributes by checking the requested memory semantics.
> +	 * the EFI runtime services.
>  	 */
> -	prot = memory ? __pgprot(PROT_NORMAL_NC) :
> -			__pgprot(PROT_DEVICE_nGnRnE);
> +	prot = __pgprot(PROT_DEVICE_nGnRnE);
>  	if (region) {
>  		switch (region->type) {
>  		case EFI_LOADER_CODE:
> @@ -364,16 +361,6 @@ static void __iomem *__acpi_os_ioremap(acpi_physical_address phys,
>  	return __ioremap(phys, size, prot);
>  }
>  
> -void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size)
> -{
> -	return __acpi_os_ioremap(phys, size, false);
> -}
> -
> -void __iomem *acpi_os_memmap(acpi_physical_address phys, acpi_size size)
> -{
> -	return __acpi_os_ioremap(phys, size, true);
> -}
> -
>  /*
>   * Claim Synchronous External Aborts as a firmware first notification.
>   *
> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
> index a43f1521efe6..45c5c0e45e33 100644
> --- a/drivers/acpi/osl.c
> +++ b/drivers/acpi/osl.c
> @@ -284,8 +284,7 @@ acpi_map_lookup_virt(void __iomem *virt, acpi_size size)
>  #define should_use_kmap(pfn)   page_is_ram(pfn)
>  #endif
>  
> -static void __iomem *acpi_map(acpi_physical_address pg_off, unsigned long pg_sz,
> -			      bool memory)
> +static void __iomem *acpi_map(acpi_physical_address pg_off, unsigned long pg_sz)
>  {
>  	unsigned long pfn;
>  
> @@ -295,8 +294,7 @@ static void __iomem *acpi_map(acpi_physical_address pg_off, unsigned long pg_sz,
>  			return NULL;
>  		return (void __iomem __force *)kmap(pfn_to_page(pfn));
>  	} else
> -		return memory ? acpi_os_memmap(pg_off, pg_sz) :
> -				acpi_os_ioremap(pg_off, pg_sz);
> +		return acpi_os_ioremap(pg_off, pg_sz);
>  }
>  
>  static void acpi_unmap(acpi_physical_address pg_off, void __iomem *vaddr)
> @@ -311,10 +309,9 @@ static void acpi_unmap(acpi_physical_address pg_off, void __iomem *vaddr)
>  }
>  
>  /**
> - * __acpi_os_map_iomem - Get a virtual address for a given physical address range.
> + * acpi_os_map_iomem - Get a virtual address for a given physical address range.
>   * @phys: Start of the physical address range to map.
>   * @size: Size of the physical address range to map.
> - * @memory: true if remapping memory, false if IO
>   *
>   * Look up the given physical address range in the list of existing ACPI memory
>   * mappings.  If found, get a reference to it and return a pointer to it (its
> @@ -324,8 +321,8 @@ static void acpi_unmap(acpi_physical_address pg_off, void __iomem *vaddr)
>   * During early init (when acpi_permanent_mmap has not been set yet) this
>   * routine simply calls __acpi_map_table() to get the job done.
>   */
> -static void __iomem __ref
> -*__acpi_os_map_iomem(acpi_physical_address phys, acpi_size size, bool memory)
> +void __iomem __ref
> +*acpi_os_map_iomem(acpi_physical_address phys, acpi_size size)
>  {
>  	struct acpi_ioremap *map;
>  	void __iomem *virt;
> @@ -356,7 +353,7 @@ static void __iomem __ref
>  
>  	pg_off = round_down(phys, PAGE_SIZE);
>  	pg_sz = round_up(phys + size, PAGE_SIZE) - pg_off;
> -	virt = acpi_map(phys, size, memory);
> +	virt = acpi_map(phys, size);
>  	if (!virt) {
>  		mutex_unlock(&acpi_ioremap_lock);
>  		kfree(map);
> @@ -375,17 +372,11 @@ static void __iomem __ref
>  	mutex_unlock(&acpi_ioremap_lock);
>  	return map->virt + (phys - map->phys);
>  }
> -
> -void __iomem *__ref
> -acpi_os_map_iomem(acpi_physical_address phys, acpi_size size)
> -{
> -	return __acpi_os_map_iomem(phys, size, false);
> -}
>  EXPORT_SYMBOL_GPL(acpi_os_map_iomem);
>  
>  void *__ref acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
>  {
> -	return (void *)__acpi_os_map_iomem(phys, size, true);
> +	return (void *)acpi_os_map_iomem(phys, size);
>  }
>  EXPORT_SYMBOL_GPL(acpi_os_map_memory);
>  
> diff --git a/include/acpi/acpi_io.h b/include/acpi/acpi_io.h
> index a0212e67d6f4..027faa8883aa 100644
> --- a/include/acpi/acpi_io.h
> +++ b/include/acpi/acpi_io.h
> @@ -14,14 +14,6 @@ static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
>  }
>  #endif
>  
> -#ifndef acpi_os_memmap
> -static inline void __iomem *acpi_os_memmap(acpi_physical_address phys,
> -					    acpi_size size)
> -{
> -	return ioremap_cache(phys, size);
> -}
> -#endif
> -
>  extern bool acpi_permanent_mmap;
>  
>  void __iomem __ref
> -- 
> 2.17.1
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
To: devel@acpica.org
Subject: [Devel] Re: [PATCH] Revert "ACPI: Add memory semantics to acpi_os_map_memory()"
Date: Fri, 10 Sep 2021 14:54:46 +0100	[thread overview]
Message-ID: <20210910135446.GA15810@lpieralisi> (raw)
In-Reply-To: 20210910122820.26886-1-justin.he@arm.com

[-- Attachment #1: Type: text/plain, Size: 8545 bytes --]

[dropped CC stable, +CC Harb]

On Fri, Sep 10, 2021 at 08:28:20PM +0800, Jia He wrote:
> This reverts commit 437b38c51162f8b87beb28a833c4d5dc85fa864e.
> 
> After this commit, a boot panic is alway hit on an Ampere EMAG server
> with call trace as follows:
>  Internal error: synchronous external abort: 96000410 [#1] SMP
>  Modules linked in:
>  CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.0+ #462
>  Hardware name: MiTAC RAPTOR EV-883832-X3-0001/RAPTOR, BIOS 0.14 02/22/2019
>  pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [...snip...]
>  Call trace:
>   acpi_ex_system_memory_space_handler+0x26c/0x2c8
>   acpi_ev_address_space_dispatch+0x228/0x2c4
>   acpi_ex_access_region+0x114/0x268
>   acpi_ex_field_datum_io+0x128/0x1b8
>   acpi_ex_extract_from_field+0x14c/0x2ac
>   acpi_ex_read_data_from_field+0x190/0x1b8
>   acpi_ex_resolve_node_to_value+0x1ec/0x288
>   acpi_ex_resolve_to_value+0x250/0x274
>   acpi_ds_evaluate_name_path+0xac/0x124
>   acpi_ds_exec_end_op+0x90/0x410
>   acpi_ps_parse_loop+0x4ac/0x5d8
>   acpi_ps_parse_aml+0xe0/0x2c8
>   acpi_ps_execute_method+0x19c/0x1ac
>   acpi_ns_evaluate+0x1f8/0x26c
>   acpi_ns_init_one_device+0x104/0x140
>   acpi_ns_walk_namespace+0x158/0x1d0
>   acpi_ns_initialize_devices+0x194/0x218
>   acpi_initialize_objects+0x48/0x50
>   acpi_init+0xe0/0x498
> 
> From the debugging, we're mapping something which is *not* described by
> the EFI memory map, but *does* want PROT_NORMAL_NC.

"Does not" you mean. We are forcing memory semantics mappings to
PROT_NORMAL_NC, which eMAG does not like at all and I'd need to
understand why.

It looks like the issue happen in SystemMemory Opregion handler.

> 
> Hence just revert it before everything is clear.
> 
> Fixes: 437b38c51162 ("ACPI: Add memory semantics to acpi_os_map_memory()")
> Cc: stable(a)vger.kernel.org

No need, it is not even in an -rc yet (and stable should not be CCed in
the addressees CC list).

Thanks,
Lorenzo

> Cc: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com>
> Cc: Ard Biesheuvel <ardb(a)kernel.org>
> Cc: Hanjun Guo <guohanjun(a)huawei.com>
> Cc: Catalin Marinas <catalin.marinas(a)arm.com>
> Cc: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
> 
> Signed-off-by: Jia He <justin.he(a)arm.com>
> ---
>  arch/arm64/include/asm/acpi.h |  3 ---
>  arch/arm64/kernel/acpi.c      | 19 +++----------------
>  drivers/acpi/osl.c            | 23 +++++++----------------
>  include/acpi/acpi_io.h        |  8 --------
>  4 files changed, 10 insertions(+), 43 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index 7535dc7cc5aa..bd68e1b7f29f 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -50,9 +50,6 @@ pgprot_t __acpi_get_mem_attribute(phys_addr_t addr);
>  void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size);
>  #define acpi_os_ioremap acpi_os_ioremap
>  
> -void __iomem *acpi_os_memmap(acpi_physical_address phys, acpi_size size);
> -#define acpi_os_memmap acpi_os_memmap
> -
>  typedef u64 phys_cpuid_t;
>  #define PHYS_CPUID_INVALID INVALID_HWID
>  
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index 1c9c2f7a1c04..f3851724fe35 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -273,8 +273,7 @@ pgprot_t __acpi_get_mem_attribute(phys_addr_t addr)
>  	return __pgprot(PROT_DEVICE_nGnRnE);
>  }
>  
> -static void __iomem *__acpi_os_ioremap(acpi_physical_address phys,
> -				       acpi_size size, bool memory)
> +void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size)
>  {
>  	efi_memory_desc_t *md, *region = NULL;
>  	pgprot_t prot;
> @@ -300,11 +299,9 @@ static void __iomem *__acpi_os_ioremap(acpi_physical_address phys,
>  	 * It is fine for AML to remap regions that are not represented in the
>  	 * EFI memory map at all, as it only describes normal memory, and MMIO
>  	 * regions that require a virtual mapping to make them accessible to
> -	 * the EFI runtime services. Determine the region default
> -	 * attributes by checking the requested memory semantics.
> +	 * the EFI runtime services.
>  	 */
> -	prot = memory ? __pgprot(PROT_NORMAL_NC) :
> -			__pgprot(PROT_DEVICE_nGnRnE);
> +	prot = __pgprot(PROT_DEVICE_nGnRnE);
>  	if (region) {
>  		switch (region->type) {
>  		case EFI_LOADER_CODE:
> @@ -364,16 +361,6 @@ static void __iomem *__acpi_os_ioremap(acpi_physical_address phys,
>  	return __ioremap(phys, size, prot);
>  }
>  
> -void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size)
> -{
> -	return __acpi_os_ioremap(phys, size, false);
> -}
> -
> -void __iomem *acpi_os_memmap(acpi_physical_address phys, acpi_size size)
> -{
> -	return __acpi_os_ioremap(phys, size, true);
> -}
> -
>  /*
>   * Claim Synchronous External Aborts as a firmware first notification.
>   *
> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
> index a43f1521efe6..45c5c0e45e33 100644
> --- a/drivers/acpi/osl.c
> +++ b/drivers/acpi/osl.c
> @@ -284,8 +284,7 @@ acpi_map_lookup_virt(void __iomem *virt, acpi_size size)
>  #define should_use_kmap(pfn)   page_is_ram(pfn)
>  #endif
>  
> -static void __iomem *acpi_map(acpi_physical_address pg_off, unsigned long pg_sz,
> -			      bool memory)
> +static void __iomem *acpi_map(acpi_physical_address pg_off, unsigned long pg_sz)
>  {
>  	unsigned long pfn;
>  
> @@ -295,8 +294,7 @@ static void __iomem *acpi_map(acpi_physical_address pg_off, unsigned long pg_sz,
>  			return NULL;
>  		return (void __iomem __force *)kmap(pfn_to_page(pfn));
>  	} else
> -		return memory ? acpi_os_memmap(pg_off, pg_sz) :
> -				acpi_os_ioremap(pg_off, pg_sz);
> +		return acpi_os_ioremap(pg_off, pg_sz);
>  }
>  
>  static void acpi_unmap(acpi_physical_address pg_off, void __iomem *vaddr)
> @@ -311,10 +309,9 @@ static void acpi_unmap(acpi_physical_address pg_off, void __iomem *vaddr)
>  }
>  
>  /**
> - * __acpi_os_map_iomem - Get a virtual address for a given physical address range.
> + * acpi_os_map_iomem - Get a virtual address for a given physical address range.
>   * @phys: Start of the physical address range to map.
>   * @size: Size of the physical address range to map.
> - * @memory: true if remapping memory, false if IO
>   *
>   * Look up the given physical address range in the list of existing ACPI memory
>   * mappings.  If found, get a reference to it and return a pointer to it (its
> @@ -324,8 +321,8 @@ static void acpi_unmap(acpi_physical_address pg_off, void __iomem *vaddr)
>   * During early init (when acpi_permanent_mmap has not been set yet) this
>   * routine simply calls __acpi_map_table() to get the job done.
>   */
> -static void __iomem __ref
> -*__acpi_os_map_iomem(acpi_physical_address phys, acpi_size size, bool memory)
> +void __iomem __ref
> +*acpi_os_map_iomem(acpi_physical_address phys, acpi_size size)
>  {
>  	struct acpi_ioremap *map;
>  	void __iomem *virt;
> @@ -356,7 +353,7 @@ static void __iomem __ref
>  
>  	pg_off = round_down(phys, PAGE_SIZE);
>  	pg_sz = round_up(phys + size, PAGE_SIZE) - pg_off;
> -	virt = acpi_map(phys, size, memory);
> +	virt = acpi_map(phys, size);
>  	if (!virt) {
>  		mutex_unlock(&acpi_ioremap_lock);
>  		kfree(map);
> @@ -375,17 +372,11 @@ static void __iomem __ref
>  	mutex_unlock(&acpi_ioremap_lock);
>  	return map->virt + (phys - map->phys);
>  }
> -
> -void __iomem *__ref
> -acpi_os_map_iomem(acpi_physical_address phys, acpi_size size)
> -{
> -	return __acpi_os_map_iomem(phys, size, false);
> -}
>  EXPORT_SYMBOL_GPL(acpi_os_map_iomem);
>  
>  void *__ref acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
>  {
> -	return (void *)__acpi_os_map_iomem(phys, size, true);
> +	return (void *)acpi_os_map_iomem(phys, size);
>  }
>  EXPORT_SYMBOL_GPL(acpi_os_map_memory);
>  
> diff --git a/include/acpi/acpi_io.h b/include/acpi/acpi_io.h
> index a0212e67d6f4..027faa8883aa 100644
> --- a/include/acpi/acpi_io.h
> +++ b/include/acpi/acpi_io.h
> @@ -14,14 +14,6 @@ static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
>  }
>  #endif
>  
> -#ifndef acpi_os_memmap
> -static inline void __iomem *acpi_os_memmap(acpi_physical_address phys,
> -					    acpi_size size)
> -{
> -	return ioremap_cache(phys, size);
> -}
> -#endif
> -
>  extern bool acpi_permanent_mmap;
>  
>  void __iomem __ref
> -- 
> 2.17.1
> 

  reply	other threads:[~2021-09-10 13:54 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-10 12:28 [PATCH] Revert "ACPI: Add memory semantics to acpi_os_map_memory()" Jia He
2021-09-10 12:28 ` Jia He
2021-09-10 13:54 ` Lorenzo Pieralisi [this message]
2021-09-10 13:54   ` [Devel] " Lorenzo Pieralisi
2021-09-10 13:54   ` Lorenzo Pieralisi
2021-09-10 14:32 ` [PATCH v2] " Jia He
2021-09-10 14:32   ` Jia He
2021-09-10 17:28   ` Ard Biesheuvel
2021-09-10 17:28     ` Ard Biesheuvel
2021-09-11 10:14     ` Lorenzo Pieralisi
2021-09-11 10:14       ` [Devel] " Lorenzo Pieralisi
2021-09-11 10:14       ` Lorenzo Pieralisi
2021-09-16 16:08     ` Lorenzo Pieralisi
2021-09-16 16:08       ` [Devel] " Lorenzo Pieralisi
2021-09-16 16:08       ` Lorenzo Pieralisi
2021-09-20 17:00       ` Lorenzo Pieralisi
2021-09-20 17:00         ` [Devel] " Lorenzo Pieralisi
2021-09-20 17:00         ` Lorenzo Pieralisi
2021-09-20 17:32         ` Rafael J. Wysocki
2021-09-20 17:32           ` [Devel] " Rafael J. Wysocki
2021-09-20 17:32           ` Rafael J. Wysocki
2021-09-21 10:05           ` Lorenzo Pieralisi
2021-09-21 10:05             ` [Devel] " Lorenzo Pieralisi
2021-09-21 10:05             ` Lorenzo Pieralisi
2021-09-22 11:11             ` Ard Biesheuvel
2021-09-22 11:11               ` Ard Biesheuvel
2021-09-22 13:07               ` Lorenzo Pieralisi
2021-09-22 13:07                 ` [Devel] " Lorenzo Pieralisi
2021-09-22 13:07                 ` Lorenzo Pieralisi
2021-09-22 23:45               ` Jeremy Linton
2021-09-22 23:45                 ` [Devel] " Jeremy Linton
2021-09-22 23:45                 ` Jeremy Linton
2021-09-22 16:33   ` Lorenzo Pieralisi
2021-09-22 16:33     ` [Devel] " Lorenzo Pieralisi
2021-09-22 16:33     ` Lorenzo Pieralisi
2021-09-22 23:09     ` Mark Kettenis
2021-09-22 23:09       ` Mark Kettenis
2021-09-23  9:40       ` Lorenzo Pieralisi
2021-09-23  9:40         ` [Devel] " Lorenzo Pieralisi
2021-09-23  9:40         ` Lorenzo Pieralisi
2021-09-23 11:05         ` Rafael J. Wysocki
2021-09-23 11:05           ` [Devel] " Rafael J. Wysocki
2021-09-23 11:05           ` Rafael J. Wysocki
2021-09-23 12:26           ` Mark Kettenis
2021-09-23 12:26             ` Mark Kettenis
2021-09-23 12:54             ` Rafael J. Wysocki
2021-09-23 12:54               ` [Devel] " Rafael J. Wysocki
2021-09-23 12:54               ` Rafael J. Wysocki
2021-09-24  9:04               ` Lorenzo Pieralisi
2021-09-24  9:04                 ` [Devel] " Lorenzo Pieralisi
2021-09-24  9:04                 ` Lorenzo Pieralisi
2021-09-28 17:26                 ` Rafael J. Wysocki
2021-09-28 17:26                   ` Rafael J. Wysocki
2021-09-29 13:31                   ` Lorenzo Pieralisi
2021-09-29 13:31                     ` [Devel] " Lorenzo Pieralisi
2021-09-29 13:31                     ` Lorenzo Pieralisi
2021-09-29 16:30                     ` Luck, Tony
2021-09-29 16:30                       ` Luck, Tony
2021-11-02 15:11                   ` Lorenzo Pieralisi
2021-11-02 15:11                     ` [Devel] " Lorenzo Pieralisi
2021-11-02 15:11                     ` Lorenzo Pieralisi

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=20210910135446.GA15810@lpieralisi \
    --to=lorenzo.pieralisi@arm.com \
    --cc=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=devel@acpica.org \
    --cc=erik.kaneda@intel.com \
    --cc=guohanjun@huawei.com \
    --cc=harb@amperecomputing.com \
    --cc=justin.he@arm.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=robert.moore@intel.com \
    --cc=will@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.