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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 26.11.15 at 00:27, <eswierk@xxxxxxxxxxxxxxxxxx> 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.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel