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.
