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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 25.11.15 at 08:48, <chao.p.peng@xxxxxxxxxxxxxxx> 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 now (like resulting in contiguous
>> socket numbers), and ask for them getting made explicit (if there
>> are any), or it being made explicit that no assumptions at all are
>> to be made at all on the presented values
> 
> Actually there is already such statement in SDM (ch8.9.1, vol3):
> 
> "The value of valid APIC_IDs need not be contiguous across package
> boundary or core boundaries".

That's a statement on APIC ID space (which necessarily can't be
contiguous on systems with a non-power-of-2 core count), but I
was asking about the socket ID space.

>> (in which case we'd
>> have to consume MADT parsing data in set_nr_sockets(), e.g.
>> by replacing num_processors there with one more than the
>> maximum APIC ID of any non-disabled CPU)?
> 
> Even with this, we still have problem for hotplug case, the inserted
> CPU may have a APIC_ID bigger than the maximum APIC_ID here.
> 
> But let's back to the real world. Most machines that support CAT should
> have continuous SOCKET_ID so it's not a problem. Giving that CAT is the
> only feature uses this, I guess this suggestion might be better than
> other solutions in practice. 

And we could actually cater for that by extrapolating the value
added to cover disabled_cpus.

Jan


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