[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>, Simon Gaiser <simon@xxxxxxxxxxxxxxxxxxxxxx>
- From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- Date: Mon, 7 Aug 2023 15:04:19 +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=VmU4k6SzTOG6clx1I/wtoQArWZ7X1lPWZ71QxHnBZKs=; b=Zg51fvtngLJ10lGMfC2XP/uN2YwEHHTbi5O98cu5gBHBquCsVgbDQvBmvZhmkNY5TH6BP4FA7Epv793UlMJ+jeZOrm58S4HaNdBdnT6DxW/NdTZgxvF2VgLM21KcGHK70T5sYM3o5BrxhQUsu3PPgzlCw0k3wvHJq1iQaBBpoT66DB6bRXJi7e1JZJV54nTFbTr1FG0+ra2RwMHzCE5p+0L1e1XnN7igLj1GKP/xeLV9aI+3dTUFaIP9Fc98Y1DBkULrCCuxB0SH2dXB5ldknhzm6PmFgh5EiFajD9RxBezgDliVtg5qVPRlyufRXHbCinQqudlK6Ffqrg8RyVJ3Nw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hAI932hAROOaEtTrY4GBo+HDdzNhfw64cEESOKaS2jul2tE2eQuNan186tM4+Sbmba0WspkkL0l4vt90WZMLp15KTzIIGLgeNekYDDyi3hcG6KEne2XZkXNl3jiRKTQhojRm8Q/dKCBP0cCWI4RlGFerjZGofNbMH88ryvbZFlvsNcrejNYt+gOklkjZk1Gup5ftNM2+nRk9I382zFIm9gJD7FBN2t7/b5rws9CmoRrdb844UacfX6QOs0tMlTypRE/lq18+tRyF4Qs+jzJuwYa6+JWDDR7bWy+GDrvLeF2/kPi87LBm8zrkgWrLj1M5ueV/KMzHSbNuIzMCUxMhpg==
- 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>
- Delivery-date: Mon, 07 Aug 2023 14:04:35 +0000
- Ironport-data: A9a23:u/jusauedXKDOyMi+dfHtrPPxOfnVKhfMUV32f8akzHdYApBsoF/q tZmKW/UbvmLYmTxftl2PYqwp0IO6sXWnNBiSFBlpH80Hn8a+JbJXdiXEBz9bniYRiHhoOCLz O1FM4Wdc5pkJpP4jk3wWlQ0hSAkjclkfpKlVKiffHg3HVQ+IMsYoUoLs/YjhYJ1isSODQqIu Nfjy+XSI1bg0DNvWo4uw/vrRChH4rKq4Vv0gnRkPaoQ5A+GyCFMZH4iDfrZw0XQE9E88tGSH 44v/JnhlkvF8hEkDM+Sk7qTWiXmlZaLYGBiIlIPM0STqkAqSh4ai87XB9JFAatjsB2bnsgZ9 Tl4ncfYpTHFnEH7sL91vxFwS0mSNEDdkVPNCSDXXce7lyUqf5ZwqhnH4Y5f0YAwo45K7W9yG fMwJBQzUQ68q7yK6eznRtVOjZ0RLZLBBdZK0p1g5Wmx4fcOZ7nmG/mPwOACmTA6i4ZJAOrUY NcfZXx3dhPcbhZTO1ARTpUjgOOvgXq5eDpdwL6XjfNvvy6Pk0oui/60b4W9lt+iHK25mm6xo G7c8nu/KRYdLNGFkhKO8262h/+JliT+MG4XPOThpqAy3wDOlwT/DjUNexyjpqWzgHS4fPxTN BI65xt/kYE9oRnDot7VGkfQTGS/lhwWVsdUEuY6wBqQ0aeS6AGcbkAfTztGbvQnstE3Xj0g0 lKVn9LvCidrubfTQnWYnp+LqRuiNC5TKnUNDQcBRBEA6sPuo6kyiAzOVddpFKOpjtzzFir0y jrMpy87750DgMhO26il8FTvhzO3uoOPXgMz/h/QXG+u8kV+foHNT5Cn7Ujz6fdGMZqDSV+Ar D4IlqCjAPsmCJiMkGmIX78LFbTxu/KdamSD3hhoAoUr8Cmr9zi7Z4dM7TpiJUBvdMEZZTvuZ 0yVsgRUjHNOAEaXgWZMS9rZI6wXIWLIT7wJiti8ggJyX6VM
- Ironport-hdrordr: A9a23:bsODKaMGq0D6j8BcTuOjsMiBIKoaSvp037BL7TEVdfUxSKb0qy nAppgmPHPP5wr5IUtQ/uxoW5PwI080l6QU3WB5B97LYOCBggWVxepZnOjfKlPbehEWwdQtsZ uII5IUNDQpNykBsS8h2njBLz/8+qjgzEl1v5ak856yd3AWV0kOhz0JczqmLg==
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
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.
>
>> 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*.
Entries with 0xFF and 0xFFFFFFFF at boot are entirely invalid.
Furthermore, given debugging that I just did with Thomas, it's very
clear that noone has tried really hotplugging CPUs under Xen. The
layering violation is rather hilarious to watch.
~Andrew
|
