[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Crash in set_cpu_sibling_map() booting Xen 4.6.0 on Fusion
>>> 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |