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

Re: [XEN PATCH] x86/ACPI: Ignore entries with invalid APIC IDs when parsing MADT


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 23 Aug 2023 14:56:45 +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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=I0epKzk3TasY2gvBS8OqyDEHuZsZVEDBQwqn8QQc5As=; b=DWOBSTaPC00J9hWkL/M6qI8vgdCFEGhwePRZ77PSXWJIwyPeueiFIHR3S74u5H9amFM/XA6C3X2Hx6E60/8CRddAByFA3A5ikfbKKBEGrrWKhIKvoojMnljD8Eyqa35cEzTjx5UeflvAlAYCs/aIyLV6cRR1VCmXbvpiKxmCAuuQeblhLW2eCuGe2UiHZ8gh6wuDUhWBfhWfAUekQON6Pt7Ro8MjyUKxkLyLKXLjlTJ0o4xAE8RBcD/OJoHeuuephtXBb0L7lHAF5ZvodTySDpVpe7wINOrIhFmfPgbVZGl4xnmklU9z0NYiX2t/9PcPTIYxRA1rtnU8Vnuc9GOyow==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BPpTEYyLGEwlzOZw5glAxaCsQlamlMPPwHOPCjzeOaXZWhm8PIF/+UjD2LHI8Qa5eTBJjQy8VrWdA3zhISk3Ufiij7DanwhlSEf22l2GAQIurUH1r3CabiEzFgcY+/Ih87XDV/bfVl+cCXj1r8+Fhb6rsADtpySXafwKo8NZB7ngPX1FNRDPr9CR8l5mnZW4gjOqs+7LiFHxda9LdcxiWWq6oPz776yWUmEH/8vVl6PdCF2ZD4wDkJfskmil8+4vVBGhZVdFQNgWEylQ/s56Llpv5eAyn2Wter8mXdENHHS/u3CoZFMxQftXh6mKSVI/SSxbvo1bGVBDBmTh7W0nJw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, Thomas Gleixner <tglx@xxxxxxxxxxxxx>, Simon Gaiser <simon@xxxxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 23 Aug 2023 12:57:01 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 23.08.2023 11:21, Andrew Cooper wrote:
> On 07/08/2023 3:18 pm, Jan Beulich wrote:
>> On 07.08.2023 16:04, Andrew Cooper wrote:
>>> On 07/08/2023 2:17 pm, Jan Beulich wrote:
>>>> On 07.08.2023 14:55, Simon Gaiser wrote:
>>>>> Jan Beulich:
>>>>>> On 07.08.2023 11:38, Simon Gaiser wrote:
>>>>>>> It seems some firmwares put dummy entries in the ACPI MADT table for non
>>>>>>> existing processors. On my NUC11TNHi5 those have the invalid APIC ID
>>>>>>> 0xff. Linux already has code to handle those cases both in
>>>>>>> acpi_parse_lapic [1] as well as in acpi_parse_x2apic [2]. So add the
>>>>>>> same check to Xen.
>>>>>> I'm afraid it doesn't become clear to me what problem you're trying to
>>>>>> solve.
>>>>> I want Xen to not think there are possible CPUs that actually never can
>>>>> be there.
>>>> Did you try using "maxcpus=" on the command line? If that doesn't work
>>>> well enough (perhaps because of causing undesirable log messages), maybe
>>>> we need some way to say "no CPU hotplug" on the command line.
>>> The ACPI tables are broken, and Xen's parsing of them is wrong.
>>>
>>> And irrespective - it's unreasonable to have users work around bugs in
>>> Xen by adding more command line.
>> Well, considering how rare CPU hotplug appears to be, such a new option
>> could default to "no hotplug".
> 
> ... or Xen could not be buggy and think there's a chance of hotplug on
> the 99% of servers where there isn't.

Why do you say "buggy" when there's no clear cut indication of whether
hotplug is possible, even not all so old ACPI versions?

>>>>> Without ignoring those dummy entries Xen thinks my NUC has 2 sockets and
>>>>> that there are 8 logical CPUs that are currently disabled but could be
>>>>> hotplugged.
>>>> Yet it's exactly this which ACPI is telling us here (with some vagueness,
>>>> which isn't easy to get around; see below).
>>>>
>>>>> I'm moderately sure that soldering in another CPU is not supported, even
>>>>> less so at runtime ;]
>>>> On your system. What about others, which are hotplug-capable?
>>> It is required that all APIC ID are stated *ahead of time*.
>> Would you mind pointing me at where this is stated?
> 
> In the spec, exactly where you'd expect to find them...
> 
> "OSPM does not expect the information provided in this table to be
> updated if the processor information changes during the lifespan of an
> OS boot."

I don't think this tells us anything about the ID not possibly changing.
It merely tells us that OSPM is not expected to parse this table again
(IOW firmware updating just this table isn't going to be enough). IDs
possibly changing is expressed by (a) the "if the processor information
changes", and (b) the next sentence, forbidding them to change while the
system is asleep: "While in the sleeping state, logical processors must
not be added or removed, nor can their ... ID or ... Flags change."

> Which is wordsmithing for "Some firmware was found to be modifying them
> and this was deemed to be illegal under the spec".

That's your reading of it; I certainly don't infer such from that
sentence.

Jan



 


Rackspace

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