Re: [PATCH] x86/ioapic: sanitize IO-APIC pins before enabling the local APIC

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Mon, Jul 17, 2023 at 08:40:05AM +0200, Jan Beulich wrote:
> On 14.07.2023 18:05, Roger Pau Monné wrote:
> > On Thu, Jul 13, 2023 at 02:18:29PM +0200, Jan Beulich wrote:
> >> On 13.07.2023 13:29, Roger Pau Monné wrote:
> >>> So to recap, I think we are in agreement that calling enable_IO_APIC()
> >>> just ahead of the call to setup_local_APIC() is the preferred
> >>> solution?
> >>
> >> Well, yes and no. My preferred course of action for the issue at hand
> >> would be to convert RTE 0 to ExtInt (under the mentioned set of
> >> conditions). I agree though that we also want to move the masking of
> >> RTEs, and for that I further agree with the placement mentioned above.
> > 
> > So I hacked up a change to set pin 0 to ExtINT mode (and avoid doing
> > the masking early), and I got:
> > 
> > (XEN) spurious 8259A interrupt: IRQ7.
> > 
> > This was a single interrupt, but still I think the masking is the
> > critical part to get backported.
> 
> One way to look at it, yes. My perspective is different though: If
> there truly is a (spurious or not) IRQ at the 8259, then it needs
> dealing with sooner or later (in the process of booting). Aiui if
> we masked pin 0 initially and then later unmasked it (after
> switching to ExtInt, if not set so by firmware), we'd still see a
> spurious IRQ7.

Hm, I see.  I'm not very familiar with 8259, I was expecting that
maybe we would mask the IRQ before getting such spurious injection,
but I'm not even sure that's possible or whether it would work.

Thanks, Roger.