thr3ads.net - Xen devel - [PATCH 0/2] ACPI: fixes to acpi_os_map

If this information is useful, please help other people find it:
Share via:

Jan Beulich

2013-Aug-20 14:44 UTC

[PATCH 0/2] ACPI: fixes to acpi_os_map_memory()

1: ACPI: fix acpi_os_map_memory()
2: ACPI: use ioremap() in acpi_os_map_memory()

While this could have been done in one step for unstable, backports to
older trees (where we don''t have a proper ioremap()) will become better
aligned with the unstable commits this way - the first patch can be
backported, while the second would at most go into 4.3-testing.

This fixes booting on upcoming systems of a vendor who couldn''t make
up their minds whether they would want to be named here (and hence
I''m keeping them anonymous), where various of the ACPI registers
traditionally located in I/O space show up in "System Memory" instead.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

Jan Beulich

2013-Aug-20 14:50 UTC

head link

[PATCH 1/2] ACPI: fix acpi_os_map_memory()

It using map_domain_page() was entirely wrong. Use __acpi_map_table()
instead for the time being, with locking added as the mappings it
produces get replaced with subsequent invocations. Using locking in
this way is acceptable here since the only two runtime callers are
acpi_os_{read,write}_memory(), which don''t leave mappings pending upon
returning to their callers.

Also fix __acpi_map_table()''s first parameter''s type - while
benign for
unstable, backports to pre-4.3 trees will need this.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/acpi/lib.c
+++ b/xen/arch/x86/acpi/lib.c
@@ -39,7 +39,7 @@ u32 __read_mostly x86_acpiid_to_apicid[M
  * from the fixed base.  That''s why we start at FIX_ACPI_END and
  * count idx down while incrementing the phys address.
  */
-char *__acpi_map_table(unsigned long phys, unsigned long size)
+char *__acpi_map_table(paddr_t phys, unsigned long size)
 {
 	unsigned long base, offset, mapped_size;
 	int idx;
--- a/xen/drivers/acpi/osl.c
+++ b/xen/drivers/acpi/osl.c
@@ -83,14 +83,20 @@ acpi_physical_address __init acpi_os_get
 	}
 }
 
-void __iomem *__init
+static DEFINE_SPINLOCK(map_lock);
+
+void __iomem *
 acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
 {
-	return __acpi_map_table((unsigned long)phys, size);
+	if (system_state >= SYS_STATE_active)
+		spin_lock(&map_lock);
+	return __acpi_map_table(phys, size);
 }
 
-void __init acpi_os_unmap_memory(void __iomem * virt, acpi_size size)
+void acpi_os_unmap_memory(void __iomem * virt, acpi_size size)
 {
+	if (system_state >= SYS_STATE_active)
+		spin_unlock(&map_lock);
 }
 
 acpi_status acpi_os_read_port(acpi_io_address port, u32 * value, u32 width)
@@ -133,9 +139,8 @@ acpi_status
 acpi_os_read_memory(acpi_physical_address phys_addr, u32 * value, u32 width)
 {
 	u32 dummy;
-	void __iomem *virt_addr;
+	void __iomem *virt_addr = acpi_os_map_memory(phys_addr, width >> 3);
 
-	virt_addr = map_domain_page(phys_addr>>PAGE_SHIFT);
 	if (!value)
 		value = &dummy;
 
@@ -153,7 +158,7 @@ acpi_os_read_memory(acpi_physical_addres
 		BUG();
 	}
 
-	unmap_domain_page(virt_addr);
+	acpi_os_unmap_memory(virt_addr, width >> 3);
 
 	return AE_OK;
 }
@@ -161,9 +166,7 @@ acpi_os_read_memory(acpi_physical_addres
 acpi_status
 acpi_os_write_memory(acpi_physical_address phys_addr, u32 value, u32 width)
 {
-	void __iomem *virt_addr;
-
-	virt_addr = map_domain_page(phys_addr>>PAGE_SHIFT);
+	void __iomem *virt_addr = acpi_os_map_memory(phys_addr, width >> 3);
 
 	switch (width) {
 	case 8:
@@ -179,7 +182,7 @@ acpi_os_write_memory(acpi_physical_addre
 		BUG();
 	}
 
-	unmap_domain_page(virt_addr);
+	acpi_os_unmap_memory(virt_addr, width >> 3);
 
 	return AE_OK;
 }
--- a/xen/include/xen/acpi.h
+++ b/xen/include/xen/acpi.h
@@ -56,7 +56,7 @@ typedef int (*acpi_table_handler) (struc
 typedef int (*acpi_table_entry_handler) (struct acpi_subtable_header *header,
const unsigned long end);
 
 unsigned int acpi_get_processor_id (unsigned int cpu);
-char * __acpi_map_table (unsigned long phys_addr, unsigned long size);
+char * __acpi_map_table (paddr_t phys_addr, unsigned long size);
 int acpi_boot_init (void);
 int acpi_boot_table_init (void);
 int acpi_numa_init (void);





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Jan Beulich

2013-Aug-20 14:51 UTC

head link

[PATCH 2/2] ACPI: use ioremap() in acpi_os_map_memory()

This drops the post-boot use of __acpi_map_table() here again (together
with the somewhat awkward locking), in favor of using ioremap().

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/acpi/osl.c
+++ b/xen/drivers/acpi/osl.c
@@ -38,6 +38,7 @@
 #include <xen/spinlock.h>
 #include <xen/domain_page.h>
 #include <xen/efi.h>
+#include <xen/vmap.h>
 
 #define _COMPONENT		ACPI_OS_SERVICES
 ACPI_MODULE_NAME("osl")
@@ -83,20 +84,25 @@ acpi_physical_address __init acpi_os_get
 	}
 }
 
-static DEFINE_SPINLOCK(map_lock);
-
 void __iomem *
 acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
 {
-	if (system_state >= SYS_STATE_active)
-		spin_lock(&map_lock);
+	if (system_state >= SYS_STATE_active) {
+		unsigned long pfn = PFN_DOWN(phys);
+		unsigned int offs = phys & (PAGE_SIZE - 1);
+
+		/* The low first Mb is always mapped. */
+		if ( !((phys + size - 1) >> 20) )
+			return __va(phys);
+		return __vmap(&pfn, PFN_UP(offs + size), 1, 1, PAGE_HYPERVISOR_NOCACHE) +
offs;
+	}
 	return __acpi_map_table(phys, size);
 }
 
 void acpi_os_unmap_memory(void __iomem * virt, acpi_size size)
 {
 	if (system_state >= SYS_STATE_active)
-		spin_unlock(&map_lock);
+		vunmap((void *)((unsigned long)virt & PAGE_MASK));
 }
 
 acpi_status acpi_os_read_port(acpi_io_address port, u32 * value, u32 width)





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Keir Fraser

2013-Aug-20 15:20 UTC

head link

Re: [PATCH 0/2] ACPI: fixes to acpi_os_map_memory()

On 20/08/2013 15:44, "Jan Beulich" <JBeulich@suse.com> wrote:
> 1: ACPI: fix acpi_os_map_memory()
> 2: ACPI: use ioremap() in acpi_os_map_memory()
> 
> While this could have been done in one step for unstable, backports to
> older trees (where we don''t have a proper ioremap()) will become
better
> aligned with the unstable commits this way - the first patch can be
> backported, while the second would at most go into 4.3-testing.
> 
> This fixes booting on upcoming systems of a vendor who couldn''t
make
> up their minds whether they would want to be named here (and hence
> I''m keeping them anonymous), where various of the ACPI registers
> traditionally located in I/O space show up in "System Memory"
instead.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Xen devel - Aug 2013 - [PATCH 0/2] ACPI: fixes to acpi_os_map_memory()

[PATCH 0/2] ACPI: fixes to acpi_os_map_memory()

[PATCH 1/2] ACPI: fix acpi_os_map_memory()

[PATCH 2/2] ACPI: use ioremap() in acpi_os_map_memory()

Re: [PATCH 0/2] ACPI: fixes to acpi_os_map_memory()