WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel