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

Re: [patch 00/37] cpu/hotplug, x86: Reworked parallel CPU bringup


  • To: Thomas Gleixner <tglx@xxxxxxxxxxxxx>, Paul Menzel <pmenzel@xxxxxxxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Thu, 20 Apr 2023 10:23:36 +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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Ce9f+CnsLS53jZdO3yENs/I6TWQ0Bpki9dH27jC8ao8=; b=ZoTTQMhs8A7za5eh6A4o+MhURcLRJClCY6aEVa6qO4dlX0N8JyuZKJdqMAs6iiaLn8dUGkU4Aak1cxqxrQVMTCZjjXEVjN/owGkKFl+E7PAqmTm/VNhTUTJwshcY74XgUWx+7QPFUJPkohqgeEUyiWQ6uFYCgWmKzpujfrRTRk1TRB+xtphSPFlzp7qbNQ9oPN5eZx9+wpxdXC5fvSqgnfR7AsthAnMu9AkE+Udf+5DwwRWEnG3kAQQaQzySp6u2a6RLGgk+V0Mj9DD2YD0Na0vZ5yU2vaVCtsPIouzmqFvdtDUhjxRpEY78qW+DzkNhzpIqDb3v+AZ/+Fw0DyOCag==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=E8zMb1TeH0nTGsOqgxOcBW/OkfBLU9jZToa9n06L4+pXVJyugWtVrKR1NzOSyNPulzMLxmj3Nl9Y7UzxePTNfN5xtKQlDwPBrXU/I9HKR24YHd5zheFk9eBB6FUd6TRu8Y+tnRivav7t7XybMPC+05SD4aFsboAvPMxXrtjPw26VviDIpdS9FUj/GPKzrub4ZUJ3fQBf5SmQ6zaV4qwwZt9xgePDXJd93Wmw7Jekr3OqMzXiRnTp+jAhtUYQJ23JZpWZwfh2JUmWh6Bc5bLw8uoJ4Q9fHt30BD//ZMV4jExj6fN8+tNNcezdCTa8XGkA+qqKD+QW24gUMpyqenBFmg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: linux-kernel@xxxxxxxxxxxxxxx, x86@xxxxxxxxxx, David Woodhouse <dwmw2@xxxxxxxxxxxxx>, Brian Gerst <brgerst@xxxxxxxxx>, Arjan van de Veen <arjan@xxxxxxxxxxxxxxx>, Paolo Bonzini <pbonzini@xxxxxxxxxx>, Paul McKenney <paulmck@xxxxxxxxxx>, Tom Lendacky <thomas.lendacky@xxxxxxx>, Sean Christopherson <seanjc@xxxxxxxxxx>, Oleksandr Natalenko <oleksandr@xxxxxxxxxxxxxx>, "Guilherme G. Piccoli" <gpiccoli@xxxxxxxxxx>, Piotr Gorski <lucjan.lucjanov@xxxxxxxxx>, David Woodhouse <dwmw@xxxxxxxxxxxx>, Usama Arif <usama.arif@xxxxxxxxxxxxx>, Jürgen Groß <jgross@xxxxxxxx>, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, Russell King <linux@xxxxxxxxxxxxxxx>, Arnd Bergmann <arnd@xxxxxxxx>, linux-arm-kernel@xxxxxxxxxxxxxxxxxxx, Catalin Marinas <catalin.marinas@xxxxxxx>, Will Deacon <will@xxxxxxxxxx>, Guo Ren <guoren@xxxxxxxxxx>, linux-csky@xxxxxxxxxxxxxxx, Thomas Bogendoerfer <tsbogend@xxxxxxxxxxxxxxxx>, linux-mips@xxxxxxxxxxxxxxx, "James E. J. Bottomley" <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>, Helge Deller <deller@xxxxxx>, linux-parisc@xxxxxxxxxxxxxxx, Paul Walmsley <paul.walmsley@xxxxxxxxxx>, Palmer Dabbelt <palmer@xxxxxxxxxxx>, linux-riscv@xxxxxxxxxxxxxxxxxxx, Mark Rutland <mark.rutland@xxxxxxx>, Sabin Rapan <sabrapan@xxxxxxxxxx>
  • Delivery-date: Thu, 20 Apr 2023 09:24:18 +0000
  • Ironport-data: A9a23:SFMPd6JLUPL5dWIGFE+RF5MlxSXFcZb7ZxGr2PjKsXjdYENS1zwEm jceD2qHa67ZMWf8Kox3aYu1phgC6sLSx9A1SVFlqX01Q3x08seUXt7xwmUcnc+xBpaaEB84t ZV2hv3odp1coqr0/0/1WlTZhSAgk/rOHvykU7Ss1hlZHWdMUD0mhQ9oh9k3i4tphcnRKw6Ws Jb5rta31GWNglaYCUpJrfPSwP9TlK6q4mhA4gZmPasjUGL2zBH5MrpOfcldEFOgKmVkNrbSb /rOyri/4lTY838FYj9yuu+mGqGiaue60Tmm0hK6aYD76vRxjnVaPpIAHOgdcS9qZwChxLid/ jnvWauYEm/FNoWU8AgUvoIx/ytWZcWq85efSZSzXFD6I+QrvBIAzt03ZHzaM7H09c54MEwQz 6wFCgsvRUChvsaZwoCSYdRz05FLwMnDZOvzu1lG5BSBV7MMZ8mGRK/Ho9hFwD03m8ZCW+7EY NYUYiZuaxKGZABTPlAQC9Q1m+LAanvXKmUE7g7K4/dupTSMpOBy+OGF3N79U9qGX8hK2G2fo XrL5T/RCRAGLt2PjzGC9xpAg8eWxX+qCNNJSOLQGvhCoR637DAfJzcvWHC4htCViHyBWNFEN BlBksYphe1onKCxdfHhUBmoiHqFuAMAQd1WEv185Azl4qPO5QqxD3ICQjQHZNFOnMs3QyE6k 1aTmpbqCCZpvbm9TXOG6qzSrDW8IyEZIGYOIygeQmMt6ND/qYUyiFTKR8xiFqeuptTvHHf7x DXihDc/g7E7jsMR0ai/u1fdjFqEqYXOVAMzzgbaRGSo6kV+foHNT4ip70XLqP1bL5exUFaMp j4HltKY4eRICouC/ASJQeMQDJmg/fOBMTvBkRhoBZZn6jfF02K4d4df7TdyDE5tKsYNPzHza UnQtAUX6JI7FFmjaKJsJai2F9gtyKztBPzlX/bPY9xWa4JtcgKd5yFvfQib2GWFuEQhlaUyI 7+UdNbqAXtyIaBmyiemAv8Uy74wzQggym7JA5P21RKq1fyZfnH9Ya8MLV/Icek96biArRT96 NdRNtWHjR5YVYXWeiDT9IMJBVwDJ3I2AYywoMtSHsaHIwx7CCQ7CuTa35slepd5hOJUkOnS9 32wU0Mez0Dw7VXDKAOXejVmaav0dYhwoGh9PiE2O1usnX85bu6H/KoZMpc6Y7Qj3Ohi1uJvC ekIfd2aBfZCQSiB/C4SBbH3q5Zjb1Ksnh6UODS+YykXeIRpTAjEvNTje2PH9iYUCTGsndAju LDm3QTeKbIbQglkHsvSQPeoy1y8uz4YgO00U0agCt1Sflj8tYtnMSr8itcpLMwWbxbO3D2X0 0CRGxhwjfmd/ac2/cPPiKTCqJ2me8NyAU9FRUHa67isPCXX92blxpVPOM6CZz/QTnjo0Kqnb ORRifr7NZUvlUxIuoxUF7dt0LJ45t3zqrscxQNhdF3TZVOtGLJmI1Gc0MVPv7ELzbhc0SOuU 1+L/9JZEbaEIsXoFBgWPgVNRviD0vQdgX/W4PI5KU759Qd++bbBWkJXVzGXhSVbLrBdP4Qiz uMs/sUR7mSXjR4nMc2PiCxO32KFMnUEXqMksdccCYrm4iIk0lBJapvYCwf375iLatwKOU4vS heQmaHAjrIawlfJcXM1Embl0u9UhJBIsxdPpHcOOFGWstPAj+0w2lta9nIqTWx90w5O1us1M 3JqOWV/NLmD8z5uj8UFVGepcylEDQeavFbs118AkmHxRlOtEGfKKQUVIu+H5kkB+mR0dz1S7 raejm3iVF7XkNrZ2yIzXQtvraXlRNkprAnawpj7QIKCAoUwZifjjum2f20UphD7AMQ3wkrau e1t++U2Yqr+XcINn5AG50Ch/ex4YHi5yKZqG5mNIIth8bngRQyP
  • Ironport-hdrordr: A9a23:AloMBqEVX6uaRyLQpLqEU8eALOsnbusQ8zAXPo5KKCC9Ffbo8f xG/c5rsiMc7Qx6ZJhOo7290cW7LU80sKQFgrX409+ZLXXbUSiTXfxfBbKL+UyeJ8SGzJ8i6U 4DSchD4azLfDxHZJ3BkXCF+r8bqbHtzEnrv5a9854Kd25XgspbnmJE42igfHGebTM2dKYRJd 6z5tdnuzHlQngedMK9b0N1JdTrlpnklI/GfRVDPBIs6BCPgTS0gYSKaCSw71MxUy5v3bxnym TOkxX46qK/99m3xwTRzXW71eUnpPLRjvVCGe2RgYwuJjLghh3AXvUYZ4G/
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 20/04/2023 9:32 am, Thomas Gleixner wrote:
> On Wed, Apr 19 2023 at 17:21, Andrew Cooper wrote:
>> On 19/04/2023 2:50 pm, Andrew Cooper wrote:
>> For xAPIC, the APIC_ID register is writeable (at least, model
>> specifically), and CPUID is only the value it would have had at reset. 
>> So the AP bringup logic can't actually use CPUID reliably.
>>
>> This was changed in x2APIC, which made the x2APIC_ID immutable.
>>
>> I don't see an option other than the AP bringup code query for xAPIC vs
>> x2APIC mode, and either looking at the real APIC_ID register, or falling
>> back to CPUID.
> I'm pondering to simply deny parallel mode if x2APIC is not there.

I'm not sure if that will help much.

Just because x2APIC is there doesn't mean it's in use.  There are
several generations of Intel system which have x2APIC but also use the
opt-out bit in ACPI tables.  There are some machines which have
mismatched APIC-ness settings in the BIOS->OS handover.

There's very little you can do on the BSP alone to know for certain that
the APs come out of wait-for-SIPI already in x2APIC mode.

One way is the ÆPIC Leak "locked into x2APIC mode" giant security
bodge.  If the system really does have a CPU with an APIC ID above 0xfe,
then chances are good that the APs come out consistently...

~Andrew



 


Rackspace

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