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

Re: [PATCH 2/4] x86/MCE: restrict allocation of thermal and CMCI vector to BSP


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Thu, 20 Nov 2025 17:25:43 +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=arcselector10001; 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=kuzQ96nhcsDbqClxo6BgU2ke70aFBZ5VK6VHGKXUP6g=; b=ErBXuyTACY/wSpt0azg6BJNx19qZb7W+NWMKx3mBzrLJU3MgM89VMM7L7LVs1HickIt025CeJ3T2NROSeWL+j2uDGLQzcfrr0Kygr+o9GVf7vAzyKWgbFA8wujV8lyqxH6EwwUG1flgxkC7B+arahc919hhQH9nPAlQ0l9Yg0bKTmXzoORHoywbW8heBLxJ8ch+CoOf4ZmRXZh1OJFjFmz7Jvy/dYM4aix69iqbi3ZNSd8TGnBShUSF1+UTmerATPYWo5y2KQyMLN1v7Qck8xx4T8VNd+jjdAvu46d1t+AbXcjaEOrrBUZYfeMaCp9EkkkAqbKjgrPjKdXgB0l5OxA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=iTXbkG622osHGjre9W2cerNsYZHuOwFZpPUOr+FQv1GIGsCo3EFGTV8ts0O36/ckcLOTt3gO+HErzRLgDpDfmiv0TqOhA3sd19ScIUQ4ZaPIxqSnCp6q4q9+maCbgRC+0/G9Fw+de5dvzphHu2LD8oDOmDqJgsLTbk5gMqL1OGH5ZQ4j5Tu1PoJo3R5r9pXvLdZRRxSPVgnzwLdc0J5KkuOhtVkvyNhPCjITnJc+ZENSnojVPaZQbTETIJUeuG80iKVLdS7kLksKi35sjT24uYV6b/jEs4cWREQm+jUy0oeIpjY8UawmvZKT7n/p5EWBWoRAkCSsGnqxZ3OeCdbzLA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 20 Nov 2025 17:26:01 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 20/11/2025 12:11 pm, Jan Beulich wrote:
> On 20.11.2025 12:51, Andrew Cooper wrote:
>> On 19/11/2025 10:50 am, Jan Beulich wrote:
>>> --- a/xen/arch/x86/cpu/mcheck/mce.c
>>> +++ b/xen/arch/x86/cpu/mcheck/mce.c
>>> @@ -110,13 +110,13 @@ static void __init mcheck_intel_therm_in
>>>  }
>>>  
>>>  /* P4/Xeon Thermal regulation detect and init */
>>> -static void intel_init_thermal(struct cpuinfo_x86 *c)
>>> +static void intel_init_thermal(const struct cpuinfo_x86 *c, bool bsp)
>>>  {
>>>      uint64_t msr_content;
>>>      uint32_t val;
>>>      int tm2 = 0;
>>>      unsigned int cpu = smp_processor_id();
>>> -    static uint8_t thermal_apic_vector;
>>> +    static uint8_t __ro_after_init thermal_apic_vector;
>>>  
>>>      if ( !intel_thermal_supported(c) )
>>>          return; /* -ENODEV */
>>> @@ -160,7 +160,8 @@ static void intel_init_thermal(struct cp
>>>          return; /* -EBUSY */
>>>      }
>>>  
>>> -    alloc_direct_apic_vector(&thermal_apic_vector, 
>>> intel_thermal_interrupt);
>>> +    if ( bsp )
>>> +        alloc_direct_apic_vector(&thermal_apic_vector, 
>>> intel_thermal_interrupt);
>> We really don't want both c and bsp passed in.  That can only go wrong.
>>
>> Furthermore, this function has 2 other examples generating bsp locally.
>>
>> The function is in desperate need of cleanup (MSRs, variable and
>> constant names), but right now this makes it worse.
>>
>> Please either use c == &boot_cpu_data, and I'll do some cleanup later,
>> or generate bsp = c == &boot_cpu_data and fix up all users in the function.
> No, throughout mce/ this won't work as long as acpi/power.c:enter_state() has
>
>     mcheck_init(&boot_cpu_data, false);

How's not not already broken then?  As said, intel_init_thermal() is
already using c == &boot_cpu_data.

This patch introduces a conflicting idea of bsp in this function, and
that's what I really want to avoid.

This looks like it wants splitting properly as {bsp,percpu}_init_$FOO()
like we have elsewhere.

~Andrew



 


Rackspace

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