Re: [PATCH v3 14/22] x86/boot: choose AP stack based on APIC ID

[Sergii Dmytruk <sergii.dmytruk@xxxxxxxxx>]

On Tue, Jun 30, 2026 at 09:17:59AM +0200, Jan Beulich wrote:
> On 30.06.2026 00:18, Sergii Dmytruk wrote:
> > On Thu, Jan 22, 2026 at 04:52:36PM +0100, Jan Beulich wrote:
> >>> --- a/xen/arch/x86/boot/x86_64.S
> >>> +++ b/xen/arch/x86/boot/x86_64.S
> >>> @@ -15,7 +15,33 @@ ENTRY(__high_start)
> >>>          mov     $XEN_MINIMAL_CR4,%rcx
> >>>          mov     %rcx,%cr4
> >>>
> >>> -        mov     stack_start(%rip),%rsp
> >>> +        test    %ebx,%ebx
> >>> +        cmovz   stack_start(%rip), %rsp
> >>> +        jz      .L_stack_set
> >>> +
> >>> +        /* APs only: get stack base from APIC ID saved in %esp. */
> >>> +        mov     $-1, %rax
> >>
> >> Here and below 32-bit insn would do fine. However, ...
> >
> > Are all addresses guaraneed to be below 4 GiB?
>
> You use %rax as the loop induction variable, so there isn't any address
> in it? Plus you already use ...
>
> >>> +        lea     x86_cpu_to_apicid(%rip), %rcx
> >>> +1:
> >>> +        add     $1, %rax
> >>> +        cmp     $NR_CPUS, %eax
>
> ... as 32-bit insn here anyway.

But %rcx contains an address and it is added to %rax for `cmp` (quoted
below).  Also if an address can be larger than 4 GiB, REPNE SCASL will
have to be 64-bit which is incompatible with the lookup for a 32-bit
value (unless I'm missing an instruction form that takes 64-bit address
but compares 32-bit values).

> >>> +        jb      2f
> >>> +        hlt
> >>> +2:
> >>> +        cmp     %esp, (%rcx, %rax, 4)
> >>> +        jne     1b
> >>
> >> ... can't all of this be a simple REPNE SCASL?
> >
> > It can, but then can't have an upper bound, right?
>
> I fear I don't understand the question. REPNE SCASL scans at most %rcx
> slots, whatever %rcx is set to up front.

Right, ignore that, the source I used to look up details confused me
about terminating conditions.

> >> As to the upper bound of NR_CPUS, do we really need to look this far?
> >
> > Are you suggesting to use `max_cpus` instead?
>
> Whatever the dynamically determined upper bound is, yes.
>
> Jan

I guess that's `nr_cpu_ids` actually, `max_cpus` is a user parameter.

Regards,
Sergii