[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 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |