Re: [Xen-devel] Crash in set_cpu_sibling_map() booting Xen 4.6.0 on Fusion

I tested on VMware Fusion with 3, 4 and 8 CPUs, and it works in all cases. (XEN) Xen version 4.6.1-pre ( 4.6.1~pre-1skyport1) (eswi...@skyportsystems.com) (gcc (Debian 5.2.1-19.1skyport1) 5.2.1 20150930) debug=n Wed Dec 2 07:22:20 PST 2015 (XEN) Bootloader: SYSLINUX 4.05 20140113 (XEN) Command

Re: [Xen-devel] Crash in set_cpu_sibling_map() booting Xen 4.6.0 on Fusion

>>> On 24.11.15 at 21:28, wrote: > RFC. Boot tested on VMware Fusion, and on a 2-socket Xeon server. Mind trying this one instead? Jan --- unstable.orig/xen/arch/x86/mpparse.c +++ unstable/xen/arch/x86/mpparse.c @@ -89,19 +89,14 @@ void __init

Re: [Xen-devel] Crash in set_cpu_sibling_map() booting Xen 4.6.0 on Fusion

BTW, we use "package ID", rather than "socket ID" in the SDM. Assignment of the package IDs on a system is a BIOS matter. Basically BIOS needs to assign package IDs to resolve APIC ID collision at early boot time, and the convention is up to the vendor/or the specific system configuration agents.

Re: [Xen-devel] Crash in set_cpu_sibling_map() booting Xen 4.6.0 on Fusion

On Thu, Nov 26, 2015 at 12:49:42AM -0700, Jan Beulich wrote: > >>> On 26.11.15 at 00:27, wrote: > > A few more data points: I also tested Xen 4.6 on VMware ESXi 5.5, and > > it yields similar results. Not surprising, since Fusion uses basically > > the same

Re: [Xen-devel] Crash in set_cpu_sibling_map() booting Xen 4.6.0 on Fusion

A few more data points: I also tested Xen 4.6 on VMware ESXi 5.5, and it yields similar results. Not surprising, since Fusion uses basically the same virtualization engine. However, ESXi offers many more choices of number of processors, number of cores, hyperthreading, etc. The weird processor ID

Re: [Xen-devel] Crash in set_cpu_sibling_map() booting Xen 4.6.0 on Fusion

>>> On 26.11.15 at 00:27, wrote: > A few more data points: I also tested Xen 4.6 on VMware ESXi 5.5, and > it yields similar results. Not surprising, since Fusion uses basically > the same virtualization engine. > > However, ESXi offers many more choices of number of

Re: [Xen-devel] Crash in set_cpu_sibling_map() booting Xen 4.6.0 on Fusion

>>> On 25.11.15 at 08:48, wrote: > On Tue, Nov 24, 2015 at 03:34:45AM -0700, Jan Beulich wrote: >> Chao, could you - inside Intel - please check whether there are >> any assumptions on the respective CPUID leaf output that aren't >> explicitly stated in the SDM right

Re: [Xen-devel] Crash in set_cpu_sibling_map() booting Xen 4.6.0 on Fusion

>>> On 24.11.15 at 21:28, wrote: > RFC. Boot tested on VMware Fusion, and on a 2-socket Xeon server. Well, thanks, but as said I view this is overkill (and I'm also not sure what you have is completely race free). Hence I'd prefer a more light weight solution if at

Re: [Xen-devel] Crash in set_cpu_sibling_map() booting Xen 4.6.0 on Fusion

RFC. Boot tested on VMware Fusion, and on a 2-socket Xeon server. diff --git a/xen/include/asm-x86/smp.h b/xen/include/asm-x86/smp.h index ea07888..a41ce2d 100644 --- a/xen/include/asm-x86/smp.h +++ b/xen/include/asm-x86/smp.h @@ -67,7 +67,7 @@ extern unsigned int nr_sockets; void

Re: [Xen-devel] Crash in set_cpu_sibling_map() booting Xen 4.6.0 on Fusion

On Tue, Nov 24, 2015 at 03:34:45AM -0700, Jan Beulich wrote: > >>> On 23.11.15 at 17:36, wrote: > > I instrumented detect_extended_topology() and ran again with 4 CPUs. > >[...] > > (XEN) smp_store_cpu_info id=3 > > (XEN) detect_extended_topology cpuid_count op=0xb

Re: [Xen-devel] Crash in set_cpu_sibling_map() booting Xen 4.6.0 on Fusion

>>> On 23.11.15 at 17:36, wrote: > I instrumented detect_extended_topology() and ran again with 4 CPUs. >[...] > (XEN) smp_store_cpu_info id=3 > (XEN) detect_extended_topology cpuid_count op=0xb count=0 eax=0x0 ebx=0x1 > ecx=0x100 edx=0x6 > (XEN)

Re: [Xen-devel] Crash in set_cpu_sibling_map() booting Xen 4.6.0 on Fusion

On Tue, Nov 24, 2015 at 2:34 AM, Jan Beulich wrote: > Indeed, and I think I had said so. The algorithm does, however, tell > us that with the above output CPU 3 (APIC ID 6) is on socket 6 (both > shifts being zero), which for the whole system results in sockets 1, > 3, and 5

Re: [Xen-devel] Crash in set_cpu_sibling_map() booting Xen 4.6.0 on Fusion

>>> On 24.11.15 at 15:13, wrote: > On Tue, Nov 24, 2015 at 2:34 AM, Jan Beulich wrote: >> Bottom line - for the moment I do not see a reasonable way of >> dealing with that situation. The closest I could see would be what >> we iirc had temporarily

Re: [Xen-devel] Crash in set_cpu_sibling_map() booting Xen 4.6.0 on Fusion

>>> On 21.11.15 at 02:21, wrote: > The problem is that the index of the socket_cpumask array is derived via > cpu_to_socket() from the APIC ID of the processor in a given socket, but > the size of the array is computed based on nr_sockets, which is not > necessarily

Re: [Xen-devel] Crash in set_cpu_sibling_map() booting Xen 4.6.0 on Fusion

I instrumented detect_extended_topology() and ran again with 4 CPUs. Loading xen-4.6-amd64.gz... ok Loading vmlinuz-3.14.51-grsec-dock... ok Loading initrd.img-3.14.51-grsec-dock... ok (XEN) Xen version 4.6.1-pre (Debian 4.6.1~pre-1skyport1) ( eswi...@skyportsystems.com) (gcc (Debian 4.9.3-4)

Re: [Xen-devel] Crash in set_cpu_sibling_map() booting Xen 4.6.0 on Fusion

On Mon, Nov 23, 2015 at 09:10:08AM +0800, Chao Peng wrote: > On Fri, Nov 20, 2015 at 05:21:11PM -0800, Ed Swierk wrote: > > The problem is that the index of the socket_cpumask array is derived via > > cpu_to_socket() from the APIC ID of the processor in a given socket, but > > the size of the

Re: [Xen-devel] Crash in set_cpu_sibling_map() booting Xen 4.6.0 on Fusion

On Fri, Nov 20, 2015 at 05:21:11PM -0800, Ed Swierk wrote: > The problem is that the index of the socket_cpumask array is derived via > cpu_to_socket() from the APIC ID of the processor in a given socket, but > the size of the array is computed based on nr_sockets, which is not > necessarily equal

Re: [Xen-devel] Crash in set_cpu_sibling_map() booting Xen 4.6.0 on Fusion

>>> On 20.11.15 at 02:22, wrote: > (XEN) [ Xen-4.6.1-pre x86_64 debug=n Not tainted ] > (XEN) CPU:3 > (XEN) RIP:e008:[] set_cpu_sibling_map+0x3f/0x330 > (XEN) RFLAGS: 00010006 CONTEXT: hypervisor > (XEN) rax: 0001 rbx:

Re: [Xen-devel] Crash in set_cpu_sibling_map() booting Xen 4.6.0 on Fusion

On 20/11/15 10:25, Jan Beulich wrote: On 20.11.15 at 02:22, wrote: >> (XEN) [ Xen-4.6.1-pre x86_64 debug=n Not tainted ] >> (XEN) CPU:3 >> (XEN) RIP:e008:[] set_cpu_sibling_map+0x3f/0x330 >> (XEN) RFLAGS: 00010006 CONTEXT: hypervisor

Re: [Xen-devel] Crash in set_cpu_sibling_map() booting Xen 4.6.0 on Fusion

I instrumented set_nr_sockets() and smp_store_cpu_info(), and re-ran with varying numbers of CPUs. With 4 CPUs, nr_sockets=4, so smp_store_cpu_info() exceeds the bounds of the socket_cpumask array when socket=4 or 6. Loading xen-4.6-amd64.gz... ok Loading vmlinuz-3.14.51-grsec-dock... ok Loading

[Xen-devel] Crash in set_cpu_sibling_map() booting Xen 4.6.0 on Fusion

Xen staging-4.6 crashes when booting on VMware Fusion 8.0.2 (with VT-x/EPT enabled), with 4 virtual CPUs: Loading xen-4.6-amd64.gz... ok Loading vmlinuz-3.14.51-grsec-dock... ok Loading initrd.img-3.14.51-grsec-dock... ok (XEN) Xen version 4.6.1-pre (Debian 4.6.1~pre-1skyport1) (