From: Thomas Gleixner <tglx@linutronix.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
x86@kernel.org, Andrew Cooper <andrew.cooper3@citrix.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
Paolo Bonzini <pbonzini@redhat.com>, Wei Liu <wei.liu@kernel.org>,
Arjan van de Ven <arjan@linux.intel.com>,
Juergen Gross <jgross@suse.com>
Subject: Re: [patch 41/58] x86/apic: Add max_apic_id member
Date: Tue, 18 Jul 2023 09:47:36 +0200 [thread overview]
Message-ID: <87h6q1y82v.ffs@tglx> (raw)
In-Reply-To: <CAHk-=wh9sDpbCPCekRr-fgWYz=9xa0_BOkEa+5vOr9Co-fNhrQ@mail.gmail.com>
Linus!
On Mon, Jul 17 2023 at 17:19, Linus Torvalds wrote:
> So all of your patches make sense to me, but the whole apic_flat case
> confuses me.
>
> On Mon, 17 Jul 2023 at 16:15, Thomas Gleixner <tglx@linutronix.de> wrote:
>>
>> --- a/arch/x86/kernel/apic/apic_flat_64.c
>> +++ b/arch/x86/kernel/apic/apic_flat_64.c
>> @@ -94,6 +94,7 @@ static struct apic apic_flat __ro_after_
>> .cpu_present_to_apicid = default_cpu_present_to_apicid,
>> .phys_pkg_id = flat_phys_pkg_id,
>>
>> + .max_apic_id = 0xFE,
>> .get_apic_id = flat_get_apic_id,
>> .set_apic_id = set_apic_id,
>
> flat_send_IPI_mask() can only deal with a single word mask. How the
> heck can the max apic ID be more than 64?
>
> I'm probably very confused.
APIC is doing that to people.
The confusing part here is the physical APIC ID vs. the destination
mode.
Physical APIC ID is always a unique number per CPU (APIC) and on XAPIC
ranging from 0x0 to 0xFE. That's what is actually checked with that
max_apic_id entry.
Destination mode is a different story. APIC has two destination modes
for actually sending IPIs or messages from IO/APIC or PCI/MSI: Physical
and logical.
Logical is a bitmap of 8 bits, where each bit represents one CPU. So the
maximum number of CPUs addressable in logical mode is 8.
You can have a system with 8 CPUs where the physical APIC IDs are
0x20-0x27 and use logical destination mode by setting the LDR register
to the bit which represents the CPU, i.e. 1 << CPU#.
So in that 8 CPU case LDR is 0x1, 0x2, ... 0x80 on CPU0 - 7. When
sending an IPI then the destination mode in the ICR is set to logical
and the destination field is written with the bit representing the
target, i.e. 1 << CPU#. The destination field can have multiple bits set
to send the IPI to several CPUs (up to 8) with a single ICR write
operation.
Once the machine has more than 8 CPUs we are forced to use physical
destination mode. Physical destination mode is using the physical APIC
ID of the target: 0-254 are the valid addresses, which fit into one
byte. 255 (0xff) is a broadcast address. Sending IPIs to multiple
targets needs one ICR write per target, which is obviously more
expensive as between each write the ICR register has to be read back and
the ICR busy bit needs to go back to zero before the next ICR write can
happen.
X2APIC is similar. It just has a wider physical APIC ID space (full
32bit). X2APIC has a logical destination mode too which is more
useful. The logical destination is 32bit wide and split into two areas:
[cluster ID] [logical ID]
Each being 16 bit wide. The logical ID is again one bit per CPU, the
cluster ID is a number. So we can send IPIs to multiple targets (up to
16) within a cluster with one ICR write. If the IPI targets are in
different clusters then obviously we need one write per cluster.
Physical destination mode on X2APIC is the same as with XAPIC but
cheaper as it does not need the ICR readback.
I'm sure you are now even more confused.
Thanks,
tglx
next prev parent reply other threads:[~2023-07-18 7:47 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-17 23:14 [patch 00/58] x86/apic: Decrapification and static calls Thomas Gleixner
2023-07-17 23:14 ` [patch 01/58] x86/cpu: Make identify_boot_cpu() static Thomas Gleixner
2023-07-17 23:14 ` [patch 02/58] x86/cpu: Remove unused physid_*() nonsense Thomas Gleixner
2023-07-17 23:14 ` [patch 03/58] x86/apic: Rename disable_apic Thomas Gleixner
2023-07-17 23:14 ` [patch 04/58] x86/apic/ioapic: Rename skip_ioapic_setup Thomas Gleixner
2023-07-17 23:14 ` [patch 05/58] x86/apic: Remove pointless x86_bios_cpu_apicid Thomas Gleixner
2023-07-17 23:14 ` [patch 06/58] x86/apic: Get rid of hard_smp_processor_id() Thomas Gleixner
2023-07-17 23:14 ` [patch 07/58] x86/apic: Remove unused max_physical_apicid Thomas Gleixner
2023-07-17 23:14 ` [patch 08/58] x86/apic: Nuke unused apic::inquire_remote_apic() Thomas Gleixner
2023-07-17 23:14 ` [patch 09/58] x86/apic: Get rid of boot_cpu_physical_apicid madness Thomas Gleixner
2023-07-17 23:14 ` [patch 10/58] x86/apic: Register boot CPU APIC early Thomas Gleixner
2023-07-17 23:14 ` [patch 11/58] x86/apic: Remove the pointless APIC version check Thomas Gleixner
2023-07-17 23:14 ` [patch 12/58] x86/of: Fix the APIC address registration Thomas Gleixner
2023-07-17 23:14 ` [patch 13/58] x86/apic: Make some APIC init functions bool Thomas Gleixner
2023-07-17 23:14 ` [patch 14/58] x86/apic: Split register_apic_address() Thomas Gleixner
2023-07-17 23:14 ` [patch 15/58] x86/apic: Sanitize APIC address setup Thomas Gleixner
2023-07-17 23:14 ` [patch 16/58] x86/apic: Sanitize num_processors handling Thomas Gleixner
2023-07-17 23:15 ` [patch 17/58] x86/apic: Nuke another processor check Thomas Gleixner
2023-07-17 23:15 ` [patch 18/58] x86/apic: Remove check_phys_apicid_present() Thomas Gleixner
2023-07-17 23:15 ` [patch 19/58] x86/apic: Get rid of apic_phys Thomas Gleixner
2023-07-18 13:11 ` Thomas Gleixner
2023-07-20 4:18 ` Michael Kelley (LINUX)
2023-07-20 8:03 ` Thomas Gleixner
2023-07-21 4:17 ` Michael Kelley (LINUX)
2023-07-17 23:15 ` [patch 20/58] x86/apic/32: Sanitize logical APIC ID handling Thomas Gleixner
2023-07-17 23:15 ` [patch 21/58] x86/apic/32: Remove x86_cpu_to_logical_apicid Thomas Gleixner
2023-07-17 23:15 ` [patch 22/58] x86/apic/ipi: Code cleanup Thomas Gleixner
2023-07-17 23:15 ` [patch 23/58] x86/apic: Mop up early_per_cpu() abuse Thomas Gleixner
2023-07-17 23:15 ` [patch 24/58] x86/apic/32: Remove pointless default_acpi_madt_oem_check() Thomas Gleixner
2023-07-18 4:28 ` Juergen Gross
2023-07-17 23:15 ` [patch 25/58] x86/apic/32: Decrapify the def_bigsmp mechanism Thomas Gleixner
2023-07-17 23:15 ` [patch 26/58] x86/apic/32: Remove bigsmp_cpu_present_to_apicid() Thomas Gleixner
2023-07-17 23:15 ` [patch 27/58] x86/apic: Nuke empty init_apic_ldr() callbacks Thomas Gleixner
2023-07-17 23:15 ` [patch 28/58] x86/apic: Nuke apic::apicid_to_cpu_present() Thomas Gleixner
2023-07-17 23:15 ` [patch 29/58] x86/ioapic/32: Decrapify phys_id_present_map operation Thomas Gleixner
2023-07-17 23:15 ` [patch 30/58] x86/apic: Mop up *setup_apic_routing() Thomas Gleixner
2023-07-17 23:15 ` [patch 31/58] x86/apic: Mop up apic::apic_id_registered() Thomas Gleixner
2023-07-17 23:15 ` [patch 32/58] x86/apic/ipi: Tidy up the code and fixup comments Thomas Gleixner
2023-07-17 23:15 ` [patch 33/58] x86/apic: Consolidate wait_icr_idle() implementations Thomas Gleixner
2023-07-17 23:15 ` [patch 34/58] x86/apic: Allow apic::wait_icr_idle() to be NULL Thomas Gleixner
2023-07-17 23:15 ` [patch 35/58] x86/apic: Allow apic::safe_wait_icr_idle() " Thomas Gleixner
2023-07-17 23:15 ` [patch 36/58] x86/apic: Move safe wait_icr_idle() next to apic_mem_wait_icr_idle() Thomas Gleixner
2023-07-17 23:15 ` [patch 37/58] x86/apic/uv: Get rid of wrapper callbacks Thomas Gleixner
2023-07-17 23:15 ` [patch 38/58] x86/apic/x2apic: Share all common IPI functions Thomas Gleixner
2023-07-17 23:15 ` [patch 39/58] x86/apic/64: Uncopypaste probing Thomas Gleixner
2023-07-17 23:15 ` [patch 40/58] x86/apic: Wrap APIC ID validation into an inline Thomas Gleixner
2023-07-17 23:15 ` [patch 41/58] x86/apic: Add max_apic_id member Thomas Gleixner
2023-07-18 0:19 ` Linus Torvalds
2023-07-18 7:47 ` Thomas Gleixner [this message]
2023-07-18 15:54 ` Thomas Gleixner
2023-07-18 16:06 ` Linus Torvalds
2023-07-18 18:59 ` Thomas Gleixner
2023-07-17 23:15 ` [patch 42/58] x86/apic: Simplify X2APIC ID validation Thomas Gleixner
2023-07-17 23:15 ` [patch 43/58] x86/apic: Prepare x2APIC for using apic::max_apic_id Thomas Gleixner
2023-07-17 23:15 ` [patch 44/58] x86/apic: Sanitize APID ID range validation Thomas Gleixner
2023-07-17 23:15 ` [patch 45/58] x86/apic: Remove pointless NULL initializations Thomas Gleixner
2023-07-17 23:15 ` [patch 46/58] x86/apic/noop: Tidy up the code Thomas Gleixner
2023-07-17 23:15 ` [patch 47/58] x86/apic: Remove pointless arguments from [native_]eoi_write() Thomas Gleixner
2023-07-23 22:45 ` Wei Liu
2023-07-17 23:15 ` [patch 48/58] x86/apic: Nuke ack_APIC_irq() Thomas Gleixner
2023-07-23 22:45 ` Wei Liu
2023-07-17 23:15 ` [patch 49/58] x86/apic: Wrap apic->native_eoi() into a helper Thomas Gleixner
2023-07-17 23:15 ` [patch 50/58] x86/apic: Provide common init infrastructure Thomas Gleixner
2023-07-18 21:29 ` Peter Keresztes Schmidt
2023-07-18 21:51 ` Thomas Gleixner
2023-07-17 23:15 ` [patch 51/58] x86/apic: Provide apic_update_callback() Thomas Gleixner
2023-07-21 4:27 ` Michael Kelley (LINUX)
2023-07-17 23:15 ` [patch 52/58] x86/apic: Replace acpi_wake_cpu_handler_update() and apic_set_eoi_cb() Thomas Gleixner
2023-07-23 22:55 ` Wei Liu
2023-07-17 23:15 ` [patch 53/58] x86/apic: Convert other overrides to apic_update_callback() Thomas Gleixner
2023-07-21 17:49 ` Michael Kelley (LINUX)
2023-07-23 12:32 ` Thomas Gleixner
2023-07-17 23:15 ` [patch 54/58] x86/xen/apic: Mark apic __ro_after_init Thomas Gleixner
2023-07-18 15:31 ` Juergen Gross
2023-07-18 15:56 ` Thomas Gleixner
2023-07-18 16:08 ` Juergen Gross
2023-07-17 23:16 ` [patch 55/58] x86/apic: Mark all hotpath APIC callback wrappers __always_inline Thomas Gleixner
2023-07-17 23:16 ` [patch 56/58] x86/apic: Wrap IPI calls into helper functions Thomas Gleixner
2023-07-17 23:16 ` [patch 57/58] x86/apic: Provide static call infrastructure for APIC callbacks Thomas Gleixner
2023-07-18 9:19 ` Peter Zijlstra
2023-07-17 23:16 ` [patch 58/58] x86/apic: Turn on static calls Thomas Gleixner
2023-07-18 13:35 ` Thomas Gleixner
2023-07-18 0:27 ` [patch 00/58] x86/apic: Decrapification and " Linus Torvalds
2023-07-18 9:23 ` Peter Zijlstra
2023-07-18 14:29 ` Linus Walleij
2023-07-24 16:59 ` William Breathitt Gray
2023-07-20 12:43 ` Marc Gonzalez
2023-07-20 13:13 ` Peter Zijlstra
2023-07-20 13:47 ` Thomas Gleixner
2023-07-20 15:16 ` Marc Gonzalez
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=87h6q1y82v.ffs@tglx \
--to=tglx@linutronix.de \
--cc=andrew.cooper3@citrix.com \
--cc=arjan@linux.intel.com \
--cc=jgross@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=thomas.lendacky@amd.com \
--cc=torvalds@linux-foundation.org \
--cc=wei.liu@kernel.org \
--cc=x86@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox