Kamble, Nitin A
2010-Feb-25 00:06 UTC
[Xen-devel] [PATCH] to fix ACPI slit table access at runtime
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 */ }; /******************************************************************************* _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2010-Feb-25 12:13 UTC
[Xen-devel] Re: [PATCH] to fix ACPI slit table access at runtime
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 > */ > }; > > > /***************************************************************************** > ** >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich
2010-Feb-25 13:03 UTC
[Xen-devel] Re: [PATCH] to fix ACPI slit table access at runtime
>>> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2010-Feb-25 13:16 UTC
Re: [Xen-devel] Re: [PATCH] to fix ACPI slit table access at runtime
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich
2010-Feb-25 13:35 UTC
[PATCH] Re: [Xen-devel] Re: [PATCH] to fix ACPI slit table access at runtime
>>> 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 } /* _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Kamble, Nitin A
2010-Feb-25 17:50 UTC
[Xen-devel] RE: [PATCH] to fix ACPI slit table access at runtime
> 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 > */ > }; > > > /***************************************************************************** > ** >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2010-Feb-25 18:01 UTC
[Xen-devel] Re: [PATCH] to fix ACPI slit table access at runtime
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Kamble, Nitin A
2010-Feb-25 18:47 UTC
[Xen-devel] RE: [PATCH] to fix ACPI slit table access at runtime
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 */ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Kamble, Nitin A
2010-Feb-25 19:31 UTC
[Xen-devel] RE: [PATCH] to fix ACPI slit table access at runtime
> 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
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich
2010-Feb-26 08:36 UTC
[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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Kamble, Nitin A
2010-Feb-26 18:37 UTC
RE: [Xen-devel] RE: [PATCH] to fix ACPI slit table access at runtime
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel