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

Core parking broken with NR_CPUS=1


  • To: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Wed, 22 Feb 2023 16:04:33 +0000
  • 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=38zvKDkk5vqJDj8XXymqC8QaIrvQS3pO3Dlxi9Z+Zrk=; b=aMBxK/A+YMX9rTa0TJeYf8XFEWgrKWEPwSIPw3SZJ7gC9qeMwRtqRIepYcQPPwNrbTHo8pAagY188i0/a9/GENWCctvshPZxcQUAD/6FYo5R5yr6XgC/pzHRutHzec+sTyTIuiKHuYmuC4Xjc+uday8k0LnF+SW7g4DGdnIjIzQVrciXnPtXPeGfQJ0JOekgNySC+psidbM/DnwhpvvfmPtCd4rMuV0K78MoZteZumlPEB401odPcj3r2FAHr1ju1MzhO++9V/KgX6++JQ3+3OQtNgBEvJp3OdCUbGxZHUfCg5lu0RhNakwJW2NQraJbjSDZRZnPSK199zYI7Yidvg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UQSqmt91haoul2dZO9LYWNK1Dwk5HD2TRgQlNg5tX6nvQgzsxDG7KtKOkRTX12iS/M1yCO8gi6nd4eYvBVyWzccd9JRl9bDplRU0zmLVTJ5XshYiQjcijZ4AmDMIkMOHFkOIIj7zc5wHVlXniSOUERMsZJ5ThT/WFaMCujlemAnPrNf0nbftMSu/9n+e9rYCeh8Nb2S/7YEOmnuWpYHj/k/jHvRg1sgJYVTK+bZLebxmR8lVNueRuzDAQBILnw9iML8OSpfFZS+Ja9yqEjz+TmobyFA5XZKM/MemvE1vT4UrLE87q0IMlGxQ/fkvHySF9V8Gk2yQxlakdC+ch+FnIA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: Jan Beulich <jbeulich@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Xenia Ragiadakou <burzalodowa@xxxxxxxxx>
  • Delivery-date: Wed, 22 Feb 2023 16:05:07 +0000
  • Ironport-data: A9a23:kWe6bKoBKP+WPSdKQEgk2TYD1+5eBmLLZBIvgKrLsJaIsI4StFCzt garIBmOaKmIMDTzetl2YY7l8UlVv5Xcn9djQQNvqS43RXgX9puZCYyVIHmrMnLJJKUvbq7FA +Y2MYCccZ9uHhcwgj/3b9ANeFEljfngqoLUUbKCYWYpA1c/Ek/NsDo788YhmIlknNOlNA2Ev NL2sqX3NUSsnjV5KQr40YrawP9UlKm06WxwUmAWP6gR5weEzSNNVvrzGInqR5fGatgMdgKFb 76rIIGRpgvx4xorA9W5pbf3GmVirmn6ZFXmZtJ+AsBOszAazsAA+v9T2Mk0MC+7vw6hjdFpo OihgLTrIesf0g8gr8xGO/VQO3kW0aSrY9YrK1Dn2SCY5xWun3cBX5yCpaz5VGEV0r8fPI1Ay RAXACouNTaCxMm3+qi6VLlhpMIRHfHHMapK7xmMzRmBZRonabbqZvyQoPpnhnI3jM0IGuvCb c0EbzYpdA7HfxBEJlYQDtQ5gfusgX78NTZfrTp5p4JuuzSVkFM3juarbIC9lt+iHK25mm6xo G7c8nu/KRYdLNGFkhKO8262h/+JliT+MG4XPOznqqEw3QDCroAVIBsOc3fhs8KntmivfNtFF 0IP1hoiqrdnoSRHSfG4BXVUukWsrhMaHtZdDeA+wAWM0bbPpRaUAHAeSTxMY8Bgs9U5LRQo3 FKUm9LiBRR0raaYD3ma89+8sjeaKSUTa2gYakcsVhAZ6tPupIUyiBPnTdt5FqOxyNrvFlnYy S2QviE6gLkUkscj2KCy/FSBiDWpzqUlVSYw7wTTG2e6tAVwYdf/Y5TysQSBq/FdMIyeU1+N+ mAenNST5/wPCpfLkzGRROIKH/ei4PPt3CDgvGOD1qIJr1yFk0NPt6gJuFmS+G8B3h44RALU
  • Ironport-hdrordr: A9a23:biaMCqoBeUFsULUMACnOPFkaV5oUeYIsimQD101hICG9vPbo7v xG/c5rrSMc7Qx6ZJhOo6HkBEDtewK/yXcx2/hzAV7AZmjbUQmTXeVfBOLZqlWKJ8S9zI5gPM xbAs9D4bPLfD5HZAXBjDVQ0exM/DBKys+VbC7loUtQcQ==
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

While testing the rebuilt debian unstable container, I found:

common/core_parking.c: In function 'core_parking_remove':
common/core_parking.c:230:53: error: array subscript 1 is above array
bounds of 'unsigned int[1]' [-Werror=array-bounds]
  230 |         core_parking_cpunum[i] = core_parking_cpunum[i + 1];
      |                                  ~~~~~~~~~~~~~~~~~~~^~~~~~~
common/core_parking.c:31:21: note: while referencing 'core_parking_cpunum'
   31 | static unsigned int core_parking_cpunum[NR_CPUS] = {[0 ...
NR_CPUS-1] = -1};
      |                     ^~~~~~~~~~~~~~~~~~~


which is an legitimate complaint - this logic is simply broken with
NR_CPUS=1.

In principle, I think the best fix is probably to have CORE_PARKING
depend on NR_CPUS > 1, except none of the interacting x86 code has been
written in a way that would be compatible.

But it also occurs to me that this is the kind of thing an embedded x86
usecase would want to compile.  Frankly, its niche even on regular x86
use-cases.

Except having looked at the code, it's a different to the other thing we
call core parking which is the smt=0 logic to keep the stacks valid for
cores/threads we don't want to use, because of #MC broadcast problems -
and this logic does need to stay.

Thoughts?

~Andrew



 


Rackspace

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