[PATCH] to fix ACPI slit table access at runtime

[PATCH] to fix ACPI slit table access at runtime

[Kamble, Nitin A]

[-- Attachment #1.1: Type: text/plain, Size: 2696 bytes --]

Hi Keir,
  I was noticing that the current Xen code was not able to access the ACPI SLIT data (node to node distance) at runtime. And I found root cause of it being the acpi_slit pointer not being valid at runtime.
I have fixed the issue by saving the slit table data at boot time, and using the saved data for runtime access as follows.

Please accept or comment.
Thanks & Regards,
Nitin

Signed-Off-By: Nitin A Kamble <nitin.a.kamble@intel.com>

diff -r b474725a242b xen/arch/x86/srat.c
--- a/xen/arch/x86/srat.c             Thu Feb 25 07:50:38 2010 -0800
+++ b/xen/arch/x86/srat.c          Thu Feb 25 08:02:36 2010 -0800
@@ -20,13 +20,15 @@
 #include <asm/e820.h>
 #include <asm/page.h>

-static struct acpi_table_slit *__read_mostly acpi_slit;
-
 static nodemask_t nodes_parsed __initdata;
 static nodemask_t nodes_found __initdata;
 static struct node nodes[MAX_NUMNODES] __initdata;
 static u8 __read_mostly pxm2node[256] = { [0 ... 255] = 0xff };

+static struct {
+             struct acpi_table_slit slit_table;
+             u8 entries[MAX_NUMNODES * MAX_NUMNODES];
+} acpi_slit;

 static int num_node_memblks;
 static struct node node_memblk_range[NR_NODE_MEMBLKS];
@@ -144,7 +146,8 @@
                                printk(KERN_INFO "ACPI: SLIT table looks invalid. Not used.\n");
                                return;
                }
-              acpi_slit = slit;
+
+             memcpy(&acpi_slit, slit, slit->header.length);
 }

 /* Callback for Proximity Domain -> LAPIC mapping */
@@ -424,10 +427,10 @@
 {
                int index;

-              if (!acpi_slit)
+             if (!acpi_slit.slit_table.header.length)
                                return a == b ? 10 : 20;
-              index = acpi_slit->locality_count * node_to_pxm(a);
-              return acpi_slit->entry[index + node_to_pxm(b)];
+             index = acpi_slit.slit_table.locality_count * node_to_pxm(a);
+             return  acpi_slit.slit_table.entry[index + node_to_pxm(b)];
 }

 EXPORT_SYMBOL(__node_distance);
diff -r b474725a242b xen/include/acpi/actbl1.h
--- a/xen/include/acpi/actbl1.h Thu Feb 25 07:50:38 2010 -0800
+++ b/xen/include/acpi/actbl1.h              Thu Feb 25 08:02:36 2010 -0800
@@ -573,7 +573,7 @@
 struct acpi_table_slit {
                struct acpi_table_header header;            /* Common ACPI table header */
                u64 locality_count;
-              u8 entry[1];                        /* Real size = localities^2 */
+             u8 entry[0];                        /* Real size = localities^2 */
 };

 /*******************************************************************************

[-- Attachment #1.2: Type: text/html, Size: 8798 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: [PATCH] to fix ACPI slit table access at runtime

[Keir Fraser]

On 25/02/2010 00:06, "Kamble, Nitin A" <nitin.a.kamble@intel.com> wrote:

> Hi Keir,
>   I was noticing that the current Xen code was not able to access the ACPI
> SLIT data (node to node distance) at runtime. And I found root cause of it
> being the acpi_slit pointer not being valid at runtime.
> I have fixed the issue by saving the slit table data at boot time, and using
> the saved data for runtime access as follows.

Better would be to dynamically alloc_boot_pages(). Then also the patch would
be about two or three lines. The only disadvantage would be that then SLIT
parsing would be for 64-bit hypervisor only (since 32-bit Xen does not have
mappings for bootmem). I think we can live with that - I note that Linux
only does SLIT parsing for x86_64 too.

By the way, a separate question for Jan: I notice you added an
alloc_boot_pages() call in arch/x86/numa.c, and get a virtual address from
mfn_to_virt(). This is bogus for x86_32, so can we just stub out that
function for the 32-bit build: looks like the caller would then gracefully
fail? I wonder whether this could explain the crash that Ian Jackson
reported on one system with PAE Xen the other day.

 -- Keir

> Please accept or comment.
> Thanks & Regards,
> Nitin
>  
> Signed-Off-By: Nitin A Kamble <nitin.a.kamble@intel.com>
>  
> diff -r b474725a242b xen/arch/x86/srat.c
> --- a/xen/arch/x86/srat.c             Thu Feb 25 07:50:38 2010 -0800
> +++ b/xen/arch/x86/srat.c          Thu Feb 25 08:02:36 2010 -0800
> @@ -20,13 +20,15 @@
>  #include <asm/e820.h>
>  #include <asm/page.h>
>  
> -static struct acpi_table_slit *__read_mostly acpi_slit;
> -
>  static nodemask_t nodes_parsed __initdata;
>  static nodemask_t nodes_found __initdata;
>  static struct node nodes[MAX_NUMNODES] __initdata;
>  static u8 __read_mostly pxm2node[256] = { [0 ... 255] = 0xff };
>  
> +static struct {
> +             struct acpi_table_slit slit_table;
> +             u8 entries[MAX_NUMNODES * MAX_NUMNODES];
> +} acpi_slit;
>  
>  static int num_node_memblks;
>  static struct node node_memblk_range[NR_NODE_MEMBLKS];
> @@ -144,7 +146,8 @@
>                                 printk(KERN_INFO "ACPI: SLIT table looks
> invalid. Not used.\n");
>                                 return;
>                 }
> -              acpi_slit = slit;
> +
> +             memcpy(&acpi_slit, slit, slit->header.length);
>  }
>  
>  /* Callback for Proximity Domain -> LAPIC mapping */
> @@ -424,10 +427,10 @@
>  {
>                 int index;
>  
> -              if (!acpi_slit)
> +             if (!acpi_slit.slit_table.header.length)
>                                 return a == b ? 10 : 20;
> -              index = acpi_slit->locality_count * node_to_pxm(a);
> -              return acpi_slit->entry[index + node_to_pxm(b)];
> +             index = acpi_slit.slit_table.locality_count * node_to_pxm(a);
> +             return acpi_slit.slit_table.entry[index + node_to_pxm(b)];
>  }
>  
>  EXPORT_SYMBOL(__node_distance);
> diff -r b474725a242b xen/include/acpi/actbl1.h
> --- a/xen/include/acpi/actbl1.h Thu Feb 25 07:50:38 2010 -0800
> +++ b/xen/include/acpi/actbl1.h              Thu Feb 25 08:02:36 2010 -0800
> @@ -573,7 +573,7 @@
>  struct acpi_table_slit {
>                 struct acpi_table_header header;            /* Common ACPI
> table header */
>                 u64 locality_count;
> -              u8 entry[1];                        /* Real size = localities^2
> */
> +             u8 entry[0];                        /* Real size = localities^2
> */
>  };
>  
>  
> /*****************************************************************************
> **
> 

Re: [PATCH] to fix ACPI slit table access at runtime

[Jan Beulich]

>>> Keir Fraser <keir.fraser@eu.citrix.com> 25.02.10 13:13 >>>
>By the way, a separate question for Jan: I notice you added an
>alloc_boot_pages() call in arch/x86/numa.c, and get a virtual address from
>mfn_to_virt(). This is bogus for x86_32, so can we just stub out that
>function for the 32-bit build: looks like the caller would then gracefully
>fail? I wonder whether this could explain the crash that Ian Jackson
>reported on one system with PAE Xen the other day.

Yes, quite possible. Although - specifically after his report - I ran
a 32-bit image on my only somewhat NUMA-ish system, and did not
see it die:

(XEN) SRAT: PXM 0 -> APIC 0 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 1 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 2 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 3 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 4 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 5 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 6 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 7 -> Node 1
(XEN) SRAT: Node 0 PXM 0 0-a0000
(XEN) SRAT: Node 0 PXM 0 100000-80000000
(XEN) SRAT: Node 1 PXM 1 80000000-d0000000
(XEN) SRAT: Node 1 PXM 1 100000000-130000000
(XEN) NUMA: Allocated memnodemap from 2e37e000 - 2e380000
(XEN) NUMA: Using 8 for the hash shift.

All it took was the patch that's now c/s 20978. But indeed the
addresses printed suggest this cannot work properly, even if it
didn't crash.

Whether this indeed causes Ian's problems could be easily
clarified by him adding loglvl=all to see those two NUMA:
messages. What makes me think it may not is that CR2 was
zero in his log.

Removing the code for 32-bit altogether is certainly one option (in
that case I'd want to see _memnodemap to be reasonably
increased though, plus we should probably make an attempt to
reduce memnodemapsize again - the hash shift currently is unduly
small - and I have a patch for the original Linux code to do so).

All other options are likely indeed not worth it to make 32-bit
happy.

Jan

Re: Re: [PATCH] to fix ACPI slit table access at runtime

[Keir Fraser]

On 25/02/2010 13:03, "Jan Beulich" <JBeulich@novell.com> wrote:

> Removing the code for 32-bit altogether is certainly one option (in
> that case I'd want to see _memnodemap to be reasonably
> increased though, plus we should probably make an attempt to
> reduce memnodemapsize again - the hash shift currently is unduly
> small - and I have a patch for the original Linux code to do so).
> 
> All other options are likely indeed not worth it to make 32-bit
> happy.

Given we agree the current situation is a bug, could you make up a patch
along the lines of what you prefer to see? Because my default action will be
simply to ifdef the code, as NUMA-on-i386 is not much a concern of mine.

 -- Keir

[PATCH] Re: Re: [PATCH] to fix ACPI slit table access at runtime

[Jan Beulich]

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

>>> Keir Fraser <keir.fraser@eu.citrix.com> 25.02.10 14:16 >>>
>Given we agree the current situation is a bug, could you make up a patch
>along the lines of what you prefer to see? Because my default action will be
>simply to ifdef the code, as NUMA-on-i386 is not much a concern of mine.

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

--- 2010-02-19.orig/xen/arch/x86/numa.c	2010-01-13 18:58:11.000000000 +0100
+++ 2010-02-19/xen/arch/x86/numa.c	2010-02-25 14:27:14.000000000 +0100
@@ -30,7 +30,7 @@ struct node_data node_data[MAX_NUMNODES]
 
 /* Mapping from pdx to node id */
 int memnode_shift;
-static typeof(*memnodemap) _memnodemap[2];
+static typeof(*memnodemap) _memnodemap[64];
 unsigned long memnodemapsize;
 u8 *memnodemap;
 
@@ -90,6 +90,7 @@ static int __init populate_memnodemap(co
 
 static int __init allocate_cachealigned_memnodemap(void)
 {
+#ifndef __i386__
 	unsigned long size = PFN_UP(memnodemapsize * sizeof(*memnodemap));
 	unsigned long mfn = alloc_boot_pages(size, 1);
 
@@ -108,6 +109,13 @@ static int __init allocate_cachealigned_
 	memnodemapsize = size / sizeof(*memnodemap);
 
 	return 0;
+#else
+	printk(KERN_ERR
+	       "Memory to Node hash needs %lu entries, got only %zu\n",
+	       memnodemapsize, ARRAY_SIZE(_memnodemap));
+	memnodemapsize = 0;
+	return -1;
+#endif
 }
 
 /*




[-- Attachment #2: i386-numa-not-boot-alloc.patch --]
[-- Type: text/plain, Size: 1064 bytes --]

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

--- 2010-02-19.orig/xen/arch/x86/numa.c	2010-01-13 18:58:11.000000000 +0100
+++ 2010-02-19/xen/arch/x86/numa.c	2010-02-25 14:27:14.000000000 +0100
@@ -30,7 +30,7 @@ struct node_data node_data[MAX_NUMNODES]
 
 /* Mapping from pdx to node id */
 int memnode_shift;
-static typeof(*memnodemap) _memnodemap[2];
+static typeof(*memnodemap) _memnodemap[64];
 unsigned long memnodemapsize;
 u8 *memnodemap;
 
@@ -90,6 +90,7 @@ static int __init populate_memnodemap(co
 
 static int __init allocate_cachealigned_memnodemap(void)
 {
+#ifndef __i386__
 	unsigned long size = PFN_UP(memnodemapsize * sizeof(*memnodemap));
 	unsigned long mfn = alloc_boot_pages(size, 1);
 
@@ -108,6 +109,13 @@ static int __init allocate_cachealigned_
 	memnodemapsize = size / sizeof(*memnodemap);
 
 	return 0;
+#else
+	printk(KERN_ERR
+	       "Memory to Node hash needs %lu entries, got only %zu\n",
+	       memnodemapsize, ARRAY_SIZE(_memnodemap));
+	memnodemapsize = 0;
+	return -1;
+#endif
 }
 
 /*

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

RE: [PATCH] to fix ACPI slit table access at runtime

[Kamble, Nitin A]

> Hi Keir,
>   I was noticing that the current Xen code was not able to access the ACPI
> SLIT data (node to node distance) at runtime. And I found root cause of it
> being the acpi_slit pointer not being valid at runtime.
> I have fixed the issue by saving the slit table data at boot time, and using
> the saved data for runtime access as follows.

Better would be to dynamically alloc_boot_pages(). Then also the patch would
be about two or three lines. The only disadvantage would be that then SLIT
parsing would be for 64-bit hypervisor only (since 32-bit Xen does not have
mappings for bootmem). I think we can live with that - I note that Linux
only does SLIT parsing for x86_64 too.

Keir,
  If I understand you correctly, you would prefer to have x86_64 bit only solution, with dynamic allocation. I will change the patch accordingly and resend it.

Thanks & Regards,
Nitin


 -- Keir

> Please accept or comment.
> Thanks & Regards,
> Nitin
>  
> Signed-Off-By: Nitin A Kamble <nitin.a.kamble@intel.com>
>  
> diff -r b474725a242b xen/arch/x86/srat.c
> --- a/xen/arch/x86/srat.c             Thu Feb 25 07:50:38 2010 -0800
> +++ b/xen/arch/x86/srat.c          Thu Feb 25 08:02:36 2010 -0800
> @@ -20,13 +20,15 @@
>  #include <asm/e820.h>
>  #include <asm/page.h>
>  
> -static struct acpi_table_slit *__read_mostly acpi_slit;
> -
>  static nodemask_t nodes_parsed __initdata;
>  static nodemask_t nodes_found __initdata;
>  static struct node nodes[MAX_NUMNODES] __initdata;
>  static u8 __read_mostly pxm2node[256] = { [0 ... 255] = 0xff };
>  
> +static struct {
> +             struct acpi_table_slit slit_table;
> +             u8 entries[MAX_NUMNODES * MAX_NUMNODES];
> +} acpi_slit;
>  
>  static int num_node_memblks;
>  static struct node node_memblk_range[NR_NODE_MEMBLKS];
> @@ -144,7 +146,8 @@
>                                 printk(KERN_INFO "ACPI: SLIT table looks
> invalid. Not used.\n");
>                                 return;
>                 }
> -              acpi_slit = slit;
> +
> +             memcpy(&acpi_slit, slit, slit->header.length);
>  }
>  
>  /* Callback for Proximity Domain -> LAPIC mapping */
> @@ -424,10 +427,10 @@
>  {
>                 int index;
>  
> -              if (!acpi_slit)
> +             if (!acpi_slit.slit_table.header.length)
>                                 return a == b ? 10 : 20;
> -              index = acpi_slit->locality_count * node_to_pxm(a);
> -              return acpi_slit->entry[index + node_to_pxm(b)];
> +             index = acpi_slit.slit_table.locality_count * node_to_pxm(a);
> +             return acpi_slit.slit_table.entry[index + node_to_pxm(b)];
>  }
>  
>  EXPORT_SYMBOL(__node_distance);
> diff -r b474725a242b xen/include/acpi/actbl1.h
> --- a/xen/include/acpi/actbl1.h Thu Feb 25 07:50:38 2010 -0800
> +++ b/xen/include/acpi/actbl1.h              Thu Feb 25 08:02:36 2010 -0800
> @@ -573,7 +573,7 @@
>  struct acpi_table_slit {
>                 struct acpi_table_header header;            /* Common ACPI
> table header */
>                 u64 locality_count;
> -              u8 entry[1];                        /* Real size = localities^2
> */
> +             u8 entry[0];                        /* Real size = localities^2
> */
>  };
>  
>  
> /*****************************************************************************
> **
> 

Re: [PATCH] to fix ACPI slit table access at runtime

[Keir Fraser]

On 25/02/2010 17:50, "Kamble, Nitin A" <nitin.a.kamble@intel.com> wrote:

> Better would be to dynamically alloc_boot_pages(). Then also the patch would
> be about two or three lines. The only disadvantage would be that then SLIT
> parsing would be for 64-bit hypervisor only (since 32-bit Xen does not have
> mappings for bootmem). I think we can live with that - I note that Linux
> only does SLIT parsing for x86_64 too.
> 
> Keir,
>   If I understand you correctly, you would prefer to have x86_64 bit only
> solution, with dynamic allocation. I will change the patch accordingly and
> resend it.

That would be great, thanks. I think you should only have to modify
acpi_numa_slit_init() in your revised patch.

 -- Keir

RE: [PATCH] to fix ACPI slit table access at runtime

[Kamble, Nitin A]

Keir, here is the updated patch. I did verify that it is giving right information at runtime.

Thanks & Regards,
Nitin

Signed-Off-By: Nitin A Kamble <nitin.a.kamble@intel.com>

diff -r b474725a242b xen/arch/x86/srat.c
--- a/xen/arch/x86/srat.c	Thu Feb 25 07:50:38 2010 -0800
+++ b/xen/arch/x86/srat.c	Fri Feb 26 02:41:27 2010 -0800
@@ -140,11 +140,21 @@
 /* Callback for SLIT parsing */
 void __init acpi_numa_slit_init(struct acpi_table_slit *slit)
 {
+	unsigned long mfn, pages;
 	if (!slit_valid(slit)) {
 		printk(KERN_INFO "ACPI: SLIT table looks invalid. Not used.\n");
 		return;
 	}
-	acpi_slit = slit;
+	pages = slit->header.length >> PAGE_SHIFT;
+	if (!pages)
+		pages = 1;
+	mfn = alloc_boot_pages(pages , 1);
+	if (!mfn) {
+		printk(KERN_ERR "ACPI: Unable to allocate memory for saving ACPI SLIT numa information.\n");
+		return;
+	}
+	acpi_slit = mfn_to_virt(mfn);
+	memcpy(acpi_slit, slit, slit->header.length);
 }
 
 /* Callback for Proximity Domain -> LAPIC mapping */

Warning in current pv_ops Kernel

[Carsten Schiers]

Dear all,

found the following warning during boot of current pv_ops kernel under
Xen 3.4.2, 2.6.18.8 Dom0 64Bit, Kernel is also 64 Bit:

[    0.000999] ------------[ cut here ]------------
[    0.000999] WARNING: at 
/usr/src/xen/xen-unstable.hg/linux-2.6-pvopsamd64.git/arch/x86/kernel/ap
ic/apic.c:247 native_apic_write_dummy+0x30/0x3c()
[    0.000999] Modules linked in:
[    0.000999] Pid: 0, comm: swapper Not tainted 2.6.31.6 #1
[    0.000999] Call Trace:
[    0.000999]  [<ffffffff81048cf6>] ? native_apic_write_dummy+0x30/0x3c
[    0.000999]  [<ffffffff8106bdb4>] warn_slowpath_common+0x77/0xa4
[    0.000999]  [<ffffffff8106bdf0>] warn_slowpath_null+0xf/0x11
[    0.000999]  [<ffffffff81048cf6>] native_apic_write_dummy+0x30/0x3c
[    0.000999]  [<ffffffff8103f4a7>] perf_counters_lapic_init+0x2e/0x30
[    0.000999]  [<ffffffff8192d94f>] init_hw_perf_counters+0x305/0x3a2
[    0.000999]  [<ffffffff8102f80f>] ? xen_restore_fl_direct_end+0x0/0x1
[    0.000999]  [<ffffffff810fac40>] ? kmem_cache_alloc+0xcb/0x12d
[    0.000999]  [<ffffffff8192d61b>] identify_boot_cpu+0x3c/0x3e
[    0.000999]  [<ffffffff8192d626>] check_bugs+0x9/0x2d
[    0.000999]  [<ffffffff81924630>] start_kernel+0x41d/0x432
[    0.000999]  [<ffffffff81923b1f>] x86_64_start_reservations+0xaa/0xae
[    0.000999]  [<ffffffff8192829a>] xen_start_kernel+0x633/0x63a
[    0.000999] ---[ end trace 4eaa2a86a8e2da22 ]---

Hope it helps, if any additional information is needed, please let me
know.

BR,
Carsten.

Re: Warning in current pv_ops Kernel

[Pasi Kärkkäinen]

On Thu, Feb 25, 2010 at 10:53:19PM +0100, Carsten Schiers wrote:
> Dear all,
> 
> found the following warning during boot of current pv_ops kernel under
> Xen 3.4.2, 2.6.18.8 Dom0 64Bit, Kernel is also 64 Bit:
> 
> [    0.000999] ------------[ cut here ]------------
> [    0.000999] WARNING: at 
> /usr/src/xen/xen-unstable.hg/linux-2.6-pvopsamd64.git/arch/x86/kernel/ap
> ic/apic.c:247 native_apic_write_dummy+0x30/0x3c()
> [    0.000999] Modules linked in:
> [    0.000999] Pid: 0, comm: swapper Not tainted 2.6.31.6 #1
> [    0.000999] Call Trace:
> [    0.000999]  [<ffffffff81048cf6>] ? native_apic_write_dummy+0x30/0x3c
> [    0.000999]  [<ffffffff8106bdb4>] warn_slowpath_common+0x77/0xa4
> [    0.000999]  [<ffffffff8106bdf0>] warn_slowpath_null+0xf/0x11
> [    0.000999]  [<ffffffff81048cf6>] native_apic_write_dummy+0x30/0x3c
> [    0.000999]  [<ffffffff8103f4a7>] perf_counters_lapic_init+0x2e/0x30
> [    0.000999]  [<ffffffff8192d94f>] init_hw_perf_counters+0x305/0x3a2
> [    0.000999]  [<ffffffff8102f80f>] ? xen_restore_fl_direct_end+0x0/0x1
> [    0.000999]  [<ffffffff810fac40>] ? kmem_cache_alloc+0xcb/0x12d
> [    0.000999]  [<ffffffff8192d61b>] identify_boot_cpu+0x3c/0x3e
> [    0.000999]  [<ffffffff8192d626>] check_bugs+0x9/0x2d
> [    0.000999]  [<ffffffff81924630>] start_kernel+0x41d/0x432
> [    0.000999]  [<ffffffff81923b1f>] x86_64_start_reservations+0xaa/0xae
> [    0.000999]  [<ffffffff8192829a>] xen_start_kernel+0x633/0x63a
> [    0.000999] ---[ end trace 4eaa2a86a8e2da22 ]---
> 
> Hope it helps, if any additional information is needed, please let me
> know.
> 

>From what branch is this kernel from? xen/master?

-- Pasi

RE: [PATCH] to fix ACPI slit table access at runtime

[Kamble, Nitin A]

> Keir, here is the updated patch. I did verify that it is giving right information at runtime.

This is re-updated and bit simplified patch.
Signed-Off-By: Nitin A Kamble <nitin.a.kamble@intel.com>


diff -r b474725a242b xen/arch/x86/srat.c
--- a/xen/arch/x86/srat.c	Thu Feb 25 07:50:38 2010 -0800
+++ b/xen/arch/x86/srat.c	Fri Feb 26 03:26:08 2010 -0800
@@ -140,11 +140,18 @@
 /* Callback for SLIT parsing */
 void __init acpi_numa_slit_init(struct acpi_table_slit *slit)
 {
+	unsigned long mfn;
 	if (!slit_valid(slit)) {
 		printk(KERN_INFO "ACPI: SLIT table looks invalid. Not used.\n");
 		return;
 	}
-	acpi_slit = slit;
+	mfn = alloc_boot_pages(PFN_UP(slit->header.length), 1);
+	if (!mfn) {
+		printk(KERN_ERR "ACPI: Unable to allocate memory for saving ACPI SLIT numa information.\n");
+		return;
+	}
+	acpi_slit = mfn_to_virt(mfn);
+	memcpy(acpi_slit, slit, slit->header.length);
 }
 
 /* Callback for Proximity Domain -> LAPIC mapping */

RE: [PATCH] to fix ACPI slit table access at runtime

[Jan Beulich]

But the alloc_boot_pages() isn't done on x86-64 only, as Keir pointed
out has to be the case.

Jan

>>> "Kamble, Nitin A" <nitin.a.kamble@intel.com> 25.02.10 20:31 >>>
> Keir, here is the updated patch. I did verify that it is giving right information at runtime.

This is re-updated and bit simplified patch.
Signed-Off-By: Nitin A Kamble <nitin.a.kamble@intel.com>


diff -r b474725a242b xen/arch/x86/srat.c
--- a/xen/arch/x86/srat.c	Thu Feb 25 07:50:38 2010 -0800
+++ b/xen/arch/x86/srat.c	Fri Feb 26 03:26:08 2010 -0800
@@ -140,11 +140,18 @@
 /* Callback for SLIT parsing */
 void __init acpi_numa_slit_init(struct acpi_table_slit *slit)
 {
+	unsigned long mfn;
 	if (!slit_valid(slit)) {
 		printk(KERN_INFO "ACPI: SLIT table looks invalid. Not used.\n");
 		return;
 	}
-	acpi_slit = slit;
+	mfn = alloc_boot_pages(PFN_UP(slit->header.length), 1);
+	if (!mfn) {
+		printk(KERN_ERR "ACPI: Unable to allocate memory for saving ACPI SLIT numa information.\n");
+		return;
+	}
+	acpi_slit = mfn_to_virt(mfn);
+	memcpy(acpi_slit, slit, slit->header.length);
 }
 
 /* Callback for Proximity Domain -> LAPIC mapping */


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

RE: RE: [PATCH] to fix ACPI slit table access at runtime

[Kamble, Nitin A]

Thanks Jan for point it out. Keir already took care of that part.
Regards,
Nitin


-----Original Message-----
From: Jan Beulich [mailto:JBeulich@novell.com] 
Sent: Friday, February 26, 2010 12:36 AM
To: Keir Fraser; Kamble, Nitin A
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] RE: [PATCH] to fix ACPI slit table access at runtime

But the alloc_boot_pages() isn't done on x86-64 only, as Keir pointed
out has to be the case.

Jan

>>> "Kamble, Nitin A" <nitin.a.kamble@intel.com> 25.02.10 20:31 >>>
> Keir, here is the updated patch. I did verify that it is giving right information at runtime.

This is re-updated and bit simplified patch.
Signed-Off-By: Nitin A Kamble <nitin.a.kamble@intel.com>


diff -r b474725a242b xen/arch/x86/srat.c
--- a/xen/arch/x86/srat.c	Thu Feb 25 07:50:38 2010 -0800
+++ b/xen/arch/x86/srat.c	Fri Feb 26 03:26:08 2010 -0800
@@ -140,11 +140,18 @@
 /* Callback for SLIT parsing */
 void __init acpi_numa_slit_init(struct acpi_table_slit *slit)
 {
+	unsigned long mfn;
 	if (!slit_valid(slit)) {
 		printk(KERN_INFO "ACPI: SLIT table looks invalid. Not used.\n");
 		return;
 	}
-	acpi_slit = slit;
+	mfn = alloc_boot_pages(PFN_UP(slit->header.length), 1);
+	if (!mfn) {
+		printk(KERN_ERR "ACPI: Unable to allocate memory for saving ACPI SLIT numa information.\n");
+		return;
+	}
+	acpi_slit = mfn_to_virt(mfn);
+	memcpy(acpi_slit, slit, slit->header.length);
 }
 
 /* Callback for Proximity Domain -> LAPIC mapping */


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