Re: Crash in set_cpu_sibling_map() booting Xen 4.6.0 on Fusion

[Chao Peng <chao.p.peng@linux.intel.com>]

On Thu, Nov 26, 2015 at 12:49:42AM -0700, Jan Beulich wrote:
> >>> On 26.11.15 at 00:27, <eswierk@skyportsystems.com> 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 processors, number
> > of cores, hyperthreading, etc. The weird processor ID assignment (0,
> > 2, 4, 6, ...) occurs only with 4 or 8 processors, 1 core per socket,
> > and no hyperthreading. If I change any of these parameters, the
> > processor IDs become sequential.
> > 
> > It appears in the 4- and 8-processor cases, VMware is emulating
> > something like a Xeon E7340:
> > https://github.com/deater/test_proc/blob/master/x86_64/x86_64.intel.6.15.11.
> > xeon_e7340
> > 
> > In fact someone asked a question about running Xen on this platform
> > way back when: 
> > http://lists.xenproject.org/archives/html/xen-users/2008-05/msg00691.html 
> > 
> > Others of similar vintage assign processor IDs 0 and 3 on a
> > 2-processor system:
> > https://www.centos.org/forums/viewtopic.php?t=30255 
> > 
> > or even 0 and 6: 
> > http://serverfault.com/questions/302429/interpreting-cpuinfo 
> > 
> > So there are real hardware platforms with non-sequential processor
> > IDs. They are quite ancient and don't support CAT, but that doesn't
> > rule out the possibility of a newer or future platform behaving
> > similarly.
> 
> Not supporting CAT is not a criteria, since the socket data setup
> happens unconditionally. However (and as said before), non-
> sequential processor IDs are fine. Non-sequential socket IDs are
> what is problematic.

I asked non-sequential socket ID problem internally but I don't know if
I can get a clear answer in the end, please just stay tuned for a while.

Thanks,
Chao