Messages in this thread |  | | From | Jürgen Groß <> | Subject | Re: [PATCH 0/7] xen/events: bug fixes and some diagnostic aids | Date | Mon, 8 Feb 2021 13:14:13 +0100 |
| |
On 08.02.21 11:40, Julien Grall wrote: > Hi Juergen, > > On 08/02/2021 10:22, Jürgen Groß wrote: >> On 08.02.21 10:54, Julien Grall wrote: >>> ... I don't really see how the difference matter here. The idea is to >>> re-use what's already existing rather than trying to re-invent the >>> wheel with an extra lock (or whatever we can come up). >> >> The difference is that the race is occurring _before_ any IRQ is >> involved. So I don't see how modification of IRQ handling would help. > > Roughly our current IRQ handling flow (handle_eoi_irq()) looks like: > > if ( irq in progress ) > { > set IRQS_PENDING > return; > } > > do > { > clear IRQS_PENDING > handle_irq() > } while (IRQS_PENDING is set) > > IRQ handling flow like handle_fasteoi_irq() looks like: > > if ( irq in progress ) > return; > > handle_irq() > > The latter flow would catch "spurious" interrupt and ignore them. So it > would handle nicely the race when changing the event affinity.
Sure? Isn't "irq in progress" being reset way before our "lateeoi" is issued, thus having the same problem again? And I think we want to keep the lateeoi behavior in order to be able to control event storms.
Juergen [unhandled content-type:application/pgp-keys][unhandled content-type:application/pgp-signature] |  |