Re: [Xen-devel] [PATCH v4 05/10] acpi: Refactor acpi_os_map_memory to be architecturally independent

2016-01-22 Thread Shannon Zhao 


On 2016/1/22 16:47, Jan Beulich wrote:
 On 22.01.16 at 09:38,  wrote:
>> > 
>> > On 2016/1/18 21:33, Jan Beulich wrote:
>> > On 16.01.16 at 06:01,  wrote:
> >>> > --- a/xen/drivers/acpi/osl.c
> >>> > +++ b/xen/drivers/acpi/osl.c
> >>> > @@ -86,17 +86,7 @@ acpi_physical_address __init 
>> > acpi_os_get_root_pointer(void)
> >>> >  void __iomem *
> >>> >  acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
> >>> >  {
> >>> > -   if (system_state >= SYS_STATE_active) {
> >>> > -   mfn_t mfn = _mfn(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_UP(offs + size), 1, 1,
> >>> > - PAGE_HYPERVISOR_NOCACHE) + offs;
> >>> > -   }
> >>> > -   return __acpi_map_table(phys, size);
> >>> > +   return arch_acpi_os_map_memory(phys, size);
> >>> >  }
>>> >> I'm quite sure I've said before that this goes too far: The __vmap()
>>> >> part and likely also the early-boot __acpi_map_table() one already
>>> >> are architecture independent and hence should stay. The factoring
>>> >> hence should only concern the first Mb handling and maybe the
>>> >> the mapping attributes passed to __vmap().
>> > 
>> > Yes, the first MB handling and __vmap() should refactor. So if it only
>> > moves them to an architecture function, how about below patch?
>> > 
>> > diff --git a/xen/arch/x86/acpi/lib.c b/xen/arch/x86/acpi/lib.c
>> > index cc15ea3..5885a3a 100644
>> > --- a/xen/arch/x86/acpi/lib.c
>> > +++ b/xen/arch/x86/acpi/lib.c
>> > @@ -33,6 +33,19 @@ u8 __read_mostly acpi_disable_value;
>> >  u32 __read_mostly x86_acpiid_to_apicid[MAX_MADT_ENTRIES] =
>> >  {[0 ... MAX_MADT_ENTRIES - 1] = BAD_APICID };
>> > 
>> > +void __iomem *
>> > +arch_acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
>> > +{
>> > +   mfn_t mfn = _mfn(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_UP(offs + size), 1, 1,
>> > + PAGE_HYPERVISOR_NOCACHE) + offs;
>> > +}
> Well, I had clearly said the vmap() part is generic; if there's
> anything architecture dependent here, then the mapping
> attributes (and hence only _those_ should be factored out,
> not the entire function invocation).
I know what you said. But how can we change the attribute for ARM in
acpi_os_map_memory() without moving these codes out?

Thanks,
-- 
Shannon


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

Re: [Xen-devel] [PATCH v4 05/10] acpi: Refactor acpi_os_map_memory to be architecturally independent

2016-01-22 Thread Jan Beulich 
>>> On 22.01.16 at 10:37,  wrote:

> 
> On 2016/1/22 16:47, Jan Beulich wrote:
> On 22.01.16 at 09:38,  wrote:
>>> > 
>>> > On 2016/1/18 21:33, Jan Beulich wrote:
>>> > On 16.01.16 at 06:01,  wrote:
>> >>> > --- a/xen/drivers/acpi/osl.c
>> >>> > +++ b/xen/drivers/acpi/osl.c
>> >>> > @@ -86,17 +86,7 @@ acpi_physical_address __init 
>>> > acpi_os_get_root_pointer(void)
>> >>> >  void __iomem *
>> >>> >  acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
>> >>> >  {
>> >>> > -  if (system_state >= SYS_STATE_active) {
>> >>> > -  mfn_t mfn = _mfn(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_UP(offs + size), 1, 1,
>> >>> > -PAGE_HYPERVISOR_NOCACHE) + offs;
>> >>> > -  }
>> >>> > -  return __acpi_map_table(phys, size);
>> >>> > +  return arch_acpi_os_map_memory(phys, size);
>> >>> >  }
 >> I'm quite sure I've said before that this goes too far: The __vmap()
 >> part and likely also the early-boot __acpi_map_table() one already
 >> are architecture independent and hence should stay. The factoring
 >> hence should only concern the first Mb handling and maybe the
 >> the mapping attributes passed to __vmap().
>>> > 
>>> > Yes, the first MB handling and __vmap() should refactor. So if it only
>>> > moves them to an architecture function, how about below patch?
>>> > 
>>> > diff --git a/xen/arch/x86/acpi/lib.c b/xen/arch/x86/acpi/lib.c
>>> > index cc15ea3..5885a3a 100644
>>> > --- a/xen/arch/x86/acpi/lib.c
>>> > +++ b/xen/arch/x86/acpi/lib.c
>>> > @@ -33,6 +33,19 @@ u8 __read_mostly acpi_disable_value;
>>> >  u32 __read_mostly x86_acpiid_to_apicid[MAX_MADT_ENTRIES] =
>>> >  {[0 ... MAX_MADT_ENTRIES - 1] = BAD_APICID };
>>> > 
>>> > +void __iomem *
>>> > +arch_acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
>>> > +{
>>> > +   mfn_t mfn = _mfn(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_UP(offs + size), 1, 1,
>>> > + PAGE_HYPERVISOR_NOCACHE) + offs;
>>> > +}
>> Well, I had clearly said the vmap() part is generic; if there's
>> anything architecture dependent here, then the mapping
>> attributes (and hence only _those_ should be factored out,
>> not the entire function invocation).
> I know what you said. But how can we change the attribute for ARM in
> acpi_os_map_memory() without moving these codes out?

By having each arch #define their value, and use that constant here?

Jan


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

Re: [Xen-devel] [PATCH v4 05/10] acpi: Refactor acpi_os_map_memory to be architecturally independent

2016-01-22 Thread Shannon Zhao 


On 2016/1/18 21:33, Jan Beulich wrote:
 On 16.01.16 at 06:01,  wrote:
>> > --- a/xen/drivers/acpi/osl.c
>> > +++ b/xen/drivers/acpi/osl.c
>> > @@ -86,17 +86,7 @@ acpi_physical_address __init 
>> > acpi_os_get_root_pointer(void)
>> >  void __iomem *
>> >  acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
>> >  {
>> > -  if (system_state >= SYS_STATE_active) {
>> > -  mfn_t mfn = _mfn(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_UP(offs + size), 1, 1,
>> > -PAGE_HYPERVISOR_NOCACHE) + offs;
>> > -  }
>> > -  return __acpi_map_table(phys, size);
>> > +  return arch_acpi_os_map_memory(phys, size);
>> >  }
> I'm quite sure I've said before that this goes too far: The __vmap()
> part and likely also the early-boot __acpi_map_table() one already
> are architecture independent and hence should stay. The factoring
> hence should only concern the first Mb handling and maybe the
> the mapping attributes passed to __vmap().

Yes, the first MB handling and __vmap() should refactor. So if it only
moves them to an architecture function, how about below patch?

diff --git a/xen/arch/x86/acpi/lib.c b/xen/arch/x86/acpi/lib.c
index cc15ea3..5885a3a 100644
--- a/xen/arch/x86/acpi/lib.c
+++ b/xen/arch/x86/acpi/lib.c
@@ -33,6 +33,19 @@ u8 __read_mostly acpi_disable_value;
 u32 __read_mostly x86_acpiid_to_apicid[MAX_MADT_ENTRIES] =
 {[0 ... MAX_MADT_ENTRIES - 1] = BAD_APICID };

+void __iomem *
+arch_acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
+{
+   mfn_t mfn = _mfn(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_UP(offs + size), 1, 1,
+ PAGE_HYPERVISOR_NOCACHE) + offs;
+}
+
 /*
  * Important Safety Note:  The fixed ACPI page numbers are *subtracted*
  * from the fixed base.  That's why we start at FIX_ACPI_END and
diff --git a/xen/drivers/acpi/osl.c b/xen/drivers/acpi/osl.c
index a2fc8c4..e2dda2e 100644
--- a/xen/drivers/acpi/osl.c
+++ b/xen/drivers/acpi/osl.c
@@ -88,16 +88,8 @@ acpi_physical_address __init
acpi_os_get_root_pointer(void)
 void __iomem *
 acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
 {
-   if (system_state >= SYS_STATE_active) {
-   mfn_t mfn = _mfn(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_UP(offs + size), 1, 1,
- PAGE_HYPERVISOR_NOCACHE) + offs;
-   }
+   if (system_state >= SYS_STATE_active)
+   return arch_acpi_os_map_memory(phys, size);
return __acpi_map_table(phys, size);
 }


-- 
Shannon


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

Re: [Xen-devel] [PATCH v4 05/10] acpi: Refactor acpi_os_map_memory to be architecturally independent

2016-01-22 Thread Jan Beulich 
>>> On 22.01.16 at 09:38,  wrote:

> 
> On 2016/1/18 21:33, Jan Beulich wrote:
> On 16.01.16 at 06:01,  wrote:
>>> > --- a/xen/drivers/acpi/osl.c
>>> > +++ b/xen/drivers/acpi/osl.c
>>> > @@ -86,17 +86,7 @@ acpi_physical_address __init 
> acpi_os_get_root_pointer(void)
>>> >  void __iomem *
>>> >  acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
>>> >  {
>>> > - if (system_state >= SYS_STATE_active) {
>>> > - mfn_t mfn = _mfn(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_UP(offs + size), 1, 1,
>>> > -   PAGE_HYPERVISOR_NOCACHE) + offs;
>>> > - }
>>> > - return __acpi_map_table(phys, size);
>>> > + return arch_acpi_os_map_memory(phys, size);
>>> >  }
>> I'm quite sure I've said before that this goes too far: The __vmap()
>> part and likely also the early-boot __acpi_map_table() one already
>> are architecture independent and hence should stay. The factoring
>> hence should only concern the first Mb handling and maybe the
>> the mapping attributes passed to __vmap().
> 
> Yes, the first MB handling and __vmap() should refactor. So if it only
> moves them to an architecture function, how about below patch?
> 
> diff --git a/xen/arch/x86/acpi/lib.c b/xen/arch/x86/acpi/lib.c
> index cc15ea3..5885a3a 100644
> --- a/xen/arch/x86/acpi/lib.c
> +++ b/xen/arch/x86/acpi/lib.c
> @@ -33,6 +33,19 @@ u8 __read_mostly acpi_disable_value;
>  u32 __read_mostly x86_acpiid_to_apicid[MAX_MADT_ENTRIES] =
>  {[0 ... MAX_MADT_ENTRIES - 1] = BAD_APICID };
> 
> +void __iomem *
> +arch_acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
> +{
> +   mfn_t mfn = _mfn(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_UP(offs + size), 1, 1,
> + PAGE_HYPERVISOR_NOCACHE) + offs;
> +}

Well, I had clearly said the vmap() part is generic; if there's
anything architecture dependent here, then the mapping
attributes (and hence only _those_ should be factored out,
not the entire function invocation).

Jan


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

Re: [Xen-devel] [PATCH v4 05/10] acpi: Refactor acpi_os_map_memory to be architecturally independent

2016-01-22 Thread Jan Beulich 
>>> On 22.01.16 at 12:55,  wrote:

> 
> On 2016/1/22 18:15, Jan Beulich wrote:
> On 22.01.16 at 10:37,  wrote:
>>> >
>>> >On 2016/1/22 16:47, Jan Beulich wrote:
>>> >On 22.01.16 at 09:38,  wrote:
>> >>> >
>> >>> >On 2016/1/18 21:33, Jan Beulich wrote:
>> >>> >On 16.01.16 at 06:01,  
>> >>> >wrote:
 >> >>> >--- a/xen/drivers/acpi/osl.c
 >> >>> >+++ b/xen/drivers/acpi/osl.c
 >> >>> >@@ -86,17 +86,7 @@ acpi_physical_address __init
>> >>> >acpi_os_get_root_pointer(void)
 >> >>> >  void __iomem *
 >> >>> >  acpi_os_map_memory(acpi_physical_address phys, 
 >> >>> > acpi_size size)
 >> >>> >  {
 >> >>> >-  if (system_state >= SYS_STATE_active) {
 >> >>> >-  mfn_t mfn = _mfn(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_UP(offs + 
 >> >>> >size), 1, 1,
 >> >>> >-PAGE_HYPERVISOR_NOCACHE) 
 >> >>> >+ offs;
 >> >>> >-  }
 >> >>> >-  return __acpi_map_table(phys, size);
 >> >>> >+  return arch_acpi_os_map_memory(phys, size);
 >> >>> >  }
  >>I'm quite sure I've said before that this goes too far: The 
  >>__vmap()
  >>part and likely also the early-boot __acpi_map_table() one 
  >>already
  >>are architecture independent and hence should stay. The 
  >>factoring
  >>hence should only concern the first Mb handling and maybe the
  >>the mapping attributes passed to __vmap().
>> >>> >
>> >>> >Yes, the first MB handling and __vmap() should refactor. So if it 
>> >>> >only
>> >>> >moves them to an architecture function, how about below patch?
>> >>> >
>> >>> >diff --git a/xen/arch/x86/acpi/lib.c b/xen/arch/x86/acpi/lib.c
>> >>> >index cc15ea3..5885a3a 100644
>> >>> >--- a/xen/arch/x86/acpi/lib.c
>> >>> >+++ b/xen/arch/x86/acpi/lib.c
>> >>> >@@ -33,6 +33,19 @@ u8 __read_mostly acpi_disable_value;
>> >>> >  u32 __read_mostly x86_acpiid_to_apicid[MAX_MADT_ENTRIES] =
>> >>> >  {[0 ... MAX_MADT_ENTRIES - 1] = BAD_APICID };
>> >>> >
>> >>> >+void __iomem *
>> >>> >+arch_acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
>> >>> >+{
>> >>> >+   mfn_t mfn = _mfn(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_UP(offs + size), 1, 1,
>> >>> >+ PAGE_HYPERVISOR_NOCACHE) + offs;
>> >>> >+}
 >>Well, I had clearly said the vmap() part is generic; if there's
 >>anything architecture dependent here, then the mapping
 >>attributes (and hence only_those_  should be factored out,
 >>not the entire function invocation).
>>> >I know what you said. But how can we change the attribute for ARM in
>>> >acpi_os_map_memory() without moving these codes out?
>> By having each arch #define their value, and use that constant here?
> You really want that?

Yes.

Jan


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

Re: [Xen-devel] [PATCH v4 05/10] acpi: Refactor acpi_os_map_memory to be architecturally independent

2016-01-22 Thread Shannon Zhao 



On 2016/1/22 18:15, Jan Beulich wrote:

On 22.01.16 at 10:37,  wrote:

>
>On 2016/1/22 16:47, Jan Beulich wrote:

>On 22.01.16 at 09:38,  wrote:

>>> >
>>> >On 2016/1/18 21:33, Jan Beulich wrote:

>>> >On 16.01.16 at 06:01,  wrote:

>> >>> >--- a/xen/drivers/acpi/osl.c
>> >>> >+++ b/xen/drivers/acpi/osl.c
>> >>> >@@ -86,17 +86,7 @@ acpi_physical_address __init

>>> >acpi_os_get_root_pointer(void)

>> >>> >  void __iomem *
>> >>> >  acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
>> >>> >  {
>> >>> >- if (system_state >= SYS_STATE_active) {
>> >>> >- mfn_t mfn = _mfn(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_UP(offs + size), 1, 1,
>> >>> >-   PAGE_HYPERVISOR_NOCACHE) + offs;
>> >>> >- }
>> >>> >- return __acpi_map_table(phys, size);
>> >>> >+ return arch_acpi_os_map_memory(phys, size);
>> >>> >  }

 >>I'm quite sure I've said before that this goes too far: The __vmap()
 >>part and likely also the early-boot __acpi_map_table() one already
 >>are architecture independent and hence should stay. The factoring
 >>hence should only concern the first Mb handling and maybe the
 >>the mapping attributes passed to __vmap().

>>> >
>>> >Yes, the first MB handling and __vmap() should refactor. So if it only
>>> >moves them to an architecture function, how about below patch?
>>> >
>>> >diff --git a/xen/arch/x86/acpi/lib.c b/xen/arch/x86/acpi/lib.c
>>> >index cc15ea3..5885a3a 100644
>>> >--- a/xen/arch/x86/acpi/lib.c
>>> >+++ b/xen/arch/x86/acpi/lib.c
>>> >@@ -33,6 +33,19 @@ u8 __read_mostly acpi_disable_value;
>>> >  u32 __read_mostly x86_acpiid_to_apicid[MAX_MADT_ENTRIES] =
>>> >  {[0 ... MAX_MADT_ENTRIES - 1] = BAD_APICID };
>>> >
>>> >+void __iomem *
>>> >+arch_acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
>>> >+{
>>> >+   mfn_t mfn = _mfn(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_UP(offs + size), 1, 1,
>>> >+ PAGE_HYPERVISOR_NOCACHE) + offs;
>>> >+}

>>Well, I had clearly said the vmap() part is generic; if there's
>>anything architecture dependent here, then the mapping
>>attributes (and hence only_those_  should be factored out,
>>not the entire function invocation).

>I know what you said. But how can we change the attribute for ARM in
>acpi_os_map_memory() without moving these codes out?

By having each arch #define their value, and use that constant here?
You really want that? Even though the way here I use is not too many 
dunplicated codes (and I think it looks clearer).


--
Shannon

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

Re: [Xen-devel] [PATCH v4 05/10] acpi: Refactor acpi_os_map_memory to be architecturally independent

2016-01-18 Thread Jan Beulich 
>>> On 16.01.16 at 06:01,  wrote:
> --- a/xen/drivers/acpi/osl.c
> +++ b/xen/drivers/acpi/osl.c
> @@ -86,17 +86,7 @@ acpi_physical_address __init acpi_os_get_root_pointer(void)
>  void __iomem *
>  acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
>  {
> - if (system_state >= SYS_STATE_active) {
> - mfn_t mfn = _mfn(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_UP(offs + size), 1, 1,
> -   PAGE_HYPERVISOR_NOCACHE) + offs;
> - }
> - return __acpi_map_table(phys, size);
> + return arch_acpi_os_map_memory(phys, size);
>  }

I'm quite sure I've said before that this goes too far: The __vmap()
part and likely also the early-boot __acpi_map_table() one already
are architecture independent and hence should stay. The factoring
hence should only concern the first Mb handling and maybe the
the mapping attributes passed to __vmap().

Jan


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

[Xen-devel] [PATCH v4 05/10] acpi: Refactor acpi_os_map_memory to be architecturally independent

2016-01-15 Thread Shannon Zhao 
From: Shannon Zhao 

Current acpi_os_map_memory is specific to x86. Refactor it to be
architecturally independent.

Cc: Jan Beulich 
Signed-off-by: Shannon Zhao 
Acked-by: Stefano Stabellini 
---
 xen/arch/x86/acpi/lib.c | 16 
 xen/drivers/acpi/osl.c  | 12 +---
 xen/include/xen/acpi.h  |  2 ++
 3 files changed, 19 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/acpi/lib.c b/xen/arch/x86/acpi/lib.c
index cc15ea3..1e2e124 100644
--- a/xen/arch/x86/acpi/lib.c
+++ b/xen/arch/x86/acpi/lib.c
@@ -33,6 +33,22 @@ u8 __read_mostly acpi_disable_value;
 u32 __read_mostly x86_acpiid_to_apicid[MAX_MADT_ENTRIES] =
 {[0 ... MAX_MADT_ENTRIES - 1] = BAD_APICID };
 
+void __iomem *
+arch_acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
+{
+   if (system_state >= SYS_STATE_active) {
+   mfn_t mfn = _mfn(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_UP(offs + size), 1, 1,
+ PAGE_HYPERVISOR_NOCACHE) + offs;
+   }
+   return __acpi_map_table(phys, size);
+}
+
 /*
  * Important Safety Note:  The fixed ACPI page numbers are *subtracted*
  * from the fixed base.  That's why we start at FIX_ACPI_END and
diff --git a/xen/drivers/acpi/osl.c b/xen/drivers/acpi/osl.c
index ce15470..dc971af 100644
--- a/xen/drivers/acpi/osl.c
+++ b/xen/drivers/acpi/osl.c
@@ -86,17 +86,7 @@ acpi_physical_address __init acpi_os_get_root_pointer(void)
 void __iomem *
 acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
 {
-   if (system_state >= SYS_STATE_active) {
-   mfn_t mfn = _mfn(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_UP(offs + size), 1, 1,
- PAGE_HYPERVISOR_NOCACHE) + offs;
-   }
-   return __acpi_map_table(phys, size);
+   return arch_acpi_os_map_memory(phys, size);
 }
 
 void acpi_os_unmap_memory(void __iomem * virt, acpi_size size)
diff --git a/xen/include/xen/acpi.h b/xen/include/xen/acpi.h
index 65e53a6..9d90d6b 100644
--- a/xen/include/xen/acpi.h
+++ b/xen/include/xen/acpi.h
@@ -54,6 +54,8 @@ 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);
 
+void __iomem *
+arch_acpi_os_map_memory(acpi_physical_address phys, acpi_size size);
 unsigned int acpi_get_processor_id (unsigned int cpu);
 char * __acpi_map_table (paddr_t phys_addr, unsigned long size);
 int acpi_boot_init (void);
-- 
2.0.4



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