Re: git: a695ac2ce8bc - main - arm64: Move intr_pic_init_secondary earlier

On 18 Nov 2025, at 18:02, Andrew Turner <andrew@FreeBSD.org> wrote:
> 
> The branch main has been updated by andrew:
> 
> URL: https://cgit.FreeBSD.org/src/commit/?id=a695ac2ce8bc8e8b989359002659063f2e056dcf
> 
> commit a695ac2ce8bc8e8b989359002659063f2e056dcf
> Author:     Andrew Turner <andrew@FreeBSD.org>
> AuthorDate: 2025-11-18 18:00:32 +0000
> Commit:     Andrew Turner <andrew@FreeBSD.org>
> CommitDate: 2025-11-18 18:00:32 +0000
> 
>    arm64: Move intr_pic_init_secondary earlier
> 
>    This may have been called after intr_irq_shuffle. For most interrupt
>    controllers this appears to be safe, however for the GICv5 we need to
>    read a per-CPU ID register before we can assign interrupts to a given
>    CPU.
> 
>    Fix the race by moving intr_pic_init_secondary earlier in the boot,
>    after devices have been enumerated and before the interrupts are moved
>    to their assigned CPUs.

I’ve been trying to figure out what race you’re implying exists, and cannot
find anything. My thoughts are as follows:

* If an AP isn’t properly online, why would we be looking at it for IRQ
  shuffling in the first place?
* intr_irq_shuffle is SI_SUB_SMP, SI_ORDER_SECOND, but release_aps is
  SI_SUB_SMP, SI_ORDER_FIRST
* release_aps blocks until all the APs are running, which was already
  signalled after intr_pic_init_secondary was called

Can you please explain in detail what race you believe exists? In the meantime,
given the motivation is unclear and it’s actively breaking multiple distinct
systems, please revert this, or I will do so shortly myself, and if there is a
race that needs fixing then you can re-land an alternative approach that works.

Jessica