Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230717223049.327865981@linutronix.de> <20230717223225.515238528@linutronix.de>
 <CAHk-=wh9sDpbCPCekRr-fgWYz=9xa0_BOkEa+5vOr9Co-fNhrQ@mail.gmail.com> <87h6q1y82v.ffs@tglx>
In-Reply-To: <87h6q1y82v.ffs@tglx>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Tue, 18 Jul 2023 09:06:27 -0700
Message-ID: <CAHk-=wjkmwJB4puU7dn0eTABXGa7WdX=JZFZjqxOEkiA3f+aGQ@mail.gmail.com>
Subject: Re: [patch 41/58] x86/apic: Add max_apic_id member
To:     Thomas Gleixner <tglx@linutronix.de>
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>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, 18 Jul 2023 at 00:47, Thomas Gleixner <tglx@linutronix.de> wrote:
>
> The confusing part here is the physical APIC ID vs. the destination
> mode.

Actually, no, what confused me here ended up being that I didn't see
any other limit checking at all for the flat mode, and then I was
"this cannot possibly work up to that limit".

But it turns out that the limit checking appears to be in the
"physflat" case, not in the simple flat case.

IOW, the physflat probe function says "I'll take it" whenever
num_possible_cpus() > 8", and that seems to be what then limits the
flat mode to a max of 8 cpus. So the limit was just in another place
than I expected.

            Linus