* state of some x86 acpi patches
@ 2008-12-16 19:19 Jeremy Fitzhardinge
2008-12-16 19:25 ` Ingo Molnar
2008-12-18 13:44 ` Andi Kleen
0 siblings, 2 replies; 15+ messages in thread
From: Jeremy Fitzhardinge @ 2008-12-16 19:19 UTC (permalink / raw)
To: Brown, Len, Yinghai Lu, linux-acpi; +Cc: Ingo Molnar
[-- Attachment #1: Type: text/plain, Size: 247 bytes --]
Hi Len,
Have you seen these three patches? Do they look OK to you?
Yinghai Lu improve the third patch ("acpi: remove final __acpi_map_table
mapping before setting acpi_gbl_permanent_mmap"), which I think Ingo
sent you instead.
Thanks,
J
[-- Attachment #2: x86-__acpi_map_table-use-early_ioremap.patch --]
[-- Type: text/plain, Size: 3252 bytes --]
Subject: x86: use early_ioremap in __acpi_map_table
__acpi_map_table effectively reimplements early_ioremap(). Rather
than have that duplication, just implement it in terms of
early_ioremap().
However, unlike early_ioremap(), __acpi_map_table just maintains a
single mapping which gets replaced each call, and has no corresponding
unmap function. Implement this by just removing the previous mapping
each time its called. Unfortunately, this will leave a stray mapping
at the end.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
arch/x86/include/asm/acpi.h | 3 ---
arch/x86/include/asm/fixmap_32.h | 4 ----
arch/x86/include/asm/fixmap_64.h | 4 ----
arch/x86/kernel/acpi/boot.c | 27 +++++++--------------------
4 files changed, 7 insertions(+), 31 deletions(-)
===================================================================
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -121,8 +121,8 @@
*/
char *__init __acpi_map_table(unsigned long phys, unsigned long size)
{
- unsigned long base, offset, mapped_size;
- int idx;
+ static char *prev_map;
+ static unsigned long prev_size;
if (!phys || !size)
return NULL;
@@ -130,26 +130,13 @@
if (phys+size <= (max_low_pfn_mapped << PAGE_SHIFT))
return __va(phys);
- offset = phys & (PAGE_SIZE - 1);
- mapped_size = PAGE_SIZE - offset;
- clear_fixmap(FIX_ACPI_END);
- set_fixmap(FIX_ACPI_END, phys);
- base = fix_to_virt(FIX_ACPI_END);
+ if (prev_map)
+ early_iounmap(prev_map, prev_size);
- /*
- * Most cases can be covered by the below.
- */
- idx = FIX_ACPI_END;
- while (mapped_size < size) {
- if (--idx < FIX_ACPI_BEGIN)
- return NULL; /* cannot handle this */
- phys += PAGE_SIZE;
- clear_fixmap(idx);
- set_fixmap(idx, phys);
- mapped_size += PAGE_SIZE;
- }
+ prev_size = size;
+ prev_map = early_ioremap(phys, size);
- return ((unsigned char *)base + offset);
+ return prev_map;
}
#ifdef CONFIG_PCI_MMCONFIG
===================================================================
--- a/arch/x86/include/asm/acpi.h
+++ b/arch/x86/include/asm/acpi.h
@@ -102,9 +102,6 @@
acpi_noirq = 1;
}
-/* Fixmap pages to reserve for ACPI boot-time tables (see fixmap.h) */
-#define FIX_ACPI_PAGES 4
-
extern int acpi_gsi_to_irq(u32 gsi, unsigned int *irq);
static inline void acpi_noirq_set(void) { acpi_noirq = 1; }
===================================================================
--- a/arch/x86/include/asm/fixmap_32.h
+++ b/arch/x86/include/asm/fixmap_32.h
@@ -99,10 +99,6 @@
(__end_of_permanent_fixed_addresses & 255),
FIX_BTMAP_BEGIN = FIX_BTMAP_END + NR_FIX_BTMAPS*FIX_BTMAPS_NESTING - 1,
FIX_WP_TEST,
-#ifdef CONFIG_ACPI
- FIX_ACPI_BEGIN,
- FIX_ACPI_END = FIX_ACPI_BEGIN + FIX_ACPI_PAGES - 1,
-#endif
#ifdef CONFIG_PROVIDE_OHCI1394_DMA_INIT
FIX_OHCI1394_BASE,
#endif
===================================================================
--- a/arch/x86/include/asm/fixmap_64.h
+++ b/arch/x86/include/asm/fixmap_64.h
@@ -50,10 +50,6 @@
FIX_PARAVIRT_BOOTMAP,
#endif
__end_of_permanent_fixed_addresses,
-#ifdef CONFIG_ACPI
- FIX_ACPI_BEGIN,
- FIX_ACPI_END = FIX_ACPI_BEGIN + FIX_ACPI_PAGES - 1,
-#endif
#ifdef CONFIG_PROVIDE_OHCI1394_DMA_INIT
FIX_OHCI1394_BASE,
#endif
[-- Attachment #3: x86-acpi-always-map.patch --]
[-- Type: text/plain, Size: 878 bytes --]
Subject: x86: always explicitly map acpi memory
Always map acpi tables, rather than assuming we can use the normal
linear mapping to access the acpi tables. This is necessary in a
virtual environment where the linear mappings are to pseudo-physical
memory, but the acpi tables exist at a real physical address. It
doesn't hurt to map in the normal non-virtual case, so just do it
unconditionally.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
arch/x86/kernel/acpi/boot.c | 3 ---
1 file changed, 3 deletions(-)
===================================================================
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -126,9 +126,6 @@
if (!phys || !size)
return NULL;
-
- if (phys+size <= (max_low_pfn_mapped << PAGE_SHIFT))
- return __va(phys);
if (prev_map)
early_iounmap(prev_map, prev_size);
[-- Attachment #4: acpi-clear-__acpi_map_table-mapping.patch --]
[-- Type: text/plain, Size: 1491 bytes --]
Subject: acpi: remove final __acpi_map_table mapping before setting acpi_gbl_permanent_mmap
On x86, __acpi_map_table uses early_ioremap() to create the mapping,
replacing the previous mapping with a new one. Once enough of the
kernel is up an running it switches to using normal ioremap(). At
that point, we need to clean up the final mapping to avoid a warning
from the early_ioremap subsystem.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
arch/x86/kernel/acpi/boot.c | 8 +++++---
drivers/acpi/bus.c | 6 ++++++
2 files changed, 11 insertions(+), 3 deletions(-)
===================================================================
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -124,11 +124,13 @@
static char *prev_map;
static unsigned long prev_size;
+ if (prev_map) {
+ early_iounmap(prev_map, prev_size);
+ prev_map = NULL;
+ }
+
if (!phys || !size)
return NULL;
-
- if (prev_map)
- early_iounmap(prev_map, prev_size);
prev_size = size;
prev_map = early_ioremap(phys, size);
===================================================================
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -650,6 +650,12 @@
if (!acpi_strict)
acpi_gbl_enable_interpreter_slack = TRUE;
+ /*
+ * Doing a zero-sized mapping will clear out the previous
+ * __acpi_map_table() mapping, if any.
+ */
+ __acpi_map_table(0, 0);
+
acpi_gbl_permanent_mmap = 1;
status = acpi_reallocate_root_table();
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: state of some x86 acpi patches 2008-12-16 19:19 state of some x86 acpi patches Jeremy Fitzhardinge @ 2008-12-16 19:25 ` Ingo Molnar 2008-12-31 23:38 ` Len Brown 2008-12-18 13:44 ` Andi Kleen 1 sibling, 1 reply; 15+ messages in thread From: Ingo Molnar @ 2008-12-16 19:25 UTC (permalink / raw) To: Jeremy Fitzhardinge; +Cc: Brown, Len, Yinghai Lu, linux-acpi * Jeremy Fitzhardinge <jeremy@goop.org> wrote: > Hi Len, > > Have you seen these three patches? Do they look OK to you? > > Yinghai Lu improve the third patch ("acpi: remove final __acpi_map_table > mapping before setting acpi_gbl_permanent_mmap"), which I think Ingo > sent you instead. Len, i asked about these patches before too - and if that's fine with you we'd just queue them up in the x86 tree (like we did before the .28 merge window). Most of the impact will be on x86. So an Acked-by from you would be fine to start this. Ingo ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: state of some x86 acpi patches 2008-12-16 19:25 ` Ingo Molnar @ 2008-12-31 23:38 ` Len Brown 2009-01-01 6:49 ` Jeremy Fitzhardinge 0 siblings, 1 reply; 15+ messages in thread From: Len Brown @ 2008-12-31 23:38 UTC (permalink / raw) To: Ingo Molnar; +Cc: Jeremy Fitzhardinge, Yinghai Lu, linux-acpi On Tue, 16 Dec 2008, Ingo Molnar wrote: > > * Jeremy Fitzhardinge <jeremy@goop.org> wrote: > > > Hi Len, > > > > Have you seen these three patches? Do they look OK to you? > > > > Yinghai Lu improve the third patch ("acpi: remove final __acpi_map_table > > mapping before setting acpi_gbl_permanent_mmap"), which I think Ingo > > sent you instead. > > Len, > > i asked about these patches before too - and if that's fine with you we'd > just queue them up in the x86 tree (like we did before the .28 merge > window). Most of the impact will be on x86. So an Acked-by from you would > be fine to start this. Sorry for the delay. I recall reading your e-mail on this and thought I replied to it, but for some reason I found neither your original message nor my reply when I searched my archives today. But I did recall Ingo making a branch for this one, and so looking at remotes/origin/acpi-for-len in ingo's tree... It isn't immediately clear to me what problem this patch series solves, and thus it is hard to judge how important this is. It touches a lot of files, and it is going to run into a bunch of merge conflicts. I'm not thrilled that the first part of the series makes changes which are then undone by the later part of the series -- that doesn't help w/ conflict resolution... The change to tbxface.c is an ACPICA API change. It looks reasonable and it might be the right change, but it is extra work -- we should sync with Bob when he gets back from break. So, this one is sort of a headache, how important is it? thanks, -- Len Brown, Intel Open Source Technology Center ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: state of some x86 acpi patches 2008-12-31 23:38 ` Len Brown @ 2009-01-01 6:49 ` Jeremy Fitzhardinge 2009-01-02 15:39 ` Ingo Molnar 0 siblings, 1 reply; 15+ messages in thread From: Jeremy Fitzhardinge @ 2009-01-01 6:49 UTC (permalink / raw) To: Len Brown; +Cc: Ingo Molnar, Yinghai Lu, linux-acpi Len Brown wrote: > On Tue, 16 Dec 2008, Ingo Molnar wrote: > > >> * Jeremy Fitzhardinge <jeremy@goop.org> wrote: >> >> >>> Hi Len, >>> >>> Have you seen these three patches? Do they look OK to you? >>> >>> Yinghai Lu improve the third patch ("acpi: remove final __acpi_map_table >>> mapping before setting acpi_gbl_permanent_mmap"), which I think Ingo >>> sent you instead. >>> >> Len, >> >> i asked about these patches before too - and if that's fine with you we'd >> just queue them up in the x86 tree (like we did before the .28 merge >> window). Most of the impact will be on x86. So an Acked-by from you would >> be fine to start this. >> > > Sorry for the delay. > I recall reading your e-mail on this and thought I replied to it, > but for some reason I found neither your original message nor > my reply when I searched my archives today. > > But I did recall Ingo making a branch for this one, and so looking > at remotes/origin/acpi-for-len in ingo's tree... > > It isn't immediately clear to me what problem this patch series solves, > and thus it is hard to judge how important this is. > > It touches a lot of files, and it is going to run into a bunch of merge > conflicts. > > I'm not thrilled that the first part of the series makes changes > which are then undone by the later part of the series -- > that doesn't help w/ conflict resolution... > > The change to tbxface.c is an ACPICA API change. > It looks reasonable and it might be the right change, > but it is extra work -- we should sync with Bob > when he gets back from break. > > So, this one is sort of a headache, how important is it? > Well, there's several aspects to this series: The important one from my perspective is using early_ioremap to map the acpi memory, rather than using a private mapping function; this is necessary when running under Xen, so that the right memory gets mapped. This in itself is pretty straightforward, but it raises a few issues. One is that the acpi code doesn't properly unmap its mapped memory, but relies on a "new mapping replaces old" semantic. Putting a wrapper around early_ioremap to emulate this is fairly straightforward, but it does leave one trailing mapping, which causes early_ioremap to raise a warning. I addressed this warning by putting in a hook to unmap the last mapping. This was simple, but pretty hackish. Yinghai went the extra distance by making the acpi code properly pair map and unmap calls on all the resources it needs, doing away with the "new map unmaps previous" behaviour, and cleaning up the warning in the process. Thanks, J ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: state of some x86 acpi patches 2009-01-01 6:49 ` Jeremy Fitzhardinge @ 2009-01-02 15:39 ` Ingo Molnar 2009-01-02 22:28 ` Len Brown 2009-01-28 23:45 ` Jeremy Fitzhardinge 0 siblings, 2 replies; 15+ messages in thread From: Ingo Molnar @ 2009-01-02 15:39 UTC (permalink / raw) To: Jeremy Fitzhardinge; +Cc: Len Brown, Yinghai Lu, linux-acpi * Jeremy Fitzhardinge <jeremy@goop.org> wrote: > Len Brown wrote: >> On Tue, 16 Dec 2008, Ingo Molnar wrote: >> >> >>> * Jeremy Fitzhardinge <jeremy@goop.org> wrote: >>> >>> >>>> Hi Len, >>>> >>>> Have you seen these three patches? Do they look OK to you? >>>> >>>> Yinghai Lu improve the third patch ("acpi: remove final >>>> __acpi_map_table mapping before setting acpi_gbl_permanent_mmap"), >>>> which I think Ingo sent you instead. >>>> >>> Len, >>> >>> i asked about these patches before too - and if that's fine with you >>> we'd just queue them up in the x86 tree (like we did before the .28 >>> merge window). Most of the impact will be on x86. So an Acked-by from >>> you would be fine to start this. >>> >> >> Sorry for the delay. >> I recall reading your e-mail on this and thought I replied to it, >> but for some reason I found neither your original message nor >> my reply when I searched my archives today. >> >> But I did recall Ingo making a branch for this one, and so looking >> at remotes/origin/acpi-for-len in ingo's tree... >> >> It isn't immediately clear to me what problem this patch series solves, >> and thus it is hard to judge how important this is. >> >> It touches a lot of files, and it is going to run into a bunch of merge >> conflicts. >> >> I'm not thrilled that the first part of the series makes changes >> which are then undone by the later part of the series -- >> that doesn't help w/ conflict resolution... >> >> The change to tbxface.c is an ACPICA API change. >> It looks reasonable and it might be the right change, >> but it is extra work -- we should sync with Bob >> when he gets back from break. >> >> So, this one is sort of a headache, how important is it? >> > > Well, there's several aspects to this series: > > The important one from my perspective is using early_ioremap to map the > acpi memory, rather than using a private mapping function; this is > necessary when running under Xen, so that the right memory gets mapped. > > This in itself is pretty straightforward, but it raises a few issues. > One is that the acpi code doesn't properly unmap its mapped memory, but > relies on a "new mapping replaces old" semantic. Putting a wrapper > around early_ioremap to emulate this is fairly straightforward, but it > does leave one trailing mapping, which causes early_ioremap to raise a > warning. > > I addressed this warning by putting in a hook to unmap the last mapping. > This was simple, but pretty hackish. Yinghai went the extra distance by > making the acpi code properly pair map and unmap calls on all the > resources it needs, doing away with the "new map unmaps previous" > behaviour, and cleaning up the warning in the process. yes, that end result is the desired state of things. We did run with this for several months and resolved all the cases that needed fixing, but dropped them when the ACPI tree moved out from under us. Can resurrect it if Len feels OK about the concept. Len, you shouldnt worry about conflicts - we can do it after the ACPI changes of this merge window are upstream so there should be no conflict trouble at all. How does that sound? Ingo ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: state of some x86 acpi patches 2009-01-02 15:39 ` Ingo Molnar @ 2009-01-02 22:28 ` Len Brown 2009-01-28 23:45 ` Jeremy Fitzhardinge 1 sibling, 0 replies; 15+ messages in thread From: Len Brown @ 2009-01-02 22:28 UTC (permalink / raw) To: Ingo Molnar; +Cc: Jeremy Fitzhardinge, Yinghai Lu, linux-acpi > yes, that end result is the desired state of things. We did run with this > for several months and resolved all the cases that needed fixing, but > dropped them when the ACPI tree moved out from under us. > > Can resurrect it if Len feels OK about the concept. Len, you shouldnt > worry about conflicts - we can do it after the ACPI changes of this merge > window are upstream so there should be no conflict trouble at all. How > does that sound? Sounds great! thanks, Len Brown, Intel Open Source Technology Center ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: state of some x86 acpi patches 2009-01-02 15:39 ` Ingo Molnar 2009-01-02 22:28 ` Len Brown @ 2009-01-28 23:45 ` Jeremy Fitzhardinge 2009-01-29 1:10 ` Yinghai Lu 1 sibling, 1 reply; 15+ messages in thread From: Jeremy Fitzhardinge @ 2009-01-28 23:45 UTC (permalink / raw) To: Ingo Molnar; +Cc: Len Brown, Yinghai Lu, linux-acpi Ingo Molnar wrote: > yes, that end result is the desired state of things. We did run with this > for several months and resolved all the cases that needed fixing, but > dropped them when the ACPI tree moved out from under us. > > Can resurrect it if Len feels OK about the concept. Len, you shouldnt > worry about conflicts - we can do it after the ACPI changes of this merge > window are upstream so there should be no conflict trouble at all. How > does that sound? > Doesn't look like these changes made it in this time. Did they get overlooked, or did some other problem come up? Or did you want me to dig them up? Thanks, J ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: state of some x86 acpi patches 2009-01-28 23:45 ` Jeremy Fitzhardinge @ 2009-01-29 1:10 ` Yinghai Lu 2009-02-07 2:58 ` Jeremy Fitzhardinge 0 siblings, 1 reply; 15+ messages in thread From: Yinghai Lu @ 2009-01-29 1:10 UTC (permalink / raw) To: Jeremy Fitzhardinge; +Cc: Ingo Molnar, Len Brown, linux-acpi [-- Attachment #1: Type: text/plain, Size: 787 bytes --] Jeremy Fitzhardinge wrote: > Ingo Molnar wrote: >> yes, that end result is the desired state of things. We did run with >> this for several months and resolved all the cases that needed fixing, >> but dropped them when the ACPI tree moved out from under us. >> >> Can resurrect it if Len feels OK about the concept. Len, you shouldnt >> worry about conflicts - we can do it after the ACPI changes of this >> merge window are upstream so there should be no conflict trouble at >> all. How does that sound? >> > > Doesn't look like these changes made it in this time. Did they get > overlooked, or did some other problem come up? Or did you want me to > dig them up? > > Thanks, > J please check attached that are updated to today tip/master with ingo's genapic patchset.. YH [-- Attachment #2: acpi_use_early_ioremap_1.patch --] [-- Type: text/x-patch, Size: 3921 bytes --] commit ac77f220e5b99e8d7bfeae21516b4ac8736c266c Author: Jeremy Fitzhardinge <jeremy@goop.org> Date: Sun Sep 7 15:21:18 2008 -0700 x86: use early_ioremap in __acpi_map_table __acpi_map_table() effectively reimplements early_ioremap(). Rather than have that duplication, just implement it in terms of early_ioremap(). However, unlike early_ioremap(), __acpi_map_table() just maintains a single mapping which gets replaced each call, and has no corresponding unmap function. Implement this by just removing the previous mapping each time its called. Unfortunately, this will leave a stray mapping at the end. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> --- arch/x86/include/asm/acpi.h | 3 --- arch/x86/include/asm/fixmap_32.h | 4 ---- arch/x86/include/asm/fixmap_64.h | 4 ---- arch/x86/kernel/acpi/boot.c | 29 ++++++++--------------------- 4 files changed, 8 insertions(+), 32 deletions(-) Index: linux-2.6/arch/x86/kernel/acpi/boot.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/acpi/boot.c +++ linux-2.6/arch/x86/kernel/acpi/boot.c @@ -108,8 +108,8 @@ enum acpi_irq_model_id acpi_irq_model = */ char *__init __acpi_map_table(unsigned long phys, unsigned long size) { - unsigned long base, offset, mapped_size; - int idx; + static char *prev_map; + static unsigned long prev_size; if (!phys || !size) return NULL; @@ -117,26 +117,13 @@ char *__init __acpi_map_table(unsigned l if (phys+size <= (max_low_pfn_mapped << PAGE_SHIFT)) return __va(phys); - offset = phys & (PAGE_SIZE - 1); - mapped_size = PAGE_SIZE - offset; - clear_fixmap(FIX_ACPI_END); - set_fixmap(FIX_ACPI_END, phys); - base = fix_to_virt(FIX_ACPI_END); - - /* - * Most cases can be covered by the below. - */ - idx = FIX_ACPI_END; - while (mapped_size < size) { - if (--idx < FIX_ACPI_BEGIN) - return NULL; /* cannot handle this */ - phys += PAGE_SIZE; - clear_fixmap(idx); - set_fixmap(idx, phys); - mapped_size += PAGE_SIZE; - } + if (prev_map) + early_iounmap(prev_map, prev_size); - return ((unsigned char *)base + offset); + prev_size = size; + prev_map = early_ioremap(phys, size); + + return prev_map; } #ifdef CONFIG_PCI_MMCONFIG Index: linux-2.6/arch/x86/include/asm/acpi.h =================================================================== --- linux-2.6.orig/arch/x86/include/asm/acpi.h +++ linux-2.6/arch/x86/include/asm/acpi.h @@ -102,9 +102,6 @@ static inline void disable_acpi(void) acpi_noirq = 1; } -/* Fixmap pages to reserve for ACPI boot-time tables (see fixmap.h) */ -#define FIX_ACPI_PAGES 4 - extern int acpi_gsi_to_irq(u32 gsi, unsigned int *irq); static inline void acpi_noirq_set(void) { acpi_noirq = 1; } Index: linux-2.6/arch/x86/include/asm/fixmap_32.h =================================================================== --- linux-2.6.orig/arch/x86/include/asm/fixmap_32.h +++ linux-2.6/arch/x86/include/asm/fixmap_32.h @@ -95,10 +95,6 @@ enum fixed_addresses { (__end_of_permanent_fixed_addresses & 255), FIX_BTMAP_BEGIN = FIX_BTMAP_END + NR_FIX_BTMAPS*FIX_BTMAPS_SLOTS - 1, FIX_WP_TEST, -#ifdef CONFIG_ACPI - FIX_ACPI_BEGIN, - FIX_ACPI_END = FIX_ACPI_BEGIN + FIX_ACPI_PAGES - 1, -#endif #ifdef CONFIG_PROVIDE_OHCI1394_DMA_INIT FIX_OHCI1394_BASE, #endif Index: linux-2.6/arch/x86/include/asm/fixmap_64.h =================================================================== --- linux-2.6.orig/arch/x86/include/asm/fixmap_64.h +++ linux-2.6/arch/x86/include/asm/fixmap_64.h @@ -50,10 +50,6 @@ enum fixed_addresses { FIX_PARAVIRT_BOOTMAP, #endif __end_of_permanent_fixed_addresses, -#ifdef CONFIG_ACPI - FIX_ACPI_BEGIN, - FIX_ACPI_END = FIX_ACPI_BEGIN + FIX_ACPI_PAGES - 1, -#endif #ifdef CONFIG_PROVIDE_OHCI1394_DMA_INIT FIX_OHCI1394_BASE, #endif [-- Attachment #3: acpi_use_early_ioremap_2.patch --] [-- Type: text/x-patch, Size: 1197 bytes --] commit c95f866ed97595a48b3dcbb6d265d5f1ae37866e Author: Jeremy Fitzhardinge <jeremy@goop.org> Date: Sun Sep 7 15:21:19 2008 -0700 x86: always explicitly map acpi memory Always map acpi tables, rather than assuming we can use the normal linear mapping to access the acpi tables. This is necessary in a virtual environment where the linear mappings are to pseudo-physical memory, but the acpi tables exist at a real physical address. It doesn't hurt to map in the normal non-virtual case, so just do it unconditionally. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> --- arch/x86/kernel/acpi/boot.c | 3 --- 1 file changed, 3 deletions(-) Index: linux-2.6/arch/x86/kernel/acpi/boot.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/acpi/boot.c +++ linux-2.6/arch/x86/kernel/acpi/boot.c @@ -114,9 +114,6 @@ char *__init __acpi_map_table(unsigned l if (!phys || !size) return NULL; - if (phys+size <= (max_low_pfn_mapped << PAGE_SHIFT)) - return __va(phys); - if (prev_map) early_iounmap(prev_map, prev_size); [-- Attachment #4: acpi_use_early_ioremap_3.patch --] [-- Type: text/x-patch, Size: 2108 bytes --] commit 5c48856148e7b02257a663f49128544814a07255 Author: Jeremy Fitzhardinge <jeremy@goop.org> Date: Thu Sep 11 14:33:16 2008 -0700 acpi: remove final __acpi_map_table mapping before setting acpi_gbl_permanent_mmap On x86, __acpi_map_table uses early_ioremap() to create the mapping, replacing the previous mapping with a new one. Once enough of the kernel is up an running it switches to using normal ioremap(). At that point, we need to clean up the final mapping to avoid a warning from the early_ioremap subsystem. This can be removed after all the instances in the ACPI code are fixed that rely on early-ioremap's implicit overmapping of previously mapped tables. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Cc: Andi Kleen <andi@firstfloor.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> --- arch/x86/kernel/acpi/boot.c | 8 +++++--- drivers/acpi/bus.c | 6 ++++++ 2 files changed, 11 insertions(+), 3 deletions(-) Index: linux-2.6/arch/x86/kernel/acpi/boot.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/acpi/boot.c +++ linux-2.6/arch/x86/kernel/acpi/boot.c @@ -111,12 +111,14 @@ char *__init __acpi_map_table(unsigned l static char *prev_map; static unsigned long prev_size; + if (prev_map) { + early_iounmap(prev_map, prev_size); + prev_map = NULL; + } + if (!phys || !size) return NULL; - if (prev_map) - early_iounmap(prev_map, prev_size); - prev_size = size; prev_map = early_ioremap(phys, size); Index: linux-2.6/drivers/acpi/bus.c =================================================================== --- linux-2.6.orig/drivers/acpi/bus.c +++ linux-2.6/drivers/acpi/bus.c @@ -694,6 +694,12 @@ void __init acpi_early_init(void) if (!acpi_strict) acpi_gbl_enable_interpreter_slack = TRUE; + /* + * Doing a zero-sized mapping will clear out the previous + * __acpi_map_table() mapping, if any. + */ + __acpi_map_table(0, 0); + acpi_gbl_permanent_mmap = 1; status = acpi_reallocate_root_table(); [-- Attachment #5: acpi_use_early_ioremap_4.patch --] [-- Type: text/x-patch, Size: 10015 bytes --] commit 5560cb0d955aad89ea0001baa0da675dba97650b Author: Yinghai Lu <yhlu.kernel@gmail.com> Date: Sun Sep 14 02:33:13 2008 -0700 acpi/x86: introduce __apci_map_table, v4 to prevent wrongly overwriting fixmap that still want to use. ACPI used to rely on low mappings being all linearly mapped and grew a habit: it never really unmapped certain kinds of tables after use. This can cause problems - for example the hypothetical case when some spurious access still references it. v2: remove prev_map and prev_size in __apci_map_table v3: let acpi_os_unmap_memory() call early_iounmap too, so remove extral calling to early_acpi_os_unmap_memory v4: fix typo in one acpi_get_table_with_size calling Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> --- arch/ia64/kernel/acpi.c | 4 ++++ arch/x86/kernel/acpi/boot.c | 17 +++++++---------- drivers/acpi/acpica/tbxface.c | 17 ++++++++++++++--- drivers/acpi/bus.c | 6 ------ drivers/acpi/osl.c | 11 +++++++++-- drivers/acpi/tables.c | 20 ++++++++++++++------ include/acpi/acpiosxf.h | 1 + include/acpi/acpixf.h | 4 ++++ include/linux/acpi.h | 1 + 9 files changed, 54 insertions(+), 27 deletions(-) Index: linux-2.6/arch/ia64/kernel/acpi.c =================================================================== --- linux-2.6.orig/arch/ia64/kernel/acpi.c +++ linux-2.6/arch/ia64/kernel/acpi.c @@ -199,6 +199,10 @@ char *__init __acpi_map_table(unsigned l return __va(phys_addr); } +char *__init __acpi_unmap_table(unsigned long virt_addr, unsigned long size) +{ +} + /* -------------------------------------------------------------------------- Boot-time Table Parsing -------------------------------------------------------------------------- */ Index: linux-2.6/arch/x86/kernel/acpi/boot.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/acpi/boot.c +++ linux-2.6/arch/x86/kernel/acpi/boot.c @@ -108,21 +108,18 @@ enum acpi_irq_model_id acpi_irq_model = */ char *__init __acpi_map_table(unsigned long phys, unsigned long size) { - static char *prev_map; - static unsigned long prev_size; - - if (prev_map) { - early_iounmap(prev_map, prev_size); - prev_map = NULL; - } if (!phys || !size) return NULL; - prev_size = size; - prev_map = early_ioremap(phys, size); + return early_ioremap(phys, size); +} +void __init __acpi_unmap_table(char *map, unsigned long size) +{ + if (!map || !size) + return; - return prev_map; + early_iounmap(map, size); } #ifdef CONFIG_PCI_MMCONFIG Index: linux-2.6/drivers/acpi/bus.c =================================================================== --- linux-2.6.orig/drivers/acpi/bus.c +++ linux-2.6/drivers/acpi/bus.c @@ -694,12 +694,6 @@ void __init acpi_early_init(void) if (!acpi_strict) acpi_gbl_enable_interpreter_slack = TRUE; - /* - * Doing a zero-sized mapping will clear out the previous - * __acpi_map_table() mapping, if any. - */ - __acpi_map_table(0, 0); - acpi_gbl_permanent_mmap = 1; status = acpi_reallocate_root_table(); Index: linux-2.6/drivers/acpi/osl.c =================================================================== --- linux-2.6.orig/drivers/acpi/osl.c +++ linux-2.6/drivers/acpi/osl.c @@ -274,12 +274,19 @@ EXPORT_SYMBOL_GPL(acpi_os_map_memory); void acpi_os_unmap_memory(void __iomem * virt, acpi_size size) { - if (acpi_gbl_permanent_mmap) { + if (acpi_gbl_permanent_mmap) iounmap(virt); - } + else + __acpi_unmap_table(virt, size); } EXPORT_SYMBOL_GPL(acpi_os_unmap_memory); +void early_acpi_os_unmap_memory(void __iomem * virt, acpi_size size) +{ + if (!acpi_gbl_permanent_mmap) + __acpi_unmap_table(virt, size); +} + #ifdef ACPI_FUTURE_USAGE acpi_status acpi_os_get_physical_address(void *virt, acpi_physical_address * phys) Index: linux-2.6/drivers/acpi/tables.c =================================================================== --- linux-2.6.orig/drivers/acpi/tables.c +++ linux-2.6/drivers/acpi/tables.c @@ -181,14 +181,15 @@ acpi_table_parse_entries(char *id, struct acpi_subtable_header *entry; unsigned int count = 0; unsigned long table_end; + acpi_size tbl_size; if (!handler) return -EINVAL; if (strncmp(id, ACPI_SIG_MADT, 4) == 0) - acpi_get_table(id, acpi_apic_instance, &table_header); + acpi_get_table_with_size(id, acpi_apic_instance, &table_header, &tbl_size); else - acpi_get_table(id, 0, &table_header); + acpi_get_table_with_size(id, 0, &table_header, &tbl_size); if (!table_header) { printk(KERN_WARNING PREFIX "%4.4s not present\n", id); @@ -206,8 +207,10 @@ acpi_table_parse_entries(char *id, table_end) { if (entry->type == entry_id && (!max_entries || count++ < max_entries)) - if (handler(entry, table_end)) + if (handler(entry, table_end)) { + early_acpi_os_unmap_memory((char *)table_header, tbl_size); return -EINVAL; + } entry = (struct acpi_subtable_header *) ((unsigned long)entry + entry->length); @@ -217,6 +220,7 @@ acpi_table_parse_entries(char *id, "%i found\n", id, entry_id, count - max_entries, count); } + early_acpi_os_unmap_memory((char *)table_header, tbl_size); return count; } @@ -241,17 +245,19 @@ acpi_table_parse_madt(enum acpi_madt_typ int __init acpi_table_parse(char *id, acpi_table_handler handler) { struct acpi_table_header *table = NULL; + acpi_size tbl_size; if (!handler) return -EINVAL; if (strncmp(id, ACPI_SIG_MADT, 4) == 0) - acpi_get_table(id, acpi_apic_instance, &table); + acpi_get_table_with_size(id, acpi_apic_instance, &table, &tbl_size); else - acpi_get_table(id, 0, &table); + acpi_get_table_with_size(id, 0, &table, &tbl_size); if (table) { handler(table); + early_acpi_os_unmap_memory(table, tbl_size); return 0; } else return 1; @@ -265,8 +271,9 @@ int __init acpi_table_parse(char *id, ac static void __init check_multiple_madt(void) { struct acpi_table_header *table = NULL; + acpi_size tbl_size; - acpi_get_table(ACPI_SIG_MADT, 2, &table); + acpi_get_table_with_size(ACPI_SIG_MADT, 2, &table, &tbl_size); if (table) { printk(KERN_WARNING PREFIX "BIOS bug: multiple APIC/MADT found," @@ -275,6 +282,7 @@ static void __init check_multiple_madt(v "If \"acpi_apic_instance=%d\" works better, " "notify linux-acpi@vger.kernel.org\n", acpi_apic_instance ? 0 : 2); + early_acpi_os_unmap_memory(table, tbl_size); } else acpi_apic_instance = 0; Index: linux-2.6/drivers/acpi/acpica/tbxface.c =================================================================== --- linux-2.6.orig/drivers/acpi/acpica/tbxface.c +++ linux-2.6/drivers/acpi/acpica/tbxface.c @@ -365,7 +365,7 @@ ACPI_EXPORT_SYMBOL(acpi_unload_table_id) /******************************************************************************* * - * FUNCTION: acpi_get_table + * FUNCTION: acpi_get_table_with_size * * PARAMETERS: Signature - ACPI signature of needed table * Instance - Which instance (for SSDTs) @@ -377,8 +377,9 @@ ACPI_EXPORT_SYMBOL(acpi_unload_table_id) * *****************************************************************************/ acpi_status -acpi_get_table(char *signature, - u32 instance, struct acpi_table_header **out_table) +acpi_get_table_with_size(char *signature, + u32 instance, struct acpi_table_header **out_table, + acpi_size *tbl_size) { u32 i; u32 j; @@ -408,6 +409,7 @@ acpi_get_table(char *signature, acpi_tb_verify_table(&acpi_gbl_root_table_list.tables[i]); if (ACPI_SUCCESS(status)) { *out_table = acpi_gbl_root_table_list.tables[i].pointer; + *tbl_size = acpi_gbl_root_table_list.tables[i].length; } if (!acpi_gbl_permanent_mmap) { @@ -420,6 +422,15 @@ acpi_get_table(char *signature, return (AE_NOT_FOUND); } +acpi_status +acpi_get_table(char *signature, + u32 instance, struct acpi_table_header **out_table) +{ + acpi_size tbl_size; + + return acpi_get_table_with_size(signature, + instance, out_table, &tbl_size); +} ACPI_EXPORT_SYMBOL(acpi_get_table) /******************************************************************************* Index: linux-2.6/include/acpi/acpiosxf.h =================================================================== --- linux-2.6.orig/include/acpi/acpiosxf.h +++ linux-2.6/include/acpi/acpiosxf.h @@ -144,6 +144,7 @@ void __iomem *acpi_os_map_memory(acpi_ph acpi_size length); void acpi_os_unmap_memory(void __iomem * logical_address, acpi_size size); +void early_acpi_os_unmap_memory(void __iomem * virt, acpi_size size); #ifdef ACPI_FUTURE_USAGE acpi_status Index: linux-2.6/include/acpi/acpixf.h =================================================================== --- linux-2.6.orig/include/acpi/acpixf.h +++ linux-2.6/include/acpi/acpixf.h @@ -130,6 +130,10 @@ acpi_get_table_header(acpi_string signat struct acpi_table_header *out_table_header); acpi_status +acpi_get_table_with_size(acpi_string signature, + u32 instance, struct acpi_table_header **out_table, + acpi_size *tbl_size); +acpi_status acpi_get_table(acpi_string signature, u32 instance, struct acpi_table_header **out_table); Index: linux-2.6/include/linux/acpi.h =================================================================== --- linux-2.6.orig/include/linux/acpi.h +++ linux-2.6/include/linux/acpi.h @@ -79,6 +79,7 @@ typedef int (*acpi_table_handler) (struc typedef int (*acpi_table_entry_handler) (struct acpi_subtable_header *header, const unsigned long end); char * __acpi_map_table (unsigned long phys_addr, unsigned long size); +void __init __acpi_unmap_table(char *map, unsigned long size); int early_acpi_boot_init(void); int acpi_boot_init (void); int acpi_boot_table_init (void); [-- Attachment #6: revert_fix_es7000_compiling.patch --] [-- Type: text/x-patch, Size: 1158 bytes --] --- arch/x86/kernel/es7000_32.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) Index: linux-2.6/arch/x86/kernel/es7000_32.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/es7000_32.c +++ linux-2.6/arch/x86/kernel/es7000_32.c @@ -287,24 +287,31 @@ int __init find_unisys_acpi_oem_table(un { struct acpi_table_header *header = NULL; int i = 0; + acpi_size tbl_size; - while (ACPI_SUCCESS(acpi_get_table("OEM1", i++, &header))) { + while (ACPI_SUCCESS(acpi_get_table_with_size("OEM1", i++, &header, &tbl_size))) { if (!memcmp((char *) &header->oem_id, "UNISYS", 6)) { struct oem_table *t = (struct oem_table *)header; oem_addrX = t->OEMTableAddr; oem_size = t->OEMTableSize; + early_acpi_os_unmap_memory(header, tbl_size); *oem_addr = (unsigned long)__acpi_map_table(oem_addrX, oem_size); return 0; } + early_acpi_os_unmap_memory(header, tbl_size); } return -1; } void __init unmap_unisys_acpi_oem_table(unsigned long oem_addr) { + if (!oem_addr) + return; + + __acpi_unmap_table((char *)oem_addr, oem_size); } #endif ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: state of some x86 acpi patches 2009-01-29 1:10 ` Yinghai Lu @ 2009-02-07 2:58 ` Jeremy Fitzhardinge 2009-02-07 3:18 ` Yinghai Lu 0 siblings, 1 reply; 15+ messages in thread From: Jeremy Fitzhardinge @ 2009-02-07 2:58 UTC (permalink / raw) To: Yinghai Lu; +Cc: Ingo Molnar, Len Brown, linux-acpi Yinghai Lu wrote: > Jeremy Fitzhardinge wrote: > >> Ingo Molnar wrote: >> >>> yes, that end result is the desired state of things. We did run with >>> this for several months and resolved all the cases that needed fixing, >>> but dropped them when the ACPI tree moved out from under us. >>> >>> Can resurrect it if Len feels OK about the concept. Len, you shouldnt >>> worry about conflicts - we can do it after the ACPI changes of this >>> merge window are upstream so there should be no conflict trouble at >>> all. How does that sound? >>> >>> >> Doesn't look like these changes made it in this time. Did they get >> overlooked, or did some other problem come up? Or did you want me to >> dig them up? >> >> Thanks, >> J >> > > > please check attached that are updated to today tip/master with ingo's genapic patchset.. > The look OK, but they didn't get merged into tip/master? J ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: state of some x86 acpi patches 2009-02-07 2:58 ` Jeremy Fitzhardinge @ 2009-02-07 3:18 ` Yinghai Lu 2009-02-08 0:09 ` Jeremy Fitzhardinge 0 siblings, 1 reply; 15+ messages in thread From: Yinghai Lu @ 2009-02-07 3:18 UTC (permalink / raw) To: Ingo Molnar Cc: Jeremy Fitzhardinge, Len Brown, linux-acpi, linux-kernel@vger.kernel.org Jeremy Fitzhardinge wrote: > Yinghai Lu wrote: >> Jeremy Fitzhardinge wrote: >> >>> Ingo Molnar wrote: >>> >>>> yes, that end result is the desired state of things. We did run with >>>> this for several months and resolved all the cases that needed fixing, >>>> but dropped them when the ACPI tree moved out from under us. >>>> >>>> Can resurrect it if Len feels OK about the concept. Len, you shouldnt >>>> worry about conflicts - we can do it after the ACPI changes of this >>>> merge window are upstream so there should be no conflict trouble at >>>> all. How does that sound? >>>> >>> Doesn't look like these changes made it in this time. Did they get >>> overlooked, or did some other problem come up? Or did you want me to >>> dig them up? >>> >>> Thanks, >>> J >>> >> >> >> please check attached that are updated to today tip/master with ingo's >> genapic patchset.. >> > > The look OK, but they didn't get merged into tip/master? > Ingo is too busy... It seems Len already agreed those patches can go through tip. Ingo? YH ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: state of some x86 acpi patches 2009-02-07 3:18 ` Yinghai Lu @ 2009-02-08 0:09 ` Jeremy Fitzhardinge 2009-02-09 12:37 ` Ingo Molnar 0 siblings, 1 reply; 15+ messages in thread From: Jeremy Fitzhardinge @ 2009-02-08 0:09 UTC (permalink / raw) To: Yinghai Lu Cc: Ingo Molnar, Len Brown, linux-acpi, linux-kernel@vger.kernel.org Yinghai Lu wrote: > Ingo is too busy... > It seems Len already agreed those patches can go through tip. > OK, I have them prepared as a branch off tip/git pullable from: The following changes since commit 82eda818f26cbef2b0a6bf6580e52645af62e4fd: Ingo Molnar (1): Merge branch 'core/locking' are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git acpi/map Jeremy Fitzhardinge (3): x86: use early_ioremap in __acpi_map_table x86: always explicitly map acpi memory acpi: remove final __acpi_map_table mapping before setting acpi_gbl_permanent_mmap Yinghai Lu (2): acpi/x86: introduce __apci_map_table, v4 revert_fix_es7000_compiling arch/ia64/kernel/acpi.c | 4 ++++ arch/x86/include/asm/acpi.h | 3 --- arch/x86/include/asm/fixmap_32.h | 4 ---- arch/x86/include/asm/fixmap_64.h | 4 ---- arch/x86/kernel/acpi/boot.c | 33 ++++++++------------------------- arch/x86/kernel/es7000_32.c | 9 ++++++++- drivers/acpi/acpica/tbxface.c | 17 ++++++++++++++--- drivers/acpi/osl.c | 11 +++++++++-- drivers/acpi/tables.c | 20 ++++++++++++++------ include/acpi/acpiosxf.h | 1 + include/acpi/acpixf.h | 4 ++++ include/linux/acpi.h | 1 + 12 files changed, 63 insertions(+), 48 deletions(-) J ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: state of some x86 acpi patches 2009-02-08 0:09 ` Jeremy Fitzhardinge @ 2009-02-09 12:37 ` Ingo Molnar 0 siblings, 0 replies; 15+ messages in thread From: Ingo Molnar @ 2009-02-09 12:37 UTC (permalink / raw) To: Jeremy Fitzhardinge, Len Brown Cc: Yinghai Lu, linux-acpi, linux-kernel@vger.kernel.org * Jeremy Fitzhardinge <jeremy@goop.org> wrote: > Yinghai Lu wrote: >> Ingo is too busy... >> It seems Len already agreed those patches can go through tip. >> > > OK, I have them prepared as a branch off tip/git pullable from: > > The following changes since commit 82eda818f26cbef2b0a6bf6580e52645af62e4fd: > Ingo Molnar (1): > Merge branch 'core/locking' > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git acpi/map > > Jeremy Fitzhardinge (3): > x86: use early_ioremap in __acpi_map_table > x86: always explicitly map acpi memory > acpi: remove final __acpi_map_table mapping before setting acpi_gbl_permanent_mmap > > Yinghai Lu (2): > acpi/x86: introduce __apci_map_table, v4 > revert_fix_es7000_compiling > > arch/ia64/kernel/acpi.c | 4 ++++ > arch/x86/include/asm/acpi.h | 3 --- > arch/x86/include/asm/fixmap_32.h | 4 ---- > arch/x86/include/asm/fixmap_64.h | 4 ---- > arch/x86/kernel/acpi/boot.c | 33 ++++++++------------------------- > arch/x86/kernel/es7000_32.c | 9 ++++++++- > drivers/acpi/acpica/tbxface.c | 17 ++++++++++++++--- > drivers/acpi/osl.c | 11 +++++++++-- > drivers/acpi/tables.c | 20 ++++++++++++++------ > include/acpi/acpiosxf.h | 1 + > include/acpi/acpixf.h | 4 ++++ > include/linux/acpi.h | 1 + > 12 files changed, 63 insertions(+), 48 deletions(-) Ok, pulled into tip:x86/acpi, thanks guys! Len: i've added your Ack to the ACPI commits. Ingo ----------------------> commit b825e6cc7b1401862531df497a4a4daff8102ed5 Author: Yinghai Lu <yhlu.kernel@gmail.com> Date: Sat Feb 7 15:39:41 2009 -0800 x86, es7000: fix ACPI table mappings Signed-off-by: Ingo Molnar <mingo@elte.hu> diff --git a/arch/x86/kernel/es7000_32.c b/arch/x86/kernel/es7000_32.c index 53699c9..71d7be6 100644 --- a/arch/x86/kernel/es7000_32.c +++ b/arch/x86/kernel/es7000_32.c @@ -292,24 +292,31 @@ int __init find_unisys_acpi_oem_table(unsigned long *oem_addr) { struct acpi_table_header *header = NULL; int i = 0; + acpi_size tbl_size; - while (ACPI_SUCCESS(acpi_get_table("OEM1", i++, &header))) { + while (ACPI_SUCCESS(acpi_get_table_with_size("OEM1", i++, &header, &tbl_size))) { if (!memcmp((char *) &header->oem_id, "UNISYS", 6)) { struct oem_table *t = (struct oem_table *)header; oem_addrX = t->OEMTableAddr; oem_size = t->OEMTableSize; + early_acpi_os_unmap_memory(header, tbl_size); *oem_addr = (unsigned long)__acpi_map_table(oem_addrX, oem_size); return 0; } + early_acpi_os_unmap_memory(header, tbl_size); } return -1; } void __init unmap_unisys_acpi_oem_table(unsigned long oem_addr) { + if (!oem_addr) + return; + + __acpi_unmap_table((char *)oem_addr, oem_size); } #endif commit 7d97277b754d3ee098a5ec69b6aaafb00c94e2f2 Author: Yinghai Lu <yhlu.kernel@gmail.com> Date: Sat Feb 7 15:39:41 2009 -0800 acpi/x86: introduce __apci_map_table, v4 to prevent wrongly overwriting fixmap that still want to use. ACPI used to rely on low mappings being all linearly mapped and grew a habit: it never really unmapped certain kinds of tables after use. This can cause problems - for example the hypothetical case when some spurious access still references it. v2: remove prev_map and prev_size in __apci_map_table v3: let acpi_os_unmap_memory() call early_iounmap too, so remove extral calling to early_acpi_os_unmap_memory v4: fix typo in one acpi_get_table_with_size calling Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Acked-by: Len Brown <len.brown@intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> diff --git a/arch/ia64/kernel/acpi.c b/arch/ia64/kernel/acpi.c index d541671..2363ed1 100644 --- a/arch/ia64/kernel/acpi.c +++ b/arch/ia64/kernel/acpi.c @@ -199,6 +199,10 @@ char *__init __acpi_map_table(unsigned long phys_addr, unsigned long size) return __va(phys_addr); } +char *__init __acpi_unmap_table(unsigned long virt_addr, unsigned long size) +{ +} + /* -------------------------------------------------------------------------- Boot-time Table Parsing -------------------------------------------------------------------------- */ diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c index 7217834..4c2aaea 100644 --- a/arch/x86/kernel/acpi/boot.c +++ b/arch/x86/kernel/acpi/boot.c @@ -121,21 +121,18 @@ enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_PIC; */ char *__init __acpi_map_table(unsigned long phys, unsigned long size) { - static char *prev_map; - static unsigned long prev_size; - - if (prev_map) { - early_iounmap(prev_map, prev_size); - prev_map = NULL; - } if (!phys || !size) return NULL; - prev_size = size; - prev_map = early_ioremap(phys, size); + return early_ioremap(phys, size); +} +void __init __acpi_unmap_table(char *map, unsigned long size) +{ + if (!map || !size) + return; - return prev_map; + early_iounmap(map, size); } #ifdef CONFIG_PCI_MMCONFIG diff --git a/drivers/acpi/acpica/tbxface.c b/drivers/acpi/acpica/tbxface.c index c3e841f..ab0aff3 100644 --- a/drivers/acpi/acpica/tbxface.c +++ b/drivers/acpi/acpica/tbxface.c @@ -365,7 +365,7 @@ ACPI_EXPORT_SYMBOL(acpi_unload_table_id) /******************************************************************************* * - * FUNCTION: acpi_get_table + * FUNCTION: acpi_get_table_with_size * * PARAMETERS: Signature - ACPI signature of needed table * Instance - Which instance (for SSDTs) @@ -377,8 +377,9 @@ ACPI_EXPORT_SYMBOL(acpi_unload_table_id) * *****************************************************************************/ acpi_status -acpi_get_table(char *signature, - u32 instance, struct acpi_table_header **out_table) +acpi_get_table_with_size(char *signature, + u32 instance, struct acpi_table_header **out_table, + acpi_size *tbl_size) { u32 i; u32 j; @@ -408,6 +409,7 @@ acpi_get_table(char *signature, acpi_tb_verify_table(&acpi_gbl_root_table_list.tables[i]); if (ACPI_SUCCESS(status)) { *out_table = acpi_gbl_root_table_list.tables[i].pointer; + *tbl_size = acpi_gbl_root_table_list.tables[i].length; } if (!acpi_gbl_permanent_mmap) { @@ -420,6 +422,15 @@ acpi_get_table(char *signature, return (AE_NOT_FOUND); } +acpi_status +acpi_get_table(char *signature, + u32 instance, struct acpi_table_header **out_table) +{ + acpi_size tbl_size; + + return acpi_get_table_with_size(signature, + instance, out_table, &tbl_size); +} ACPI_EXPORT_SYMBOL(acpi_get_table) /******************************************************************************* diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c index fb1be7b..765fd1c 100644 --- a/drivers/acpi/bus.c +++ b/drivers/acpi/bus.c @@ -694,12 +694,6 @@ void __init acpi_early_init(void) if (!acpi_strict) acpi_gbl_enable_interpreter_slack = TRUE; - /* - * Doing a zero-sized mapping will clear out the previous - * __acpi_map_table() mapping, if any. - */ - __acpi_map_table(0, 0); - acpi_gbl_permanent_mmap = 1; status = acpi_reallocate_root_table(); diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c index b3193ec..d1dd516 100644 --- a/drivers/acpi/osl.c +++ b/drivers/acpi/osl.c @@ -274,12 +274,19 @@ EXPORT_SYMBOL_GPL(acpi_os_map_memory); void acpi_os_unmap_memory(void __iomem * virt, acpi_size size) { - if (acpi_gbl_permanent_mmap) { + if (acpi_gbl_permanent_mmap) iounmap(virt); - } + else + __acpi_unmap_table(virt, size); } EXPORT_SYMBOL_GPL(acpi_os_unmap_memory); +void early_acpi_os_unmap_memory(void __iomem * virt, acpi_size size) +{ + if (!acpi_gbl_permanent_mmap) + __acpi_unmap_table(virt, size); +} + #ifdef ACPI_FUTURE_USAGE acpi_status acpi_os_get_physical_address(void *virt, acpi_physical_address * phys) diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c index a885295..fec1ae3 100644 --- a/drivers/acpi/tables.c +++ b/drivers/acpi/tables.c @@ -181,14 +181,15 @@ acpi_table_parse_entries(char *id, struct acpi_subtable_header *entry; unsigned int count = 0; unsigned long table_end; + acpi_size tbl_size; if (!handler) return -EINVAL; if (strncmp(id, ACPI_SIG_MADT, 4) == 0) - acpi_get_table(id, acpi_apic_instance, &table_header); + acpi_get_table_with_size(id, acpi_apic_instance, &table_header, &tbl_size); else - acpi_get_table(id, 0, &table_header); + acpi_get_table_with_size(id, 0, &table_header, &tbl_size); if (!table_header) { printk(KERN_WARNING PREFIX "%4.4s not present\n", id); @@ -206,8 +207,10 @@ acpi_table_parse_entries(char *id, table_end) { if (entry->type == entry_id && (!max_entries || count++ < max_entries)) - if (handler(entry, table_end)) + if (handler(entry, table_end)) { + early_acpi_os_unmap_memory((char *)table_header, tbl_size); return -EINVAL; + } entry = (struct acpi_subtable_header *) ((unsigned long)entry + entry->length); @@ -217,6 +220,7 @@ acpi_table_parse_entries(char *id, "%i found\n", id, entry_id, count - max_entries, count); } + early_acpi_os_unmap_memory((char *)table_header, tbl_size); return count; } @@ -241,17 +245,19 @@ acpi_table_parse_madt(enum acpi_madt_type id, int __init acpi_table_parse(char *id, acpi_table_handler handler) { struct acpi_table_header *table = NULL; + acpi_size tbl_size; if (!handler) return -EINVAL; if (strncmp(id, ACPI_SIG_MADT, 4) == 0) - acpi_get_table(id, acpi_apic_instance, &table); + acpi_get_table_with_size(id, acpi_apic_instance, &table, &tbl_size); else - acpi_get_table(id, 0, &table); + acpi_get_table_with_size(id, 0, &table, &tbl_size); if (table) { handler(table); + early_acpi_os_unmap_memory(table, tbl_size); return 0; } else return 1; @@ -265,8 +271,9 @@ int __init acpi_table_parse(char *id, acpi_table_handler handler) static void __init check_multiple_madt(void) { struct acpi_table_header *table = NULL; + acpi_size tbl_size; - acpi_get_table(ACPI_SIG_MADT, 2, &table); + acpi_get_table_with_size(ACPI_SIG_MADT, 2, &table, &tbl_size); if (table) { printk(KERN_WARNING PREFIX "BIOS bug: multiple APIC/MADT found," @@ -275,6 +282,7 @@ static void __init check_multiple_madt(void) "If \"acpi_apic_instance=%d\" works better, " "notify linux-acpi@vger.kernel.org\n", acpi_apic_instance ? 0 : 2); + early_acpi_os_unmap_memory(table, tbl_size); } else acpi_apic_instance = 0; diff --git a/include/acpi/acpiosxf.h b/include/acpi/acpiosxf.h index a62720a..ab0b85c 100644 --- a/include/acpi/acpiosxf.h +++ b/include/acpi/acpiosxf.h @@ -144,6 +144,7 @@ void __iomem *acpi_os_map_memory(acpi_physical_address where, acpi_size length); void acpi_os_unmap_memory(void __iomem * logical_address, acpi_size size); +void early_acpi_os_unmap_memory(void __iomem * virt, acpi_size size); #ifdef ACPI_FUTURE_USAGE acpi_status diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h index c8e8cf4..cc40102 100644 --- a/include/acpi/acpixf.h +++ b/include/acpi/acpixf.h @@ -130,6 +130,10 @@ acpi_get_table_header(acpi_string signature, struct acpi_table_header *out_table_header); acpi_status +acpi_get_table_with_size(acpi_string signature, + u32 instance, struct acpi_table_header **out_table, + acpi_size *tbl_size); +acpi_status acpi_get_table(acpi_string signature, u32 instance, struct acpi_table_header **out_table); diff --git a/include/linux/acpi.h b/include/linux/acpi.h index 6fce2fc..d59f0fa 100644 --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -79,6 +79,7 @@ typedef int (*acpi_table_handler) (struct acpi_table_header *table); typedef int (*acpi_table_entry_handler) (struct acpi_subtable_header *header, const unsigned long end); char * __acpi_map_table (unsigned long phys_addr, unsigned long size); +void __init __acpi_unmap_table(char *map, unsigned long size); int early_acpi_boot_init(void); int acpi_boot_init (void); int acpi_boot_table_init (void); commit 05876f88ed9a66b26af613e222795ae790616252 Author: Jeremy Fitzhardinge <jeremy@goop.org> Date: Sat Feb 7 15:39:40 2009 -0800 acpi: remove final __acpi_map_table mapping before setting acpi_gbl_permanent_mmap On x86, __acpi_map_table uses early_ioremap() to create the mapping, replacing the previous mapping with a new one. Once enough of the kernel is up an running it switches to using normal ioremap(). At that point, we need to clean up the final mapping to avoid a warning from the early_ioremap subsystem. This can be removed after all the instances in the ACPI code are fixed that rely on early-ioremap's implicit overmapping of previously mapped tables. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Acked-by: Len Brown <len.brown@intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c index 5424a18..7217834 100644 --- a/arch/x86/kernel/acpi/boot.c +++ b/arch/x86/kernel/acpi/boot.c @@ -124,12 +124,14 @@ char *__init __acpi_map_table(unsigned long phys, unsigned long size) static char *prev_map; static unsigned long prev_size; + if (prev_map) { + early_iounmap(prev_map, prev_size); + prev_map = NULL; + } + if (!phys || !size) return NULL; - if (prev_map) - early_iounmap(prev_map, prev_size); - prev_size = size; prev_map = early_ioremap(phys, size); diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c index 765fd1c..fb1be7b 100644 --- a/drivers/acpi/bus.c +++ b/drivers/acpi/bus.c @@ -694,6 +694,12 @@ void __init acpi_early_init(void) if (!acpi_strict) acpi_gbl_enable_interpreter_slack = TRUE; + /* + * Doing a zero-sized mapping will clear out the previous + * __acpi_map_table() mapping, if any. + */ + __acpi_map_table(0, 0); + acpi_gbl_permanent_mmap = 1; status = acpi_reallocate_root_table(); commit eecb9a697f0b790e5840dae8a8b866bea49a86ee Author: Jeremy Fitzhardinge <jeremy@goop.org> Date: Sat Feb 7 15:39:38 2009 -0800 x86: always explicitly map acpi memory Always map acpi tables, rather than assuming we can use the normal linear mapping to access the acpi tables. This is necessary in a virtual environment where the linear mappings are to pseudo-physical memory, but the acpi tables exist at a real physical address. It doesn't hurt to map in the normal non-virtual case, so just do it unconditionally. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Acked-by: Len Brown <len.brown@intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c index c518599..5424a18 100644 --- a/arch/x86/kernel/acpi/boot.c +++ b/arch/x86/kernel/acpi/boot.c @@ -127,9 +127,6 @@ char *__init __acpi_map_table(unsigned long phys, unsigned long size) if (!phys || !size) return NULL; - if (phys+size <= (max_low_pfn_mapped << PAGE_SHIFT)) - return __va(phys); - if (prev_map) early_iounmap(prev_map, prev_size); commit 1c14fa4937eb73509e07ac12bf8db1fdf4c42a59 Author: Jeremy Fitzhardinge <jeremy@goop.org> Date: Sat Feb 7 15:39:38 2009 -0800 x86: use early_ioremap in __acpi_map_table __acpi_map_table() effectively reimplements early_ioremap(). Rather than have that duplication, just implement it in terms of early_ioremap(). However, unlike early_ioremap(), __acpi_map_table() just maintains a single mapping which gets replaced each call, and has no corresponding unmap function. Implement this by just removing the previous mapping each time its called. Unfortunately, this will leave a stray mapping at the end. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h index 9830681..4518dc5 100644 --- a/arch/x86/include/asm/acpi.h +++ b/arch/x86/include/asm/acpi.h @@ -102,9 +102,6 @@ static inline void disable_acpi(void) acpi_noirq = 1; } -/* Fixmap pages to reserve for ACPI boot-time tables (see fixmap.h) */ -#define FIX_ACPI_PAGES 4 - extern int acpi_gsi_to_irq(u32 gsi, unsigned int *irq); static inline void acpi_noirq_set(void) { acpi_noirq = 1; } diff --git a/arch/x86/include/asm/fixmap_32.h b/arch/x86/include/asm/fixmap_32.h index c7115c1..047d9ba 100644 --- a/arch/x86/include/asm/fixmap_32.h +++ b/arch/x86/include/asm/fixmap_32.h @@ -95,10 +95,6 @@ enum fixed_addresses { (__end_of_permanent_fixed_addresses & 255), FIX_BTMAP_BEGIN = FIX_BTMAP_END + NR_FIX_BTMAPS*FIX_BTMAPS_SLOTS - 1, FIX_WP_TEST, -#ifdef CONFIG_ACPI - FIX_ACPI_BEGIN, - FIX_ACPI_END = FIX_ACPI_BEGIN + FIX_ACPI_PAGES - 1, -#endif #ifdef CONFIG_PROVIDE_OHCI1394_DMA_INIT FIX_OHCI1394_BASE, #endif diff --git a/arch/x86/include/asm/fixmap_64.h b/arch/x86/include/asm/fixmap_64.h index 00a30ab..298d9ba 100644 --- a/arch/x86/include/asm/fixmap_64.h +++ b/arch/x86/include/asm/fixmap_64.h @@ -50,10 +50,6 @@ enum fixed_addresses { FIX_PARAVIRT_BOOTMAP, #endif __end_of_permanent_fixed_addresses, -#ifdef CONFIG_ACPI - FIX_ACPI_BEGIN, - FIX_ACPI_END = FIX_ACPI_BEGIN + FIX_ACPI_PAGES - 1, -#endif #ifdef CONFIG_PROVIDE_OHCI1394_DMA_INIT FIX_OHCI1394_BASE, #endif diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c index d37593c..c518599 100644 --- a/arch/x86/kernel/acpi/boot.c +++ b/arch/x86/kernel/acpi/boot.c @@ -121,8 +121,8 @@ enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_PIC; */ char *__init __acpi_map_table(unsigned long phys, unsigned long size) { - unsigned long base, offset, mapped_size; - int idx; + static char *prev_map; + static unsigned long prev_size; if (!phys || !size) return NULL; @@ -130,26 +130,13 @@ char *__init __acpi_map_table(unsigned long phys, unsigned long size) if (phys+size <= (max_low_pfn_mapped << PAGE_SHIFT)) return __va(phys); - offset = phys & (PAGE_SIZE - 1); - mapped_size = PAGE_SIZE - offset; - clear_fixmap(FIX_ACPI_END); - set_fixmap(FIX_ACPI_END, phys); - base = fix_to_virt(FIX_ACPI_END); + if (prev_map) + early_iounmap(prev_map, prev_size); - /* - * Most cases can be covered by the below. - */ - idx = FIX_ACPI_END; - while (mapped_size < size) { - if (--idx < FIX_ACPI_BEGIN) - return NULL; /* cannot handle this */ - phys += PAGE_SIZE; - clear_fixmap(idx); - set_fixmap(idx, phys); - mapped_size += PAGE_SIZE; - } + prev_size = size; + prev_map = early_ioremap(phys, size); - return ((unsigned char *)base + offset); + return prev_map; } #ifdef CONFIG_PCI_MMCONFIG ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: state of some x86 acpi patches 2008-12-16 19:19 state of some x86 acpi patches Jeremy Fitzhardinge 2008-12-16 19:25 ` Ingo Molnar @ 2008-12-18 13:44 ` Andi Kleen 2008-12-18 19:46 ` Jeremy Fitzhardinge 1 sibling, 1 reply; 15+ messages in thread From: Andi Kleen @ 2008-12-18 13:44 UTC (permalink / raw) To: Jeremy Fitzhardinge; +Cc: Brown, Len, Yinghai Lu, linux-acpi, Ingo Molnar Jeremy Fitzhardinge <jeremy@goop.org> writes: > > However, unlike early_ioremap(), __acpi_map_table just maintains a > single mapping which gets replaced each call, and has no corresponding > unmap function. Implement this by just removing the previous mapping > each time its called. Unfortunately, this will leave a stray mapping > at the end. Stray mappings are dangerous. They can lead to illegal cache aliases later. Better avoid them. I guess ACPI could call a cleanup function after it's done with all early mappings. -Andi -- ak@linux.intel.com ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: state of some x86 acpi patches 2008-12-18 13:44 ` Andi Kleen @ 2008-12-18 19:46 ` Jeremy Fitzhardinge 2008-12-18 21:47 ` Ingo Molnar 0 siblings, 1 reply; 15+ messages in thread From: Jeremy Fitzhardinge @ 2008-12-18 19:46 UTC (permalink / raw) To: Andi Kleen; +Cc: Brown, Len, Yinghai Lu, linux-acpi, Ingo Molnar Andi Kleen wrote: > Jeremy Fitzhardinge <jeremy@goop.org> writes: > >> However, unlike early_ioremap(), __acpi_map_table just maintains a >> single mapping which gets replaced each call, and has no corresponding >> unmap function. Implement this by just removing the previous mapping >> each time its called. Unfortunately, this will leave a stray mapping >> at the end. >> > > Stray mappings are dangerous. They can lead to illegal cache aliases > later. Better avoid them. > > I guess ACPI could call a cleanup function after it's done with > all early mappings. > Right. But Yinghai (I think) went through and made all the acpi mappings get properly mapped and unmapped, so my patch is moot. J ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: state of some x86 acpi patches 2008-12-18 19:46 ` Jeremy Fitzhardinge @ 2008-12-18 21:47 ` Ingo Molnar 0 siblings, 0 replies; 15+ messages in thread From: Ingo Molnar @ 2008-12-18 21:47 UTC (permalink / raw) To: Jeremy Fitzhardinge; +Cc: Andi Kleen, Brown, Len, Yinghai Lu, linux-acpi * Jeremy Fitzhardinge <jeremy@goop.org> wrote: > Andi Kleen wrote: >> Jeremy Fitzhardinge <jeremy@goop.org> writes: >> >>> However, unlike early_ioremap(), __acpi_map_table just maintains a >>> single mapping which gets replaced each call, and has no corresponding >>> unmap function. Implement this by just removing the previous mapping >>> each time its called. Unfortunately, this will leave a stray mapping >>> at the end. >>> >> >> Stray mappings are dangerous. They can lead to illegal cache aliases >> later. Better avoid them. >> >> I guess ACPI could call a cleanup function after it's done with >> all early mappings. >> > > Right. But Yinghai (I think) went through and made all the acpi > mappings get properly mapped and unmapped, so my patch is moot. yes, right. Ingo ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2009-02-09 12:37 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-12-16 19:19 state of some x86 acpi patches Jeremy Fitzhardinge 2008-12-16 19:25 ` Ingo Molnar 2008-12-31 23:38 ` Len Brown 2009-01-01 6:49 ` Jeremy Fitzhardinge 2009-01-02 15:39 ` Ingo Molnar 2009-01-02 22:28 ` Len Brown 2009-01-28 23:45 ` Jeremy Fitzhardinge 2009-01-29 1:10 ` Yinghai Lu 2009-02-07 2:58 ` Jeremy Fitzhardinge 2009-02-07 3:18 ` Yinghai Lu 2009-02-08 0:09 ` Jeremy Fitzhardinge 2009-02-09 12:37 ` Ingo Molnar 2008-12-18 13:44 ` Andi Kleen 2008-12-18 19:46 ` Jeremy Fitzhardinge 2008-12-18 21:47 ` Ingo Molnar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox