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

Re: HVM guest only bring up a single vCPU

  • To: Jan Beulich <jbeulich@xxxxxxxx>, Julien Grall <julien@xxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Fri, 27 Aug 2021 13:52:34 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.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=bor4mHy0ZMKCn9p7ISHO6wN8h6iZExosoXJLSANvU+k=; b=dltptcsuZ9R1yRUSVitHK1HHmzXI1lkLipBFoULvl9aBGW4jye/vz6/KhEpG0GHde8MZk8ww5FcDzYbOAXgyCkSfrJLVF1H/YSve9Z/DEKwZa5vkmuDHqGGpNR8AkQpESCSdkkQxCvs99Pa9/ErGeJa3L+lAiVWUAHru/jsa9OOei4YTvmUbjYVNCeh6rUApPkhjGy6dP5MIvwFb5mBGTQjTWZsbNr2VY0A/sXnhwy+etnJbRYRECX4pMW4DRpawBdbpqMrf7Shu7xwTFMSpqwmM5O9PAwSQ++teWOe3SwzQl0WlWDiH7TmPtTtgN8hDWGy9C6D0/yG4uvxF3s4E9w==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=b5TSgG0FQ3wvK0JK4IuDw4rmzJwS5tWQwe39qx7XoWdEwLzZzZ44EZx+Co3LHedGLbCs2El3cszbSciNf8iFwcHhFBelEEX1xk1qlIFDzfEZjCEektQeEqUttnB7Zh0NPy5T4sv7lGzVYs9kI3AN3A30nQxzHFaxqD/369UuKz6rXFiL3oZekTKijfmXAxbrTFYGDl0Q3nmKwEJJXJJmxYCAXaRYUspADBaNDrohbWZfHCFoEvEYjn2t6sZRRSXFW0/V/K7kD+OzLryU3Iemx9VmvidskNQMbKrEzogV6rHQNjgsvjJo+yGjqbZxrzMOoAmWJM/VBeOweztFikXmqg==
  • Authentication-results: esa5.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 27 Aug 2021 12:52:50 +0000
  • Ironport-hdrordr: A9a23:wAqSDKnIkacWfEOT/AAjtUWf97npDfO7imdD5ihNYBxZY6Wkfp +V88jzhCWZtN9OYhwdcLC7WZVpQRvnhPtICPoqTMiftW7dyReVxeBZnPbfKljbdREWmdQtrZ uIH5IOb+EYSGIK9/oSgzPIY+rIouP3iZxA7N22pxwGLXAIGtNdBkVCe2Km+yVNNXh77PECZf yhD6R81lidkDgsH7+G7i5vZZm8mzSHruOrXTc2QzocrCWehzKh77D3VzCewxclSjtKhZMv63 LMnQDV7riq96jT8G6T60bjq7Bt3PfxwNpKA8KBzuATNzXXkw6tIKBsQaeLsjwZqPymrHwqjN 7PiRE9ONkb0QKfQkiF5T/WnyXw2jcn7HHvjXeenHvYuMT8AAk3DsJQ7LgpOSfx2g4FhpVRwa hL12WWu958FhXbhhnw4NDOSlVDile0iWBKq59Rs1VvFa8lLJNBp40W+01YVL0aGjjh1YwhGO 5ySOnB+fdtd0+AZXyxhBgu/DWVZAV3Iv66eDlHhiTMuAIm20yRjnFohfD3p01wtq7UEPJ/lq L52s0CrsA8cicUBZgNTNvpD/HHU1Aleii8RF56F26XXZ3vC0i93qIf349Fk91CWKZ4hqfay6 6xHW+xiwYJCjTT4Iu1rcV2ziw=
  • Ironport-sdr: aWs/6rw0Q5LSIxDo4zKC5p9GAMOawCjAOS/T3BMHrKBm6RGPRoYUymx/9QWKraQlJQdpM7kVQv UH53p3AOdVkevRA5o5RzczfTkMACKvlquLCJoP53a9Rm18ZydPcDq9xuBievJTiwitjKdeygb9 cOnWfW9EmjMN9sVO03I2LmREeW2OFxTwu46ygw0iNMevRndxE9JIlB782A7A0TmZCOpMnFG3BX n/9KvNwOKEfQ/mE4X5ZL4X4EukfOt1u7s7XgtXXjWjR2keOex5XA+s04Rpx1PsADOYqOYrLrhm D0J8LF/UOSHeOxa2qN32ubK+
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 27/08/2021 10:26, Jan Beulich wrote:
> 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 <julien@xxxxxxx>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>

I don't particularly like this, but I don't like any of the junk we
currently have here.

This codepath ought to be limited to virtual environments which have
given us garbage in p->basic.lppp in the first place.

Therefore, Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

> ---
> 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.

It's broken for several reasons, perhaps most obviously because it is a
gross assumption that all systems look like a Intel Core/Xeon with

The right way to fix this is to pack the APIC IDs tightly (which
actually lets us break the 128 vcpu barrier without vIOMMU), and adjust
the SMT mask in leaf 0xd to compensate.

We need a slide of 8 on the APIC IDs to do AMD legacy topology by the
book, but as we've not had that before, I'm quite tempted to leave
implementing that algorithm to whomever first actually needs it.

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

Honestly, until someone starts the "lets do topology correctly,
following Intel and AMD's topology algorithms", I recommend not
tinkering.  It is incredibly fragile logic.




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