On 26.08.2021 23:00, Julien Grall wrote:
> Digging down, Linux will set smp_num_siblings to 0 (via
> detect_ht_early()) and as a result will skip all the CPUs. The value is
> retrieve from a CPUID leaf. So it sounds like we don't set the leaft
> correctly.
Xen leaves leaf 1 EBX[23:16] untouched from what the tool stack
passes. The tool stack doubles the value coming from hardware
(or qemu in your case), unless the result would overflow. Hence
it would look to me as if the value coming from qemu has got to
be zero. Which is perfectly fine if HTT is off, just that
libxenguest isn't prepared for this. Could you see whether the
patch below helps (making our hack even hackier)?
Jan
libxenguest/x86: ensure CPUID[1].EBX[32:16] is non-zero for HVM
We unconditionally set HTT, so merely doubling the value read from
hardware isn't going to be correct if that value is zero.
Reported-by: Julien Grall <jul...@xen.org>
Signed-off-by: Jan Beulich <jbeul...@suse.com>
---
I question the doubling in the first place, as that leads to absurd
values when the underlying hardware has a value larger than 1 here. I'd
be inclined to suggest to double the value only if the incoming value
has bit 0 set. And then we'd want to also deal with the case of both
bit 0 and bit 7 being set (perhaps by clearing bit 0 in this case).
--- a/tools/libs/guest/xg_cpuid_x86.c
+++ b/tools/libs/guest/xg_cpuid_x86.c
@@ -594,7 +594,9 @@ int xc_cpuid_apply_policy(xc_interface *
* Update to reflect vLAPIC_ID = vCPU_ID * 2, but make sure to avoid
* overflow.
*/
- if ( !(p->basic.lppp & 0x80) )
+ if ( !p->basic.lppp )
+ p->basic.lppp = 2;
+ else if ( !(p->basic.lppp & 0x80) )
p->basic.lppp *= 2;
switch ( p->x86_vendor )
