From: Thomas Gleixner <tglx@linutronix.de>
To: Jan Beulich <jbeulich@suse.com>,
Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "Roger Pau Monné" <roger.pau@citrix.com>, "Wei Liu" <wl@xen.org>,
"Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>,
xen-devel@lists.xenproject.org,
"Simon Gaiser" <simon@invisiblethingslab.com>
Subject: Re: [XEN PATCH] x86/ACPI: Ignore entries with invalid APIC IDs when parsing MADT
Date: Sun, 27 Aug 2023 17:44:15 +0200 [thread overview]
Message-ID: <87jztga3sg.ffs@tglx> (raw)
In-Reply-To: <26c50dc7-adf3-dbf1-253b-ce333d31911c@suse.com>
On Wed, Aug 23 2023 at 14:56, Jan Beulich wrote:
> On 23.08.2023 11:21, Andrew Cooper wrote:
>> 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.
The APIC/X2APIC description of MADT specifies flags:
Enabled If this bit is set the processor is ready for use. If
this bit is clear and the Online Capable bit is set,
system hardware supports enabling this processor during
OS runtime. If this bit is clear and the Online Capable
bit is also clear, this processor is unusable, and OSPM
shall ignore the contents of the Processor Local APIC
Structure.
Online Capable The information conveyed by this bit depends on the
value of the Enabled bit. If the Enabled bit is set,
this bit is reserved and must be zero. Otherwise, if
this this bit is set, system hardware supports enabling
this processor during OS runtime.
This is also related to SRAT which defines the proximity of memory to
processors at boot time with a similar set of flags.
Also 8.4 says:
Each processor in the system must be declared in the ACPI namespace in
the \_SB scope. .... A Device definition for a processor is declared
using the ACPI0007 hardware identifier (HID). Processor configuration
information is provided exclusively by objects in the processor
device’s object list.
When the platform uses the APIC interrupt model, UID object values
under a processor device are used to associate processor devices with
entries in the MADT.
MADT is the authoritative table for processor enumeration, whether
present or not. This is required because that's the only way to size
resources, which depend on the possible maximum topology.
Otherwise you'd end up with a CPU hotplugged which is outside of the
resource space allocated during init.
Thanks,
tglx
next prev parent reply other threads:[~2023-08-27 15:44 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-07 9:38 [XEN PATCH] x86/ACPI: Ignore entries with invalid APIC IDs when parsing MADT Simon Gaiser
2023-08-07 10:01 ` Andrew Cooper
2023-08-07 10:06 ` Andrew Cooper
2023-08-07 10:17 ` Simon Gaiser
2023-08-07 14:45 ` Simon Gaiser
2023-08-23 9:32 ` Andrew Cooper
2023-09-11 10:17 ` Simon Gaiser
2023-08-07 10:13 ` Jan Beulich
2023-08-07 12:55 ` Simon Gaiser
2023-08-07 13:17 ` Jan Beulich
2023-08-07 14:04 ` Andrew Cooper
2023-08-07 14:18 ` Jan Beulich
2023-08-23 9:21 ` Andrew Cooper
2023-08-23 12:56 ` Jan Beulich
2023-08-27 15:44 ` Thomas Gleixner [this message]
2023-08-29 14:25 ` Roger Pau Monné
2023-08-29 22:54 ` Thomas Gleixner
2023-08-30 7:20 ` Jan Beulich
2023-08-30 15:44 ` Thomas Gleixner
2023-08-07 15:05 ` Simon Gaiser
2023-08-23 9:13 ` Roger Pau Monné
2023-09-01 7:44 ` Jan Beulich
2023-09-06 20:49 ` Stefano Stabellini
2023-09-07 6:50 ` Jan Beulich
2023-09-07 21:30 ` Stefano Stabellini
2023-09-11 18:24 ` Andrew Cooper
2023-09-11 22:38 ` Stefano Stabellini
2023-09-12 9:38 ` Roger Pau Monné
2023-09-12 7:56 ` Thomas Gleixner
2023-09-13 10:02 ` George Dunlap
2023-09-13 23:18 ` Stefano Stabellini
2023-09-15 10:41 ` George Dunlap
2023-09-12 8:33 ` Jan Beulich
2023-09-12 8:36 ` Jan Beulich
2023-09-11 18:05 ` Simon Gaiser
2023-09-12 8:41 ` Jan Beulich
2023-09-12 8:45 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87jztga3sg.ffs@tglx \
--to=tglx@linutronix.de \
--cc=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=marmarek@invisiblethingslab.com \
--cc=roger.pau@citrix.com \
--cc=simon@invisiblethingslab.com \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.