[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: Jan Beulich <jbeulich@xxxxxxxx>
- From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- Date: Wed, 23 Aug 2023 10:21:02 +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=WrSH3Zk7Y59xjaBOmCiILqLUlQVv9gVYPXkkZ/PzVrg=; b=D6CtaRhqW4bo2CkS6EjdG/OVn/wDS+M/QTKhSo1Luy3ikyyZCO1MpovTr22k3JjPdAx5y9JKwLyuJLWBFLN7VjSKwWCSAwB3uAy5u6unJU/vvqF/NR2p46QyJ2qgOQbnmF1CKiCS/sUUJvXdkXYilvT7Qrl0n1v93hEUDcGIDn9VMVweqCKJg4ZtyX5OJwJWmmJhUjsAZo/hF3MQ0Njx9LTBcyxMf0hzY4rfgdpJX/BLX3iPGGVjJCozjeDMuDiML2USAuJzDmvMGSV6xVXnT90GH7ljHAre1rhdPCI51zKOlBGkUsqUnqCXh92ndAYm6X/7eTYNRYfyFd9MQ0hCbw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MCBaHG82DxXVdXB8mNsIzcwio1Orr8L4vDh6m2nqZEIqtiGKJM7XKK9ixKmaUSePFbL1tcYqumgeVU0S0Hu6m+E0T7R2hvghUNMd4lA+2WgJo7HElTYakHealQchOXU1PlA5EPaO7fdlL2wBXYizfmhz+BOHDBPtGJ8Ng6YYHdEQFLei/tqs9zn78R7apiSSWZX+ekc8F3qj0i1Xyo3ewpICzl60vOUCrjdNfb1d1vP87HY44OaC+bWhnNpDD47rHL6gS9+jefeXRLOoLjThzGox1BRtnCOsqS3kEa2CQjDTlJOhBw0sEugLeSIhAjg0ULADjbFzG/6EgOKkXsnLlQ==
- 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>, 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 09:21:25 +0000
- Ironport-data: A9a23:s9hsrarkW2e6itrFUx7UTvSu4PVeBmLnZBIvgKrLsJaIsI4StFCzt garIBmGPP6CMGD0Ld9wPIqypkNVu5DRndViT1drr381EnsV95uZCYyVIHmrMnLJJKUvbq7FA +Y2MYCccZ9uHhcwgj/3b9ANeFEljfngqoLUUbKCYWYpA1c/Ek/NsDo788YhmIlknNOlNA2Ev NL2sqX3NUSsnjV5KQr40YrawP9UlKq04GpwUmAWP6gR5weOzSJNVfrzGInqR5fGatgMdgKFb 76rIIGRpgvx4xorA9W5pbf3GmVirmn6ZFXmZtJ+AsBOszAazsAA+v9T2Mk0MC+7vw6hjdFpo OihgLTrIesf0g8gr8xGO/VQO3kW0aSrY9YrK1Dn2SCY5xWun3cBX5yCpaz5VGEV0r8fPI1Ay RAXADZOQk6Aveep+uyUFsZQq8AvEc7EOoxK7xmMzRmBZRonabbqZv2QoOR+hXI3jM0IGuvCb c0EbzYpdA7HfxBEJlYQDtQ5gfusgX78NTZfrTp5p4JuuzSVkFM3jeerbIu9lt+iHK25mm6xo G7c8nu/KRYdLNGFkhKO8262h/+JliT+MG4XPOTirqU10AbJngT/DjUHW3W5m8aGlnW0UvBDN wtXqyMq95E9oRnDot7VGkfQTGS/lhwWVsdUEuY6wBqQ0aeS6AGcbkAbShZRZdpgs9U5LRQv3 0WMlsnkBhRutqOUUnOX8rqIrTK0NjMRJGVEbigBJSMV7t+mrIwtgxbnStd4DLXzntDzASv3w T2BsG45nbp7pdIE07WT+VHBni62oZ7IXkg5623/RWOg6QVRZYi7Zpep41zW8fZBKomCSlCL+ nMDnqCjAPsmCJiMkGmWRrwLFbTxvfKdamWA0BhoAoUr8Cmr9zi7Z4dM7TpiJUBvdMEZZTvuZ 0yVsgRUjHNOAEaXgWZMS9rZI6wXIWLITLwJiti8ggJyX6VM
- Ironport-hdrordr: A9a23:jo3EUqh74b8LVfKas0A78SQqBHBQXh4ji2hC6mlwRA09TyX5ra 2TdZUgpHrJYVMqMk3I9uruBEDtex3hHP1OkOss1NWZPDUO0VHARO1fBOPZqAEIcBeOldK1u5 0AT0B/YueAd2STj6zBkXSF+wBL+qj6zEiq792usEuEVWtRGsVdB58SMHfiLqVxLjM2YqYRJd 6nyedsgSGvQngTZtTTPAh/YwCSz+e78q4PeHQ9dmca1DU=
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
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.
>
>>>> 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."
Which is wordsmithing for "Some firmware was found to be modifying them
and this was deemed to be illegal under the spec".
~Andrew
|
