[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: HVM guest only bring up a single vCPU

  • To: Julien Grall <julien@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 27 Aug 2021 11:26:54 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=49X9HUtKmCoxlpsj64qfOvL54npLODYkICa9fxmHsjk=; b=GhA4MhMgUw0T0pjVdgJ7iqUkm+N45z+8w1nGgJxrRzjgitGEiW5vYpHhUYbG/bMgsOV16v59F3X+e7IrCU6wOgnMJ+mlB8XDTrGsiFbps0F7qBoE802Y6vg4SIjEWSvRQRAEPrEAgl7qQVgt08UhaofdFU97PRVbO48BPV97GQRukAIsbe5bVPeUMPr9sXEXWvFT/gkH2hLQgRDbMs+BK3I4eWN4LihLCoErr4x9Gr0R4NLExBLNDVHde9RgIUwOgyYBIU6arBvLyOMf/s/dmKcfWFR1ltzoYI6LwN6tXtcqK9OKlp2nACjoo56ip40rzmlBiw2+75dNuLVCejulmA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ERsWoW54M+b75apBnzWqCmBDPzpefaCY4nRDhH2dDdzprrkF0hI7VzWRY3kbnMzsTqxgOhfYTVNSaaMF2SIWdqeVzE2dspA3WGRiWzBdJ4cINV+OmNKyu6dSxEbraWxAzb2zES1XLxEIrmYJAYDxirrX6R8WeV88U8paXAJojBfUqJXNn/xAJlJjACGKo+hnqBh3NrDnOzG+4WJK6vaFOeJbk2iOlZlwQWu7VBCLzA+le1tCBhMSAZiAmJ1AYL+ly5nx8YJLA2pyvsQaaMtHA6AzYHgWB3TdgM4PHtjWvlNnHWCDNlV0kSHNxQMwC5l1ZO3PPxdMQxRXp4HnXUiMlA==
  • Authentication-results: citrix.com; dkim=none (message not signed) header.d=none;citrix.com; dmarc=none action=none header.from=suse.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Delivery-date: Fri, 27 Aug 2021 09:27:04 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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)?


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 <julien@xxxxxxx>
Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
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 )



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.