Re: [PATCH 4/4] x86/APIC: restrict certain messages to BSP

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 13/03/2020 09:26, Jan Beulich wrote:
> All CPUs get an equal setting of EOI broadcast suppression; no need to
> log one message per CPU, even if it's only in verbose APIC mode.
>
> Only the BSP is eligible to possibly get ExtINT enabled; no need to log
> that it gets disabled on all APs, even if - again - it's only in verbose
> APIC mode.
>
> Take the opportunity and introduce a "bsp" parameter to the function, to
> stop using smp_processor_id() to tell BSP from APs.

On further consideration, this is introducing a latent bug.

In a theoretical world where we could take the BSP offline, it is still
the CPU with the ID 0 which needs various of these things setting back up.

You could argue that we could move ExtINT/NMI handling to a different
CPU, and in this case, BSP still isn't the right distinction.  We'd want
something to signify "the processor which is the target of legacy
interrupts", as in such a case, it would specifically no longer be the
CPU we booted on.

OTOH, the adjustment for the NMI watchdog does look to be different. 
AFAICT, that is for deferring the watchdog setup until later in boot, at
which point "the BSP" is the appropriate distinction to use.  (That said
- I'm not sure why anything should need delaying.  I suspect this is
misplaced code to begin with.)

As for the messages being printed, I think that is fine to restrict to
the BSP.

A conversation on LKML has revealed why LVT0.MASK gets sampled - it is
to distinguish between the two virtual wire modes.  LVT0.MASK needs to
stay masked on the BSP if the firmware configured it like that, because
the PIC is wired through an IO-APIC pin which ultimately ends up
delivering an MSI ExtINT interrupt, rather than using the dedicates
sideband bus message to emulate the legacy ExtINT/LINT0 line.

~Andrew