From: Jan Beulich <jbeulich@suse.com>
To: Matthew Barnes <matthew.barnes@cloud.com>
Cc: Wei Liu <wl@xen.org>, Anthony PERARD <anthony.perard@citrix.com>,
Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [XEN PATCH] tools: add x2APIC entries in MADT based on APIC ID
Date: Tue, 26 Mar 2024 17:15:46 +0100 [thread overview]
Message-ID: <b178ffdf-cbd1-45fe-a271-1fa09f40606e@suse.com> (raw)
In-Reply-To: <sjkt43mvc7mpqqbqi3yky5eouf6lk3cuiksskvrnoo7hyq7gfp@7lfnxlbpvuef>
On 26.03.2024 16:57, Matthew Barnes wrote:
>>> This patch scans each APIC ID before constructing the MADT, and uses the
>>> x2APIC entry for each vCPU whose APIC ID exceeds the size limit imposed
>>> by regular APIC entries.
>>
>> It is my understanding that if you use any x2APIC entry, every CPU needs
>> to have one.
>
> In the ACPI 6.4 specification, section 5.2.12.12, the note says the following:
>
> [Compatibility note] On some legacy OSes, Logical processors with APIC ID
> values less than 255 (whether in XAPIC or X2APIC mode) must use the Processor
> Local APIC structure to convey their APIC information to OSPM, and those
> processors must be declared in the DSDT using the Processor() keyword.
>
> Therefore, even in X2APIC mode, it's better to represent processors with APIC
> ID values less than 255 with APIC entries for legacy reasons.
Well, my reading of that is different: All CPUs need to have x2APIC entries
if one has, and CPUs with small enough APIC IDs _additionally_ need xAPIC
entries. That's what I've been observing on real hardware, too.
Jan
next prev parent reply other threads:[~2024-03-26 16:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-13 15:35 [XEN PATCH] tools: add x2APIC entries in MADT based on APIC ID Matthew Barnes
2024-03-14 13:50 ` Jan Beulich
2024-03-25 14:30 ` Alejandro Vallejo
2024-03-26 16:51 ` Roger Pau Monné
2024-03-26 15:57 ` Matthew Barnes
2024-03-26 16:15 ` Jan Beulich [this message]
2024-03-26 16:38 ` Matthew Barnes
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=b178ffdf-cbd1-45fe-a271-1fa09f40606e@suse.com \
--to=jbeulich@suse.com \
--cc=anthony.perard@citrix.com \
--cc=matthew.barnes@cloud.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.