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

["Nakajima, Jun" <jun.nakajima@xxxxxxxxx>]

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. And "contiguous package IDs" are not
required there to make it flexible. In fact, if you look at "Example
8-22. Compute the Number of Packages, Cores, and Processor
Relationships in a MP System", the sample code doesn't assume that
PACKAGE_IDs be continuous.


On Thu, Nov 26, 2015 at 6:11 PM, Chao Peng <chao.p.peng@xxxxxxxxxxxxxxx> wrote:
> On Thu, Nov 26, 2015 at 12:49:42AM -0700, Jan Beulich wrote:
>> >>> 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.
>
> 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
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel



-- 
Jun
Intel Open Source Technology Center

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