On Sun, Sep 22, 2024 at 01:08:21PM -0000, Michael van Elst wrote: > cme...@cmeerw.org (Christof Meerwald) writes: > > >Turns out in my case the CPUID_HTT flag is not set (so lp_max = 1), > >but the maximum number of cores per package is set to 16 - 1, so > >core_max = 16. > > That's a confusing number, the chip has 14 cores and 28 threads. > If HTT is disabled, that would still be only 14 threads. So > I guess, the VM software fakes these values.
Some of it is definitely faked, but I am not sure what the real meaning of these is anyway. BTW, this particular VM has 2 CPU cores assigned to it. The one real Intel CPU I currently have access to is a "Intel(R) Pentium(R) CPU N3540" - here the cpuid results would set lp_max=16 and core_max=8, although the CPU only has 4 cores/threads. It seems to me that most VMs set the CPUID_HTT to false. Anyway, another Intel-based VM I have access to has CPUID_HTT false and maximum IDs for cores in pkg = 0x0 (0) so it would have lp_max=1 and core_max=1, but also has 2 CPU cores assigned. > >but we don't check for that condition in the Intel case - should we? > >Adding that case for Intel seems to fix it for me, e.g. > > > /* Check for leaf 4 support. */ > > if (ci->ci_max_cpuid >= 4 && > > (ci->ci_feat_val[0] & CPUID_HTT) != 0) { > > /* Maximum number of Cores per package (eax[31:26]). */ > > x86_cpuid2(4, 0, descs); > > core_max = __SHIFTOUT(descs[0], CPUID_DCP_CORE_P_PKG) > > + 1; > > } else { > > core_max = 1; > > } > > Wouldn't that tell that we only have 1 core / 1 thread ? I am not sure - I am currently running NetBSD with that change and it has 2 CPU cores assigned and the 2 cores show up in /proc/cpuinfo and in dmesg: [ 1.000004] cpu0 at mainbus0 apid 0 [ 1.000004] cpu0: Use lfence to serialize rdtsc [ 1.000004] cpu0: Intel(R) Xeon(R) CPU E5-2690 v4 @ 2.60GHz, id 0x406f1 [ 1.000004] cpu0: node 0, package 0, core 0, smt 0 [ 1.000004] cpu1 at mainbus0 apid 1 [ 1.000004] cpu1: Intel(R) Xeon(R) CPU E5-2690 v4 @ 2.60GHz, id 0x406f1 [ 1.000004] cpu1: node 0, package 1, core 0, smt 0 > Maybe instead of failing when lp_max < core_max, we should just > gracefully handle this case as lp_max == core_max. That was actually my initial attempt (which also worked), but then I saw that the AMD code checked for CPUID_HTT, so thought maybe the Intel code should do the same? But now I am thinking that maybe for CPUID_HTT false, both AMD and Intel should essentially set lp_max to core_max (instead of setting core_max to 1). Christof -- https://cmeerw.org sip:cmeerw at cmeerw.org mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org