Re: irq_guest_eoi_timer interaction with MSI

["Jan Beulich" <jbeulich@novell.com>]

>>> Keir Fraser <keir.fraser@eu.citrix.com> 13.11.08 10:42 >>>
>A perfectly reasonable fix if you are not worried about guest-initiated irq
>storms (e.g. because all devices are controlled by dom0) would be to remove
>the eoi_timer logic.

No, that doesn't seem like a good idea to me.

>Otherwise we could relax it some (e.g., require N IRQs
>to get stacked up rather than just 1; or add explicit rate limiting).

For the main problem at hand, that would just reduce the likelihood of the
device refusing to work. For the performance issue, that would be an
option, as would be reducing the timeout value. However, I would also
consider making EVTCHNOP_unmask clear that state, and then perhaps
find a way to tell the guest that it should call this even if unmask_evtchn()
finds the event channel to be bound to the local CPU. The obvious thing
would be to either extend shared_info or have the guest register an
address with Xen where per-event-channel overflow status would be
reported by Xen.

>We only disable MSI when the device does not support masking. Perhaps we
>should make disable/enable no-ops in that case?

Yes, but don't we need an alternative way to avoid storms then?

Jan